Поделиться через


Размеры пакета приложения

В этой статье рассматриваются элементы, входящие в пакет приложения Xamarin.Android, и связанные с ними стратегии эффективного развертывания пакетов на этапах отладки и выпуска.

Обзор

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

Пакеты выпусков

Чтобы предоставить пользователям полностью автономные приложения, пакет должен содержать само приложение, все связанные с ним библиотеки, контент, среду выполнения Mono и необходимые сборки библиотеки базовых классов (BCL). Например, для стандартного шаблона "Hello World" содержимое полного пакета сборки будет выглядеть так:

Package size before linker

15,8 МБ — это слишком большой размер. Основной проблемой здесь стали библиотеки BCL, так как они включают mscorlib, System и Mono.Android с большим количеством важных для работы приложения компонентов. Но значительная часть их функциональности, скорее всего, не нужна в вашем приложении. Было бы неплохо исключить эти ненужные компоненты.

При сборке приложения для распространения следует применить дополнительный процесс "компоновки", который проверяет приложение и удаляет любой неиспользуемый код. Примерно такой же процесс сборщик мусора выполняет для динамической памяти. Разница лишь в том, что он работает с объектами, а компоновщик — с кодом приложения. Например, в System.dll существует целое пространство имен для отправки и получения электронной почты. Если приложение не использует эти возможности, код для них просто зря занимает место в приложении. Запустив компоновщик для приложения Hello World, мы получим новую версию пакета:

Package size after linker

Как видите, этот процесс значительно сокращает объем BCL, удаляя все ненужное. Обратите внимание, что конечный размер BCL всегда зависит от того, что используется в приложении. Давайте рассмотрим приложение ApiDemo с более серьезной функциональностью. Здесь хорошо видно, что компонент BCL занимает больше места, чем в примере Hello World, поскольку ApiDemo нужно больше функций из него:

ApiDemo package size after linking

Как мы видим на этих примерах, размер пакета приложения обычно имеет размер на 2.9 МБ больше, чем само приложение и его зависимости.

Отладочные пакеты

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

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

При первой отладке на устройстве мы скопируем два больших пакета: Общая среда выполнения и Общая платформа. Общая среда выполнения содержит среду выполнения Mono и BCL, а общая платформа — конкретные сборки для уровня API Android:

Shared runtime package size

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

The actual application is small

Быстрое развертывание сборок

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

Чтобы включить быстрое развертывание сборок, выполните следующие действия:

  1. В обозревателе решений щелкните правой кнопкой мыши проект Android и выберите пункт Параметры.

  2. В диалоговом окне "Параметры проекта" выберите Сборка Android:

    Project Options Android Build

  3. Установите флажки Использовать общую среду выполнения Mono и Быстрое развертывание сборок:

    Checkboxes selected under Packaging tab

  4. Нажмите кнопку ОК, чтобы сохранить изменения и закрыть диалоговое окно параметров проекта.

Теперь при следующей отладочной сборке этого приложения все сборки будут установлены напрямую на устройство (если еще не установлены), и отдельно будет установлен небольшой пакет приложения (очищенный от сборок). Такой подход сокращает время на подготовку к тестированию обновленной версии приложения.

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

Итоги

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