Подготовка приложения к выпуску

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

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

• Укажите значок приложения— каждое приложение Xamarin.Android должно иметь указанный значок приложения. С технической точки зрения это не обязательно, однако многие продавцы, например Google Play, требуют, чтобы у приложения был свой значок.

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

• Сжатие APK — размер окончательного APK-файла можно значительно уменьшить с помощью компоновщика Xamarin.Android в управляемом коде и ProGuard в байт-коде Java.

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

• Настройка свойств упаковки — свойства упаковки управляют созданием пакета приложений Android (APK). Этот шаг позволяет оптимизировать пакет APK, защитить его ресурс и при необходимости разбить его на модули. Кроме того, вы можете предоставить пользователям пакет приложений Android, оптимизированный для их устройств.

• Компиляция — этот шаг компилирует код и ресурсы, чтобы убедиться, что он выполняет сборку в режиме выпуска.

• Архив для публикации — этот шаг создает приложение и помещает его в архив для подписывания и публикации.

Далее эти действия описываются более подробно.

Указание значка приложения

Настоятельно рекомендуется указывать значок приложения для каждого проекта Xamarin.Android. Некоторые магазины приложений не допускают публикацию приложений Android без значков. Указать значок приложения для проекта Xamarin.Android можно с помощью свойства Icon атрибута Application.

В этих примерах в @drawable/icon добавлена ссылка на файл значка по пути Resources/drawable/icon.png (обратите внимание, что расширение .png не включено в имя ресурса). Этот атрибут также объявляется в файле Properties\AssemblyInfo.cs, как показано в следующем примере:

[assembly: Application(Icon = "@drawable/icon")]

Как правило, using Android.App объявляется в верхней части AssemblyInfo.cs (для пространства имен атрибута Android.App задается значение Application). Но, возможно, потребуется добавить инструкцию using, если ее еще нет.

Настройка управления версиями приложения

Управление версиями имеет важное значение для обслуживания и распространения приложений Android. Без какого то ни было механизма управления версиями сложно определить необходимость и способ обновления приложения. Для упрощения управления версиями Android распознает два различных типа сведений:

• Номер версии — целочисленное значение (используемое внутри Android и приложением), представляющее версию приложения. Для большинства приложений номер версии начинается с 1, и с каждой сборкой это значение увеличивается. Это значение не имеет связи или сопоставления с атрибутом имени версии (см. ниже). Пользователи не должны видеть это значение в приложениях и службах публикации. Это значение хранится в файле AndroidManifest.xml в виде android:versionCode.

• Имя версии — строка, используемая только для передачи информации пользователю о версии приложения (как установлено на определенном устройстве). Пользователи должны видеть имя версии. Оно также должно отображаться в Google Play. Android не использует эту строку для внутренних целей. Имя версии может быть любым строковым значением, упрощающим идентификацию сборки, установленной на устройстве пользователя. Это значение хранится в файле AndroidManifest.xml в виде android:versionName.

Сокращение объема пакета APK

