🐘 Ускорение сборки Android проекта. Избавляемся от AGP в API-модулях

Уже давно известно что Gradle модули c Java/Kotlin плагином собираются быстрее чем те что с AGP. Статья от разработчика огромного приложения про ускорение сборки. API и IMPL модули уже сделали, а вот теперь делают чистыми API модули

#архитектура #gradle #оптимизация #agp

🤖 Демоприложения: как жить, когда у вас 90+ application-модулей (15 мин)

Т-Банк активно использовал подход демоприложений для фичей (минимальные приложения для тестирования и быстрой сборки), что привело к 90 app-модулям в Gradle-проекте.

Разработчик из T-Банка рассказал, как они занялись оптимизацией этого подхода и упрощением его поддержки, а именно:
👉 как они ушли от кода интеграции в application-модулях
👉 придумали подход collector + initializer (плагинная архитектура для настройки модулей)
👉 перешли на библиотеку App Startup, избавились от нее и стали использовать стандартный Java ServiceLoader из-за увеличения времени сборки, так как Jetpack-библиотека требует Android-модули и создает много задач

#android #gradle #оптимизация

🤖 Как удалить отладочный код в релизных сборках на примере логов

Еще одна рекомендация - используйте минификацию кода через R8/ProGuard чтобы удалить весь код логирования. Ничего лишнего не уйдёт в логи, а также повысите скорость работы

Добавьте в правила следующие инструкции

# Удаляем Log.v()
-assumenosideeffects class android.util.Log {
    public static int v(...);
}

# Удаляем Log.d()
-assumenosideeffects class android.util.Log {
    public static int d(...);
}

# Удаляем Log.i()
-assumenosideeffects class android.util.Log {
    public static int i(...);
}

Подробнее про инструкцию assumenosideeffects читайте в документации

#android #proguard #r8 #оптимизация

🤖 Strict-режим Android Resource Shrinker — аккуратнее, он без компромиссов

В Android можно включить resource shrinking, чтобы убрать из финального APK/Bundlа неиспользуемые ресурсы (строки, drawables, layouts и т.д.)

android {
    buildTypes {
        release {
            shrinkResources true
            minifyEnabled true
        }
    }
}

С недавних пор Google экспериментирует со strict режимом работы шринкера, который делает эту очистку более агрессивной, а именно:
👉 Удаляет все ресурсы, которые не удалось найти в коде или XML.
👉 Не делает допущений, что ресурс “вдруг используется где-то через reflection”. Нету явного использования или keep правила - удаление
👉 Режет всё под корень — даже если вы явно используете getIdentifier() или динамически загружаете ресурсы по имени, он может их не заметить и выкинуть.

📉 Эффект - меньший размер сборки, но есть риск крешей в рантайме, если ресурсы удалены, а были нужны

Как включается strict режим:

# В gradle.properties
android.experimental.enableStrictResourceShrinking=true

🛡 Как сохранить нужные ресурсы от удаления?

Если вы точно знаете, что ресурс используется, но shrinker может его не заметить:
1️⃣ProGuard правила (R8 учитывает их для ресурсов тоже):

# Правила для R8
-keepresources R.string.some_dynamic_string
-keepresources R.drawable.icon_loaded_by_name

2️⃣Файлы в папках res/raw/ и assets/ shrinker не трогает вообще.
3️⃣tools:keep и tools:discard в XML (подробнее тут):

<resources xmlns:tools="https://schemas.android.com/tools"
    tools:keep="@layout/landing,@drawable/logo"
    tools:discard="@drawable/unused_image" />

Рекомендации:
👉 Не включайте strict-режим без хорошего UI-тест-покрытия.
👉 Проверьте, что не используете динамическое получение ресурсов getIdentifier() без крайней необходимости.
👉 Добавляйте -keepresources, если есть малейшие сомнения.

Подробнее про оптимизацию ресурсов читайте в официальной документации

#android #r8 #оптимизация