Как стать автором
Обновить

Комментарии 6

Спасибо за статью!
Есть только одно дополнение про этот абзац.


любое изменение в buildSrc будет инвалидировать весь кэш сборки, что может быть несущественно для средних и маленьких проектов, но выливаться в серьезные проблемы для больших команд.

Эту проблему поправили в Gradle 6.8

По ссылке, если я правильно понял, говорится про необходимость перекомпиляции .kts файлов, а не про билд кэш. А в текущей документации написано такое:
image

Хм, и правда. Невнимательно прочитал change log, там действительно только про инвалидацию конфигурации, но не про кэши.

Ради интереса прогнал assembleDebug --scan на проекте сначала с использованием buildSrc, потом с included build. Проект небольшой, состоит из трёх модулей: app, ui-kit и ещё один модуль-библиотека.


Получил такие результаты:


# Замер без кэшей для сравнения (--rerun-tasks --no-build-cache)
No cache:                            3m 9.846s, 0 avoided tasks

# buildSrc (127 tasks)
No changes:                          2.185s, 89 avoided tasks
Dependency version (non-ABI change): 3m 4.044s, 14 avoided tasks
Add dependency (ABI change):         3m 21.682s, 14 avoided tasks

# included build (115 tasks)
No changes:                          4.928s, with 87 avoided tasks
Dependency version (non-ABI change): 3m 44.495s, 13 avoided tasks
Add dependency (ABI change):         3m 38.804s, 13 avoided tasks

no changes — cначала прогонял несколько раз таск без каких либо изменений. Чтобы посмотреть сколько времени проект собирается когда есть все кэши.
dependency version — менял версию зависимости. Пересобирал проект три раза, каждый раз менял версию у разных зависимостей.
add dependency — добавлял новую константу с зависимостью. Прогонял сборку так же три раза, добавляя каждый раз новую константу.


По build-scan'ам не заметил особой разницы, разве что с buildSrc по какой-то причине чуть быстрее проходит "холостой" билд без внесения изменений (всегда около 2 сек, против 4-5 сек с included build) при том что тасок становится немного больше.
По времени есть небольшой разброс, но это не бенчмарк и замеров слишком мало поэтому скорее стоит ориентироваться на avoided tasks. При внесении любого изменения в buildSrc или included build все модули пересобирались.


Может неправильная методика замеров? Или стоит смотреть разницу на проектах с бОльшим количеством модулей?

Думаю, вообще использование композитных сборок вместо buildSrc на самом деле актуально для больших команд > 20 человек.

Сам пришел к такой архитектуре проектов энное время назад, единственное, ждём сейчас от gradle 7.0 адекватную работу с зависимостями благодаря version catalogs

Зарегистрируйтесь на Хабре, чтобы оставить комментарий