Thread by @mobileunderhood

Начнем неделю. Сегодня расскажу про сборку приложения.
Будет много капитанства, но это стоит проговорить для полноты картины. #день1из7

Начать хорошо бы с официальных рекомендаций
- developer.android.com/studio/build/o…
- guides.gradle.org/performance/
Они обновляются под новые версии. Если давно не заглядывали, то самое время освежить.

Используем последние версии AGP, Gradle и всех тулзов с кодогенерацией.
Насколько свежие? Выбираем подходящий для команды баланс между стабильностью и новыми фичами.
Вчитываемся в changelog и пробуем.

"Сделать ли мне "Х", ускорит ли сборку?" - на такой вопрос нет однозначного и простого ответа.
Это гипотеза. Чтобы ее проверить, надо представлять как это работает внутри. Чем лучше мы понимаем внутренности работы, тем более эффективные модели получается строить.

А что собственно ускоряем? Надо найти где болит и научиться это измерять. Используем github.com/gradle/gradle-….
Сценарии должны отражать типовые изменения в проекте и покрывать оптимизации в системе сборки (изменение ABI, инкрементальность, чистые сборки и т.п.).

Такие проверки дорогие, поэтому запускаем их уже в develop. Это дает понимание трендов и ловит только очень крупные изменения.
Основная ценность готовых сценариев в другом. Мы упрощаем себе проверку подозрительных изменений, которые влияют на сборку.

Выносим сборку на более мощную машину: github.com/Instamotor-Lab…
Для мелких изменений иногда медленнее получается, дольше ждем синхронизацию файлов.
Также при изменении структуры модулей может сломать модели проекта для IDE, приходится все чистить.
В целом есть смысл пробовать.

Для поиска узких мест - build scan scans.gradle.com. Визуализация решает, да и типовые проблемы подсвечивают явно.
Большую часть информации можно достать самостоятельно, через API. Завтра про это подробнее.

Свежее видео с Droidcon Berlin 2019: droidcon.com/media-detail?v…

Новый день - новые баги. А ведь только похвалил build scan. Говорят, что слишком много данных засылаем. Видимо это толстый намек на покупку Gradle enterprise.

Пару слов про remote cache. Его легко настроить, но все веселье начинается потом. Хорошо если есть Gradle enterpise и он покажет корень проблемы. Но если нет, нужно самому искать.
RTFM: guides.gradle.org/using-build-ca…. С большинством описанных проблем уже столкнулись. А сейчас примеры:

Прогреваем remote cache на linux (docker) и в OSX, потому что есть баги с переносимостью кеша между ОС (issuetracker.google.com/issues/1267752…)

Написали гит хук, который подчищает пустые директории. Ломалось кеширование после рефакторинга (youtrack.jetbrains.com/issue/KT-27687)

Как одна оптимизация ломает другую или еще один пример, почему не стоит их включать без проверки (youtrack.jetbrains.com/issue/KT-31511)

Вручную проверяем параметры окружения, версию build tools, не можем зафиксировать (issuetracker.google.com/issues/1177897…). Это тоже нужно для переиспользования кеша.

И мой любимчик в номинации "веселой отладки, неудачники" thoeni.io/post/macos-sie…

Вот такие трудовые будни. Надеюсь удалось передать почему простые советы плохо работают и нужно разбираться в причинах.

Просто обязан упомянуть замечательный выпуск @PodlodkaPodcast c @artem_zin : podlodka.tilda.ws/87

Сразу огворюсь, с bazel мало знаком, не могу по существу сравнивать. Затронем еще эту тему при обсуждении CI.

@PodlodkaPodcast @artem_zin Если уже попробовали все простые оптимизации и хочется немного уличной магии: