Если извлечь максимум из вышепредставленного, то есть, выключить AOT, Linker установить на Sdk и User Assemblies (All), тогда можно сократить размер файла приложения насколько возможно, однако, в этом случае потеряется преимущество быстрого запуска.

При включении всех параметров, в том числе AOT и ProGuard для одной архитектуры размер файла увеличивается примерно на ~39%. Заметьте, что процентное увеличение может быть выше или ниже в зависимости от используемого кода и ресурсов. Пустое приложение Xamarin.Forms с включенным AOT может уместиться в 15 мб только в лучшем случае. Вероятно, приложение будет больше.

Если не включать другие параметры AOT и ProGuard, но по-прежнему использовать AOT, то файл может увеличиться на ~65%. Увеличение будет более значительным, если выбрано несколько архитектур.

Другие сравнения

Одностраничное нативное приложение Xamarin.Android без AOT, линковки SDK и пользовательских сборок занимает 5, 800 кб. При включенном AOT размер сразу подскакивает до 10, 021 кб. Это только для armeabi-v7a. Другие параметры не заданы. Одностраничное нативное приложение Android весит всего лишь 1, 747 кб. С таким нативным приложением никакое другое сравниться в минимализме не может.

AOT в Android

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

Дополнительные аргументы Android Aot

Благодаря представлению отчета об ошибке я нашел интересные аргументы, которые можно передать компилятору AOT, чтобы уменьшить двоичный размер. Хотя я не видел, что происходит с трассировкой стека в любом отчете об ошибке, я могу, по крайней мере, подтвердить, что эти аргументы уменьшают размер файла. В качестве меры предосторожности следовало бы убедиться в том, что аналитики и ведение журнала хорошо настроены и могут запечатлеть как можно больше данных, благодаря чему не придется полагаться на трассировку стека. Чтобы получить краткий справочник можно добавить и тот и другой аргумент к Android csproj вот так:

no-write-symbols

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

nodebug

Отладочная информация тоже может выявляться в окончательном двоичном файле AOT, и параметр nodebug отключает эту функцию.

Удаление поддержки x86

Это подходит не всем, однако, если приложение рассчитано исключительно для смартфонов, тогда попытаться можно, так как среди них мало тех, что с поддержкой x86. Я знаю только Asus Zenfone 2, и, согласно некоторым отчетам, общее использование x86 где-то в диапазоне 1%. Удаление поддержки для архитектуры x86 может привести к тому, что размер пакета будет меньшим.

Разделение APK в Android

Если поддерживается несколько архитектур (ABIs), использование множественной поддержки APK позволяет создать новый пакет для каждого ABI. Google предостерегает от этого, но только потому, что поддерживать придется два APK. На самом же деле недостатков в использовании двух или более APK нет за исключением дополнительных издержек, связанных с их созданием.

Чтобы это сделать можно попробовать создать по одному пакету (.apk) на каждый выбранный ABI. Таким образом создастся APK, для каждой архитектуры, которая будет выбрана для поддержки.

Уменьшаем приложение iOS

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

Сжатие изображений

При наличии в приложении большого числа изображений высокого разрешения их можно легко сжимать, причем совершенно без потери качества. Перейдите в TinyPng, чтобы сжать файлы PNG или JPEG. Мне иногда удавалось добиться сокращение размера файла изображения более чем на 80% без потери качества. Это не повлияет на использование памяти, но может привести к сокращению размера файла пакета приложения. Разумеется, в начале разработки приложения вместо этого можно использовать SVG.

ProGuard

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

Итог

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

Автор: Adam Pedley
Источник: XamarinHelp.com