Оптимизация Gradle: ускорение сборки Android-приложений

Введение / Зачем это нужно

Gradle — это система сборки Android-приложений, и её конфигурация напрямую влияет на скорость разработки. По умолчанию настройки часто консервативны и не используют весь потенциал современного железа. Некорректная конфигурация может превратить сборку проекта в "узкое место", отнимая драгоценные минуты (а иногда и часы) на каждой итерации.

В этом гайде вы проверите и оптимизируете ключевые параметры Gradle, что в среднем ускоряет сборку Debug-сборки на 30-50%, а полные сборки — в 2-3 раза. Мы сосредоточимся на параметрах, безопасных для большинства проектов и совместимых с последними версиями Android Gradle Plugin (AGP).

Требования / Подготовка

Перед началом убедитесь, что:

1. У вас установлен Android Studio Flamingo (2022.2.1) или новее.
2. В проекте используется Android Gradle Plugin (AGP) 8.0+ и Gradle 8.0+. Проверить можно в файлах:
   • gradle/wrapper/gradle-wrapper.properties (работает distributionUrl)
   • build.gradle (проектного уровня) в блоке classpath 'com.android.tools.build:gradle:...'
3. Вы имеете права на запись в корневую папку Android-проекта.
4. Проект успешно собирается в текущей конфигурации (чтобы было с чем сравнивать).

Шаг 1: Найти или создать gradle.properties

Файл gradle.properties — это центральное место для глобальных настроек Gradle. Он должен находиться в корне вашего проекта (там же, где settings.gradle или settings.gradle.kts).

• Если файл уже существует — откройте его.
• Если нет — создайте новый текстовый файл с именем gradle.properties в корне проекта.

Также существует пользовательский файл ~/.gradle/gradle.properties (в домашней директории). Настройки из него применяются ко всем проектам. Мы будем редактировать файл в проекте, чтобы изменения были локальными и версионированными.

Шаг 2: Добавить базовые параметры производительности

Добавьте в gradle.properties следующие строки. Они включают ключевые механизмы ускорения:

# Включение Gradle Daemon - фонового процесса, который ускоряет запуск сборки
org.gradle.daemon=true

# Включение параллельного выполнения модулей (не путать с параллельными задачами внутри модуля)
org.gradle.parallel=true

# Включение кеширования build-кеша (кеширует промежуточные результаты задач)
org.gradle.caching=true

Что делают эти параметры:

• daemon: Демон остается в памяти после сборки, что исключает "холодный старт" JVM при следующем запуске.
• parallel: Позволяет Gradle выполнять сборку разных модулей проекта одновременно (если модули не зависят друг от друга).
• caching: Сохраняет результаты выполнения задач между сборками. Если входные данные (исходники, зависимости) не изменились, задача не выполняется заново.

Шаг 3: Настроить JVM аргументы для Gradle

Это самый важный блок для производительности. Недостаток памяти — частая причина медленных сборок и OutOfMemoryError. Добавьте:

# Максимальный размер heap memory для демона Gradle.
# Установите 25-50% от доступной RAM, но не более ~4-6 ГБ.
# Пример для 16 ГБ RAM: -Xmx4g
org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=1024m -Dfile.encoding=UTF-8

# Рекомендация по сборщику мусора для долгоживущих процессов (как Daemon)
org.gradle.jvmargs=-XX:+UseParallelGC -XX:MaxGCPauseMillis=200

Как рассчитать -Xmx:

1. Определите, сколько RAM обычно свободно при работе Android Studio.
2. Выделите Gradle не более 50% от этого значения. Например, если у вас 16 ГБ и под IDE и эмулятор уходит 8 ГБ, для Gradle остаётся 4-6 ГБ.
3. Слишком высокое значение (-Xmx8g на машине с 8 ГБ) вызовет свопинг и замедлит систему.

Объединённый пример для org.gradle.jvmargs:

org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=1024m -XX:+UseParallelGC -XX:MaxGCPauseMillis=200 -Dfile.encoding=UTF-8

Шаг 4: Включить конфигурацию на лету и кеширование для AGP

Для Android-проектов есть специфичные параметры, которые значительно ускоряют инкрементальные сборки:

# Включает "конфигурацию на лету" (configuration on demand) для AGP.
# Позволяет собирать только те модули, которые необходимы для текущей задачи.
android.experimental.enableNewResourceShrinker=true
android.experimental.enableSourceSetPathsMap=true

