В помощь мобильному разработчику
Ускоряем приложение на Xamarin.Forms

5 способов ускорить запуск приложения Xamarin.Forms

Александр Алексеев

Xamarin SDK для iOS и Android обеспечивает исключительно эффективную основу для создания кроссплатформенных приложений Xamarin.Forms. Когда Вы работаете над настройкой скорости и быстроты реакции приложения Xamarin.Forms, имейте в виду, что те же принципы, которые улучшают работу приложений, созданных с помощью Xamarin SDK для iOS и Android, также применимы и для усовершенствования кроссплатформенных приложений Xamarin.Forms — и это начинается с их запуска.

 

Что подразумевается под «запуском»…

В первую очередь я определяю понятие запуска — startup — как все, что происходит с того времени, как пользователь прикасается к иконке приложения и до того момента, когда на экране появляется первая информация, пригодная для использования. Сравнив пустое приложение Xamarin.Android с пустым приложением Xamarin.Forms, можно увидеть, что приложение Xamarin.Android загружается быстрее. Почему это происходит?

Xamarin.Forms предоставляют возможность совместного использования не только пользовательского интерфейса на целевых платформах, но, кроме того, и распространенных функций приложений, таких как AppLinks для глубоких ссылок, Navigation, MessagingCenter и DependencyService, а также несколько элементов, необходимых для кроссплатформенных оповещений пользовательского интерфейса, листов действий, панелей инструментов, строк состояния и т. д. В случае добавления похожих реализаций в приложение Xamarin.Android, различие в производительности начнет исчезать. Это немного объясняет происходящие, и возникает вопрос: что можно предпринять, дабы повлиять на скорость запуска? Вот пять советов по увлечению скорости запуска проектов iOS, Android и UWP.

 

1. Загрузка локального контента в первую очередь

Нам кажется выгодным загружать свежие данные сразу же после запуска приложения, но это только замедляет отображение и заполнение первого экрана. Если у Вас есть состояние от предыдущего запуска, используйте его, или пусть это будет тот контент, который используется для первого запуска.

Если приложение уже готово к работе в автономном режиме, а лучше чтобы это было так, тогда Вы все подготовили для немедленного заполнения контентом первого экрана. Azure Mobile Apps и Realm with Azure являются отличными функциями.

Если необходимо зайти в интернет, с тем чтобы получить контент для первого запуска, обеспечите пользователю некоторый интерфейс, сообщающий что в данный момент происходит при помощи индикатора загрузки. Это также прекрасная возможность для того чтобы заполнить пустую часть экрана какой-нибудь полезной информацией, дабы придать этому экрану больше смысла, или заполнить чем-то, что пользователь ожидает увидеть в приложении, или же просто чем-то веселым! Что бы Вы ни выбрали — просто не оставляйте экран пустым.

Полезный совет: Ограничьте загрузку данных из интернета только тем, что действительно необходимо. Не тратьте времени на такие затратные процессы, как обработка строк, — лучше запрашивайте данные по мере их необходимости.

 

2. Оптимизация ресурсов

Изображения и видео являются тяжелыми и могут существенно замедлить начальную визуализацию экрана. Уменьшите зависимость от тяжелых ресурсов и оптимизируйте все используемые медиа под необходимые разрешения. Не возлагайте задачу по выбору требуемых разрешений ресурсов на операционную систему.

Для целевых экранов Android компоненты размещаются в папках, представляющих плотность дисплея.

  • ldpi (low) ~120dpi
  • mdpi (medium) ~160dpi
  • hdpi (high) ~240dpi
  • xhdpi (extra-high) ~320dpi
  • xxhdpi (extra-extra-high) ~480dpi
  • xxxhdpi (extra-extra-extra-high) ~640dpi

Существует также особая плотность — nodpi, которая сообщает системе Android не масштабировать ресурсы вне зависимости от разрешения экрана.

При размещении большого изображения в папке ldpi и использовании этого компонента на экране xxhdpi Android будет масштабировать его. Это работает медленно и приводит к увеличению потребления памяти во время выполнения, а иногда даже к сбою приложения; я с этим уже сталкивался.

Чтобы справляться с различными разрешениями и большим количеством ресурсов очень полезно использовать, например, приложение Sketch и/или Zeplin для создания нескольких размеров компонентов из одного источника проекта.

В Xamarin.Android 7.0 недавно была добавлена экспериментальная функция для предварительного сжатия PNG-файлов, которая называется AndroidExplicitCrunch. Она дополнительно уменьшает размер ресурсов (и приложения), ускоряет время сборки и обеспечивает их оптимизацию для среды выполнения. Чтобы активировать эту функцию, отредактируйте текст у Android csproj и измените PropertyGroup у конфигурации сборки:

Совет: Для оптимизации размера приложения прочитай эту статью

 