Размер пакетов APK Xamarin.Android можно уменьшить, используя компоновщик Xamarin.Android, который удаляет ненужный управляемый код, и средство ProGuard из пакета SDK для Android, которое удаляет неиспользуемый байт-код Java. В процессе сборки сначала используется компоновщик Xamarin.Android для оптимизации управляемого кода (C#), а затем применяется ProGuard (если он включен) для оптимизации пакета APK на уровне байт-кода Java.

Настройка компоновщика

Режим "Выпуск" отключает общую среду выполнения и включает компоновку, поэтому приложение поставляет только части Xamarin.Android, необходимые во время выполнения. С помощью статического анализа компоновщик в Xamarin.Android определяет, какие сборки, типы и члены типов использует или указывает приложение Xamarin.Android. Затем компоновщик удаляет все неиспользуемые (или неуказанные) сборки, типы и члены. Это может привести к значительному сокращению размера пакета. Рассмотрим пример HelloWorld, когда окончательный размер пакета APK уменьшается на 83 %:

• Конфигурация: Нет — Xamarin.Android 4.2.5 Size = 17.4 МБ.

• Конфигурация: только сборки SDK — размер Xamarin.Android 4.2.5 = 3.0 МБ.

При компоновке могут возникать нежелательные побочные эффекты, поэтому важно повторно протестировать приложение в режиме выпуска на физическом устройстве.

ProGuard

ProGuard является средством пакета SDK для Android, которое компонует и скрывает код Java. ProGuard обычно используется для создания небольших приложений за счет сокращения размера больших включенных библиотек (например, служб Google Play) в пакете APK. ProGuard удаляет неиспользуемый байт-код Java, что приводит к уменьшению размера результирующего приложения. Например, использование ProGuard для небольших приложений Xamarin.Android обычно достигает примерно 24 % уменьшения размера — использование ProGuard для больших приложений с несколькими зависимостями библиотеки обычно достигает еще большего размера.

ProGuard не является альтернативой компоновщику Xamarin.Android. Компоновщик Xamarin.Android связывает управляемый код, а ProGuard — байт-код Java. В процессе сборки сначала используется компоновщик Xamarin.Android для оптимизации управляемого кода (C#) в приложении, а затем применяется ProGuard (если он включен) для оптимизации пакета APK на уровне байт-код Java.

Если параметр Включить ProGuard включен, Xamarin.Android запустит ProGuard в итоговом пакете APK. Во время сборки ProGuard создает и использует файл конфигурации ProGuard. Xamarin.Android также поддерживает настраиваемые действия сборки ProguardConfiguration. В проект можно добавить настраиваемый файл конфигурации ProGuard, щелкнуть его правой кнопкой мыши и выбрать в качестве действия сборки, как показано в следующем примере:

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

Дополнительные сведения об использовании средства ProGuard см. в разделе ProGuard.

Защита приложения

Выключить отладку

Во время разработки приложения Android отладка выполняется с использованием протокола Java Debug Wire (JDWP). Это технология, которая позволяет таким средствам, как adb, взаимодействовать с виртуальной машиной Java в целях отладки. Протокол JDWP включен по умолчанию для сборок отладки приложения Xamarin.Android. Несмотря на то, что протокол JDWP имеет важное значение во время разработки, он может представлять угрозу безопасности для выпускаемых приложений.

Манифест Android содержит атрибут android:debuggable, который контролирует возможность отладки приложения. Атрибуту android:debuggable рекомендуется задать значение false. Проще всего это сделать путем добавления инструкции условной компиляции в файл AssemblyInfo.cs:

#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif

Обратите внимание, что сборки отладки автоматически задают некоторые разрешения для упрощения отладки (например, Internet и ReadExternalStorage). Однако сборки выпуска используют только разрешения, настроенные явным образом. Если обнаружится, что при переключении на сборку выпуска приложение теряет разрешение, которое было доступно в сборке отладки, убедитесь, что это разрешение включено явным образом в списке Необходимые разрешения, как описано в разделе Разрешения.

Защита приложений с использованием Dotfuscator

Объединение сборок в машинный код

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

Этот параметр требует наличия лицензии Enterprise и доступен только при отключении параметра Использовать Fast Deployment. Параметр Объединить сборки в машинный код отключен по умолчанию.

Обратите внимание, что параметр Объединить в машинный код не означает, что сборки компилируются в машинный код. Параметр Компиляция AOT нельзя использовать для компиляции сборок в машинный код.

Компиляция AOT

Параметр Компиляция AOT (на странице Свойства упаковки страницы) активирует компиляцию AOT (Ahead-of-Time) сборок. Если этот параметр включен, издержки при запуске JIT (Just In Time) уменьшаются путем предварительной компиляции сборки до времени выполнения. Итоговый машинный код включается в пакет APK вместе с нескомпилированными сборками. Это приводит к сокращению времени запуска приложения, но за счет незначительного увеличения размеров APK.

Для использования параметра Компиляция AOT требуется лицензия Enterprise или более высокого уровня. Параметр Компиляция AOT доступен, только если проект настроен для режима "Выпуск". По умолчанию параметр отключен. Дополнительные сведения о компиляции AOT см. в статье об AOT.

Оптимизирующий компилятор LLVM

Оптимизирующий компилятор LLVM создает быстрее скомпилированный код небольшого размера и преобразует AOT-скомпилированные сборки в машинный код, однако это происходит за счет увеличения времени сборки. Компилятор LLVM отключен по умолчанию. Для использования компилятора LLVM сначала необходимо включить параметр Компиляция AOT на странице Свойства упаковки.

Настройка свойств упаковки

Многие из этих свойств, например Использовать общую среду выполнения и Использовать Fast Deployment, предназначены для режима отладки. Тем не менее для режима выпуска приложения предусмотрены другие настройки, которые определяют, как приложение оптимизируется по размеру и скорости выполнения, как обеспечивается защита приложения от незаконного использования и как следует упаковывать приложения для поддержки различных архитектур и ограничений по размеру.

Указание поддерживаемых архитектур

При подготовке приложения Xamarin.Android к выпуску необходимо указать поддерживаемые архитектуры процессоров. Один APK-файл может содержать код для нескольких различных архитектур. О поддержке нескольких архитектур процессоров см. раздел Архитектуры ЦП.

Создание одного пакета (APK) для каждого выбранного ABI

Если этот параметр включен, один пакет APK создается для каждого поддерживаемого ABI (выбираемого на вкладке Дополнительно, как описано в разделе Архитектуры ЦП), а не один большой пакет APK для всех поддерживаемых ABI. Этот параметр доступен, только если проект настроен для режима "Выпуск". По умолчанию параметр отключен.

Multi-DEX

Если параметр Включить Multi-Dex включен, инструменты Android SDK Tools используются для преодоления предела в 65 тысяч методов для формата DEX-файлов. Ограничение метода 65K основано на количестве методов Java, на которые ссылается приложение (включая те библиотеки, от которых зависит приложение) — это не зависит от количества методов, написанных в исходном коде. Если приложение определяет лишь несколько методов, но использует много методов (или большие библиотеки), вероятно, что предел в 65 тысяч будет превышен.

Бывает, что приложение не использует каждый метод в каждой ссылаемой библиотеке. Поэтому можно воспользоваться таким средством, как ProGuard (см. выше), чтобы удалить неиспользуемые методы из кода. Параметр Включить Multi-Dex рекомендуется включать только в случае крайней необходимости, т. е. приложение по-прежнему ссылается на более чем 65 тысяч методов Java даже после использования ProGuard.

Дополнительные сведения о Multi-Dex см. в статье о настройке приложений с более чем 64 тысячами методов.

Пакеты приложений Android

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

Чтобы включить поддержку пакетов приложений Android, в параметрах проекта Android выберите для свойства Формат пакета Android значение bundle. Прежде чем это сделать, убедитесь, что проект настроен на использование конфигурации Release, поскольку пакеты приложений предназначены только для пакетов выпуска.

Теперь можно создать пакет приложений, выполнив поток архивации. Будет создан пакет приложений для вашего приложения.

Дополнительные сведения о пакетах приложений Android см. в разделе Пакеты приложений Android.

Компилировать

Архивация для публикации

Связанные ссылки

• Многоядерные устройства и Xamarin.Android
• Архитектура процессора
• AOT
• Сокращение объемов кода и ресурсов
• Настройка приложений с помощью более чем 64 000 методов