# Включает кеширование ресурсов и манифестов между сборками.
android.advancedApkSigning=true
android.aptCache=true

Примечание: Параметр android.experimental.enableNewResourceShrinker стабилен с AGP 7.0+. Остальные экспериментальные флаги могут меняться. Проверьте актуальность для вашей версии AGP в официальной документации.

Шаг 5: Настроить параллелизм для задач внутри модуля

Параметр org.gradle.parallel управляет параллелизмом между модулями. Для параллелизма внутри модуля (например, компиляция Java/Kotlin файлов, обработка ресурсов) используется другое свойство:

# Устанавливает максимальное количество worker-процессов для задач внутри модуля.
# Оптимально: количество физических ядер CPU (не гипертредов).
# Автоматическая настройка: org.gradle.workers.max=auto
org.gradle.workers.max=4

Как определить значение: Запустите nproc (Linux/macOS) или посмотрите в Диспетчере задач (Windows) количество физических ядер. Для 4-ядерного CPU установите 4, для 8-ядерного — 6 или 8. Слишком высокое значение (org.gradle.workers.max=16 на 4-ядернике) вызовет конкуренцию за ресурсы и замедлит сборку.

Шаг 6: Применить изменения и проверить результат

1. Сохраните файл gradle.properties.
2. Остановите все запущенные демоны Gradle. В терминале выполните:

   ./gradlew --stop
   

3. Очистите проект, чтобы начать "свежую" сборку с новыми настройками (это важно для первого замера):

   ./gradlew clean
   

4. Соберите проект и включите вывод лога со временем:

   ./gradlew assembleDebug --profile
   

   
   Флаг --profile сгенерирует отчет build/reports/profile/<timestamp>/profile.html. Откройте его в браузере.
5. Проанализируйте отчет:
   • Во вкладке "Tasks" вы увидите время выполнения каждой задачи. Ищите долгие задачи (:app:mergeDebugResources, :app:compileDebugKotlin).
   • Во вкладке "Build metrics" проверьте значения Daemon (должен быть true) и Configuration cache (если включен).
   • Сравните общее время сборки (BUILD SUCCESSFUL в консоли) с временем до изменений.

Проверка результата

Успешная настройка проявляется в:

1. Уменьшении времени "первой" сборки (после clean). Ожидаемый эффект: 10-30% быстрее за счет org.gradle.jvmargs и org.gradle.workers.max.
2. Резком ускорении "инкрементальных" сборок (без clean). Ожидаемый эффект: в 2-5 раз быстрее за счет org.gradle.caching, org.gradle.daemon и android.* флагов.
3. Плавной работе Android Studio без подтормаживаний при авто-сборке (Build → Make Project). Это признак адекватных org.gradle.jvmargs.
4. Отсутствии ошибок GC overhead limit exceeded или Java heap space в консоли Gradle.

Возможные проблемы

Проблема: Сборка стала медленнее или падает с ошибками памяти

Решение: Скорее всего, org.gradle.jvmargs заданы слишком агрессивно для вашего объема RAM. Уменьшите -Xmx (например, с 4096m до 2048m). Также проверьте, не конфликтуют ли флаги android.experimental.* с вашей версией AGP. Попробуйте закомментировать их.

Проблема: Gradle демон не запускается или постоянно перезапускается

Решение: Убедитесь, что org.gradle.daemon=true. Проверьте, нет ли в gradle.properties противоречивых настроек из других источников (например, в ~/.gradle/gradle.properties). Выполните ./gradlew --status, чтобы увидеть состояние демонов.

Проблема: Параллельная сборка ломает проект (неконсистентные артефакты)

Решение: Редко, но возможно при наличии некорректных зависимостей или side-effect-задач в build.gradle. Временно отключите org.gradle.parallel и постройте проект, чтобы локализовать проблемный модуль. Чаще всего проблема в build.gradle модуля, который неявно зависит от артефактов другого модуля.

Проблема: CI/CD падает с ошибками после включения кеширования

Решение: В чистом окружении CI кеш Gradle по умолчанию отключен. Настройки org.gradle.caching могут требовать предварительной подготовки кеша. Для CI часто используют отдельный файл gradle.properties.ci или передают параметры через командную строку, отключая кеш: -Dorg.gradle.caching=false.