Из раза в раз Android-разработчики страдают при обновлении зависимостей в поиске совместимых версий, и мы не стали исключением. Недавно нам понадобилось обновить версию библиотеки Coil для устранения проблем с бинарной совместимостью. Однако новая версия библиотеки подтянула за собой Kotlin 2.1.0, из-за чего наш Android Gradle Plugin начал выдавать множество предупреждений, связанных с R8, и предлагал заглянуть в таблицу совместимых версий. Стоит ли говорить, что в этой таблице новой версии Kotlin не оказалось 🫥
Ну что ж, обновляем AGP до последней версии в надежде, что всё заработает. Действительно, предупреждения исчезли, но минификация перестала работать😬
Что же произошло
В версии AGP 8.4.2 изменили механизм работы R8.
Как было раньше
Сначала собирались все модули, затем выполнялась минификация каждого модуля
Как стало сейчас
Теперь минификация выполняется отдельно для каждого модуля сразу после его сборки. Из-за этого R8 считает, что код в модуле никем не используется, и просто удаляет его!
Как исправить
Правильным решением будет оставить флаг isMinifyEnabled только в application модуле. Поскольку он зависит от всех остальных модулей в приложении, минификация будет выполняться только после сборки всех модулей. Это обеспечит корректную работу минификации как для app-модуля, так и для остальных модулей.
Таким образом, оставив минификацию только для app-модуля, мы не только исправили проблему, но и ускорили сборку релизной версии, так как теперь минификация запускается только один раз.
#Android #Gradle #R8
Ну что ж, обновляем AGP до последней версии в надежде, что всё заработает. Действительно, предупреждения исчезли, но минификация перестала работать
Что же произошло
В версии AGP 8.4.2 изменили механизм работы R8.
Как было раньше
Сначала собирались все модули, затем выполнялась минификация каждого модуля
Как стало сейчас
Теперь минификация выполняется отдельно для каждого модуля сразу после его сборки. Из-за этого R8 считает, что код в модуле никем не используется, и просто удаляет его!
Как исправить
Правильным решением будет оставить флаг isMinifyEnabled только в application модуле. Поскольку он зависит от всех остальных модулей в приложении, минификация будет выполняться только после сборки всех модулей. Это обеспечит корректную работу минификации как для app-модуля, так и для остальных модулей.
Таким образом, оставив минификацию только для app-модуля, мы не только исправили проблему, но и ускорили сборку релизной версии, так как теперь минификация запускается только один раз.
#Android #Gradle #R8
Please open Telegram to view this post
VIEW IN TELEGRAM
Как ускорить релизную сборку
Из всех докладов на Mobius, которые мне удалось посмотреть, могу выделить классный доклад о том, как в Т-Банке случайно ускорили релизную сборку в два раза.
Я думаю, у многих в проектах работа R8 занимает больше всего времени из всего процесса сборки, а в крупных проектах выполнение этой таски может доходить до 3 часов🙀 — и это требует огромного количества оперативной памяти.
Так что же может значительно увеличивать длительность выполнения этой таски?
1. Неоптимальные правила
Обычно это правила с условием, например, такие встречаются в библиотеке kotlinx-serialization. На них тратится больше всего времени, нужно быть аккуратнее с такими правилами и не дублировать их в своём коде, так как правила для R8 уже поставляются вместе с библиотеками.
2. Огромное количество ресурсов
Таска shrinkResources может потреблять очень много оперативной памяти, и если в вашей дизайн-системе вы предоставляете большую библиотеку иконок, то, возможно, стоит пересмотреть подход и не тащить тысячи иконок, чтобы потом R8 не удалял их очень долго. Как вариант, можно рассмотреть загрузку иконок с CDN по запросу.
А главная проблема в том, что добавление любой библиотеки в проект или изменение правил в одном из модулей может сказаться на времени сборки всего проекта, поэтому нужно не забивать на мониторинг времени сборки приложения и вовремя реагировать на изменения.
#R8 #Gradle
Из всех докладов на Mobius, которые мне удалось посмотреть, могу выделить классный доклад о том, как в Т-Банке случайно ускорили релизную сборку в два раза.
Я думаю, у многих в проектах работа R8 занимает больше всего времени из всего процесса сборки, а в крупных проектах выполнение этой таски может доходить до 3 часов
Так что же может значительно увеличивать длительность выполнения этой таски?
1. Неоптимальные правила
Обычно это правила с условием, например, такие встречаются в библиотеке kotlinx-serialization. На них тратится больше всего времени, нужно быть аккуратнее с такими правилами и не дублировать их в своём коде, так как правила для R8 уже поставляются вместе с библиотеками.
2. Огромное количество ресурсов
Таска shrinkResources может потреблять очень много оперативной памяти, и если в вашей дизайн-системе вы предоставляете большую библиотеку иконок, то, возможно, стоит пересмотреть подход и не тащить тысячи иконок, чтобы потом R8 не удалял их очень долго. Как вариант, можно рассмотреть загрузку иконок с CDN по запросу.
А главная проблема в том, что добавление любой библиотеки в проект или изменение правил в одном из модулей может сказаться на времени сборки всего проекта, поэтому нужно не забивать на мониторинг времени сборки приложения и вовремя реагировать на изменения.
#R8 #Gradle
Please open Telegram to view this post
VIEW IN TELEGRAM
Маст-хэв кастомные Gradle-плагины
Если вы разрабатываете несколько приложений, то наверняка уже шарите какой-то общий код, вынося его в отдельные библиотеки или модули. Но не только общие модули могут быть полезны — можно ещё переиспользовать утилитарный код с помощью Gradle-плагинов.
Знаю, что многие, мягко говоря, не любят Gradle — и на то есть причины. Однако написание собственного небольшого плагина проще, чем кажется, особенно если делать это неправильно (привет afterEvaluate🙃 ).
Вот несколько идей для плагинов, которые могут быть полезны:
1️⃣ Version Catalog — очень простой плагин, который помогает удобно переиспользовать версии зависимостей между проектами. Про него я уже как-то писал здесь.
2️⃣ Code Style — обёртка над Detekt с настроенными дефолтными и кастомными правилами.
3️⃣ Git Hook — запуск тестов и проверки кода при коммите, проверка сообщения коммита и прочее.
4️⃣ Vault — плагин для получения секретов из защищённого хранилища при первоначальной настройке проекта.
5️⃣ Publish — плагин для упрощения публикации собственных плагинов, каталога версий, Android и KMP-библиотек.
🔥 Если тема интересна — ставьте реакции, и я расскажу подробнее, как создавать такие плагины и дам рекомендации как не стоит делать.
#Gradle
Если вы разрабатываете несколько приложений, то наверняка уже шарите какой-то общий код, вынося его в отдельные библиотеки или модули. Но не только общие модули могут быть полезны — можно ещё переиспользовать утилитарный код с помощью Gradle-плагинов.
Знаю, что многие, мягко говоря, не любят Gradle — и на то есть причины. Однако написание собственного небольшого плагина проще, чем кажется, особенно если делать это неправильно (привет afterEvaluate
Вот несколько идей для плагинов, которые могут быть полезны:
#Gradle
Please open Telegram to view this post
VIEW IN TELEGRAM