Новая система сборки Android приложений со значительным приростом скорости 🔥
Entry posted by Yaroslav Brovin in Общая
4,208 views
Добрый день, уважаемые пользователи FGX Native!
Вот мы и подошли к главной ключевой новинке версии FGX Native 1.15.0.0, а именно речь пойдет о новой системе сборки для Android приложений 🔥. Долгое время мы шли к этому решению и уверены, что данная система сборки является ключевым нововведением для всех будущих релизов FGX Native. Это огромный шаг и потенциал для мобильной разработки на Delphi.
Перед тем, как окунуться в детали новинки, настоятельно рекомендуем ознакомиться с нашей статьей о миграции на AndroidX, в которой мы частично описали текущие проблемы, которые стоят за штатной системой сборки Delphi.
Что не так со стандартной системой сборки Delphi для Android приложений?
Для начала нужно понять, почему в чём проблемы стандартной системы сборки.
1. Поддержка сторонних Android-библиотек
Это самая важная часть для FGX Native. Мы используем различные сторонние Android библиотеки - Firebase, AdMob, Visio и прочие. Все эти библиотеки в свою очередь используют другие библиотеки, и тд т тп. Каждая библиотека - это не только код, но и ресурсы, изменения необходимые для Android манифеста и тд. Соотвественно, для полноценной поддержки сторонних Android-библиотек требуется не только внедрить исполняемый код, но и так же поставить все ресурсы и слить правки в Android манифесте.
Стандартная система сборки Delphi ограничена только внедрением кода. А это значит, что выдрав из Андроид-библиотеки только код и проигнорировав ресурсы, манифесты и нативный код, мы получаем нестабильное решение, которое может не работать, падать и тд. Поэтому в Delphi сообществе очень много проблем с использованием сторонних Android решений. И все они зачастую упираются в ограничение стандартной системы сборки.
Более подробно проблема поддержки Android-библиотек описана в статье про миграцию на AndroidX.
2. Скорость
Не секрет, что скорость сборки Android приложений из Delphi, по сравнению с нативными средствами разработки, оставляет желать лучшего. И если во время сборки простого приложения проблема не так заметна, то ситуация кардинально менятся, когда мы имеем дело с приложениями готовыми для продакшена и содержащими большое количество кода, ресурсов и тд.
Повторный запуск приложения (после сборки без изменений) может занимать минуты(!) (в зависимости от используемых ресурсов). А после внесения любых, даже самых незначительных изменений в проект, требуется потратить почти столько же времени, как на сборку проекта с нуля.
Мы собрали немного статистики от наших клиентов по сборке существующих продакшен-приложений с большим количеством экранов и ресурсов. Данные показатели зависят от многих факторов: сложность проекта, характеристики компьютера, на котором осуществляется сборка и тд. Но для нас важно относительные значения времени в рамках одного проекта и одного компьютера. Поэтому следует иметь ввиду, что в каждом конкретном случае числа будут другими.
- Первый столбец содержит время старта (без отладки) проекта с нуля. До этого проект не собирался и нет никаких промежуточных результатов сборки.
- Второй столбец указывает время старта (без отладки) проекта после внесения изменения в проект: изменили исходный код и тд.
- Третий столбец отвечает за повторный старт (без отладки) приложения без внесения изменений .
Из этой таблицы хорошо видно, что в среднем на сборку с запуском уходит ~1 минута. Обычный сценарий использования: внес изменений в коде, собрал, запустил, поймал ошибку, опять внес изменений и тд. Грубо говоря, в среднем 60 запусков в день приложения (без отладки) может занимать 1 час рабочего времени! С отладкой цифры становятся еще более угрожающими. Тратится драгоценное время на ожидание, вместо того, чтобы потратить его с пользой.
3. Технологическое отставание от требований Google
Стоит отметить, что Google активно развивает сборку Android приложений, каждый раз выдвигая всё новые и новые требования к полученному приложению:
- Был APK, на его смену пришел более умный AAB.
- Новые требования к версии используемых библиотек. Если используемая библиотека старая, то приложение не может быть загружено в маркет или же просто не работать на свежих версиях Android.
Поскольку Delphi самостоятельно реализует систему сборки, то получается состояние вечной гонки, в которой Delphi, к сожалению, всегда в роли догоняющего. Поэтому, как только Google/Apple меняют структуру пакета приложения, вам приходится ждать обновлений Delphi, которые изменят встроенную систему сборки в соответствии с новыми требованиями. С учётом частоты выхода новых версий Delphi это может вылиться в длительное ожидание, а иногда и финансовые затраты, необходимые для приобретения новой версии.
Что нам дает новая система сборки
Учитывая все перечисленные выше минусы встроенной сборки Android приложений, мы пошли по единственному верному на наш взгляд пути, а именно, мы внедрили родную систему сборки, которая используется в Android Studio и которую рекомендует сам Google.
1. Поддержка Android-библиотек
Полноценная поддержка всех Android-библиотек. Теперь перед Delphi разработчиком не будет практических никаких ограничений для использования сторонних библиотек. Мы предлагаем полный цикл интеграции любого стороннего решения в FGX Native приложения под Android:
- Вы находите интересуемое решение на Java для Android
- Вы добавляете Java библиотеку в FGX Native проект
- Вы генерируете заголовочные файлы для Java библиотеки на языке Delphi при помощи нашей утилиты Java2Delphi.
В будущем появится автоматическое скачивания всех зависимостей. Так что вам даже не придется искать файл библиотеки, достаточно будет указать имя библиотеки и её версию. Остальное на себя возьмет FGX Native.
2. Скорость
После внедрения новой системы сборки, мы попросили наших клиентов, повторно протестировать сборку их проектов. Все результаты сведены в таблицу ниже. Из нее наглядно видно, что в целом сборка и запуск проектов стал быстрее от 2 до 5 раз 🔥(кроме старта с нуля, что обуславливается долгой сборкой главной so-библиотеки приложения, которая целиком и полностью зависит от компилятора и линкера).
Давайте разберем результаты подробнее.
Старт после изменений
Данный замер является самым часто используемым. Вы вносите изменения в проект и запускаете приложение для тестирования и отладки. Практически - это основной сценарий работы разработчика. В целом прирост скорости составляет от 2 до 5 раз на тестируемой выборке проектов 🚀. Важно отметить, что при этом новая система сборки проделывает гораздо большую работу по сравнению со стандартной, даже если брать в расчёт только внедрение дополнительных ресурсов от используемых библиотеки. Количество ресурсов может исчисляться сотнями, и, если добавлять их все через Deployment Manager, то разница в результатах будет еще больше (не в пользу стандартной системы сборки).
Повторный старт
Данный вариант используется реже, когда вы пытаетесь воспроизвести какую-то ситуацию без изменений кода и у вас не получается ее поймать с первого раза. В этом случае вы просто запускаете приложение из IDE повторно.
В этом случае показатели скорости просто ошеломительные. Прирост составляет в ~5 раз на текущей выборке и практически он является постоянной. Если в стандартной системе сборке повторный запуск зависит от количества ресурсов и размера приложения, то для FGX Native это постоянная величина.
Старт с нуля
Данный тест "Старт с нуля" актуален только для первичной сборки, когда вы скачали проект и выполняете первую сборку. Это самый редкий сценарий запуска, т.к., как правило, при последующих запусках используется "кэш", полученный на предыдущих итерациях. В дальнейшем используется вариант внесения изменений и повторного старта. Сюда не относится вариант с полной пересборкой проекта.
3. Технологическое отставание от требований Google
Мы не "изобретаем велосипед" в сборке Android приложений, а берем проверенное официальное решение от Google, которое поддерживается Google. А это значит:
- Соответствование всем новым требованиям со стороны Google
- Легкое/моментальное обновление системы сборки до последней версии, без необходимости обновления Delphi
Использование
Первая сборка
При первом открытии FGX Native проекта, начиная с 1.15.0.0 автоматически будет выполнена миграция настроек проекта, в рамках которой будет предложено обновить шаблон манифеста Android приложения и файл стилей styles.xml. Если вы не вносили никаких правок, просто подтвердите замену. Если же вы вносили правки, то необходимо перенести их вручную в правую часть редактора.
При обновлении в корень проекта автоматически сохраняется старый файл шаблона. Данное поведение можно отключить при помощи чекбокса, расположенного в левом нижнем углу.
При первой сборке FGX Native проекта начиная с 1.15.0.0 в корне проекта автоматически будет создана директория ".android-build". Этот каталог содержит всё необходимое для сборки вашего проекта. Его не нужно добавлять в систему контроля версии, он может быть большого размера, так как там сохраняются промежуточные результаты сборки, при необходимости его можно удалять. Все файлы внутри данной директории являются автогенерируемыми, поэтому не пытайтесь вносить ручные правки, они будут проигнорированы.
Первая сборка может занять длительное время, так как при ней загружаются с интернета (требуется наличие активного интернет соединения!) все необходимые компоненты сборки. Однако последующие сборки будут проходить намного быстрее. Во время первой сборки среда может визуально "подвисать", это связано с тем, что интеграция с msbuild в IDE не умеет выполняться полностью параллельно.
Ошибки сборки
Если в результате сборки появляется ошибка, то подробную информацию можно найти на нижней вкладке "Output", а не в "Build", как раньше.
Например, все ошибки упаковки на панели "Build" будут сводиться к такой.
Подробности можно найти на вкладке "Output". По тексту ошибки становится ясно, что в проекте используется TargetApiVersion ниже 33.
Требования
- Для успешной сборки требуется свежая версия Java JDK (не ниже 18). Можно использовать ту, что идет в поставке с Delphi.
- Требуется наличие интернета для первой сборки приложения, так как при ней скачиваются необходимые компоненты сборки.
- Теперь все FGX Native под Android используют TargetAPILevel = 33. Мы полностью перешли на использование последней версии Android. Поэтому понижать версию теперь нельзя.
Когда планируется релиз?
Поскольку релиз 1.15.0.0 является очень крупным и затрагивает критические важные моменты, мы хотим быть уверены, что он не испортит ваши проекты. Поэтому внедрение будет происходить постепенно. На первом этапе мы отдали некоторым нашим клиентам сборку на предварительное тестирования на больших проектах, получили обратную связь и устраняем найденные недочеты. Далее на этой неделе мы планируем выпустить экспериментальную версию 1.15.0.0 для широкого круга пользователей. По сути - это полноценная версия и вы сможете опробовать её для перехода на Android 13, сравнить скорость сборки и тд. Однако, если вы столкнетесь с какими-то серьезными проблемами для вашего проекта, вы всегда сможете откатиться на стабильную версию 1.14.6.0. На текущий момент, практически все большие собранные проекты на 1.15.0.0 успешно запускаются и работают.
Если при тестировании вы столкнетесь с проблемами, просьба сообщить нам о них, и мы постараемся их оперативно поправить.
Всем спасибо за внимание и хорошей продуктивной недели!
-
14
22 Comments
Recommended Comments