3. Отложенная загрузка всего, в чем нет срочной необходимости

App.xaml Resources являются удобным местом для размещения стилей, шрифтов и других ресурсов, которые будут использоваться в приложении, но это все также будет загружаться при запуске. Если хочется устранить любую, даже миллисекундную задержку в запуске приложения, тогда отсюда следует убрать все, что не нужно, и затем неторопливо загружать это по страницам или другим методом.

 

4. Включение компиляции XAML

XAML — это популярный и однозначно мощный способ указания пользовательского интерфейса. Если Вы предпочитаете работать с C# и создавать на нем пользовательский интерфейс, он, естественно, компилируется вместе с остальным кодом, что дает возможность контролировать время и скорость компиляции. Если Вы хотите воспользоваться этим преимуществом при работе с XAML, тогда следует включить компиляцию XAML (XAMLC). Это позволит скомпилировать XAML в промежуточный язык (IL) и добавить его в скомпилированную сборку, что приведет к ускорению запуска и лучшей производительности среды выполнения. Рассмотрим, каким образом это можно активировать:

На уровне приложения Вы можете объявить свои параметры XAMLC, и это повлияет на все приложение в целом.

Если требуется задать параметры XAMLC на уровне класса, то это также можно сделать!

Если XAMLC включен, Вы получаете возможность контроля скорости компиляции на языке XAML для большинства свойств, и в результате пользовательской интерфейс отображается быстрее. Размер файла может оставаться неизменным или незначительно увеличиваться по мере, как Вы подбираете компромиссное решение в размере файла .xaml для IL в сборке.

 

5. Сокращение числа сборок

Как известно, за удобство приходится платить. Возможно, плата здесь весьма незначительна, однако, нам всегда хочется самого лучшего, когда дело касается производительности. Хотя пакеты NuGet — это замечательная вещь, так как они позволяют использовать другие библиотеки, в реальности все не так однозначно, поскольку чем больше (и крупнее) сборки, от которых зависит мобильное приложение, тем в большей степени, естественным образом, замедляется его выполнение по мере того, как вызовы пересекают границы. Xamarin.Forms, например, проверяет все сборки на предмет атрибутов [ExportRenderer] и в настоящее время не имеет метода для выбора или отказа от них. Эта одна из тех вещей, которую мы планируем улучшить в будущем.

Взвесьте преимущества/недостатки каждой зависимости и по возможности привести этот код в основное приложение. Производительность приложения и скорость запуска может варьироваться, так что нужно смотреть по обстоятельствам. Далее, приводится некоторые соображения по поводу производительности, могущие показаться Вам полезными, которые часто не принимают во внимание.

 

Бонус 1: AOT – компиляция

Я называю это бонусом, потому что мы по-прежнему классифицируем AOT как экспериментальную компиляцию на Android, и она подходит не всем. Конечно, в iOS используются AOT и компилятор LLVM по умолчанию, так что тут добавить нечего.

При включении экспериментальной компиляции Android AOT Вы получаете немедленное улучшение скорости запуска, а также общей скорости компиляции за счет некоторого снижения затрат вычислительных ресурсов. За это приходится платить некоторым увлечением размера APK, так что Вам лучше оценить возможные преимущества этого для приложения самостоятельно, и взвесить все за и против. Чтобы включить AOT, откройте конфигурацию проекта и установите  соответствующий флажок.

AOT компиляция

К сведению: AOT доступен на Xamarin Android 5.1 и 7.0+

 

Бонус 2: Оптимизация времени сборки

Хотя это напрямую и не применяется для улучшения скорости запуска, один из наших архитекторов мобильных решений — Брендон Минник поделился своим набором конфигураций по оптимизации сборки. Вы можете ознакомиться с ним на GitHub.

 

Что дальше

Здесь приводятся всего лишь несколько моих любимых трюков, и они могут применяться ко всем экранам приложения, а не только к экрану запуска. Я мог бы много к этому добавить, рассказать о разметке макета, оптимизации измерения в циклах компоновки и т. д. Большая часть этих вопросов рассматривается в Руководстве по производительности Xamarin.Forms.

Сообщество Xamarin.Forms и группа по проектированию осуществляет поиск компромиссов и обсуждает болевые точки и возможные решения на форумах Xamarin. Пожалуйста, присоединитесь к общей дискуссии, дабы поделиться своими выводами, и продолжайте дальнейшее изучения возможностей улучшения скорости запуска и выполнения приложений на всех платформах Xamarin.Forms.

 

Автор: David Ortinau
ИсточникОфициальный блог Xamarin

Александр Алексеев
Александр Алексеев

Xamarin - разработчик. Работаю с .NET платформой с 2012 года, программирую в основном с использованием C#. За это время успел поработать с ASP.NET, Entity Framework, MSSQL, Git

xamarin forms
Xamarin Live Player

Написать ответ