Gradle: 5 полезностей для разработчика

[archinamon]

Выключаем Crashlytics

В предыдущем проекте пришёл к выводу, что получается очень удобно если просто вынести все метрики и аналитики в отдельный флавор. Таким образом, в дев-версию сборки, где не нужен крашлитикс и аналитика, соответствующие зависимости даже не попадут в classpath.
Для этого:

dependencies {
    productionCompile("com.crashlytics.sdk.android:crashlytics:$fabricVersion") { transitive = true; }
}

[scottKey]

Тоже хорошое решение, но если вариантов которым будет необходим крашлитикс и аналитика несколько, то прийдется дублировать.

[archinamon]

Не обязательно. Можно сделать через flavor dimensions. Например, есть дименшен device: phone, tablet, wear; и есть дименшен environment: production, develop, marketing. На выходе получаем device.count * environment.count * buildType.count вариантов (18 вариантов сборки).

[scottKey]

Да, всё верно. И насколько я понимаю вы используете как phoneProductionDebug, так и phoneProductionRelease варианты сборки?

[archinamon]

Оба варианта используются, в итоге. Релиз берёт CI-машина, а дебаг обычно собирается только на локальных машинах, если нужен.

[scottKey]

Тогда у вас хорошее решение, спасибо что поделились!

[agent10]

А указание resConfigs влияет только на последний шаг сборки, грубо говоря, только на размер apk? Т.е. разнообразный мёржинг ресурсов остаётся и на скорость сборки это не влияет?

[scottKey]

Да, всё верно. Ресурсы подготовит, смержит, а уже во время запаковки – выкинет.

[agent10]

Напрашивается вопрос — а зачем?) Я, конечно, детально со всеми этапами не знаком, но на лицо куча лишних действий)

[scottKey]

Этот аспект отражён в статье, только ради уменьшения размера apk.

[agent10]

Я понял, что ради уменьшения)
Я не понимаю, для чего готовить и мержить ресурсы, которые в результате будут выкинуты.

Например, у меня 10 языков, в каждом по 2 тысяче строк.
Но у меня не для всех flavors нужны все языки, где-то надо всего 2 языка.
Если бы ресурсы игнорировались на начальном этапе это могло бы немного, но повысить скорость сборки.

[scottKey]

Было бы удобно, но пока, насколько мне известно, так сделать нельзя.

[archinamon]

Кстати, он не должен мёржить ресурсы из других флаворов. Только из тех, вариант сборки которых выбран.

Но если говорить о произвольной выборке в пределах выбранного варианта, то Вы забываете про lint проверки. Некоторые проблемы с ресурсами выяляются только на этапе сборки. Это и отсутствие переводов строк, и коллизии/баги с 9патч. Представьте себе обработку 10-20 языков, по 2-5 тысяч записей в каждом, в фоне во время основной работы с проектом. Могу ошибаться, но по-моему логичнее незначительно увеличить время сборки, но убедиться в корректности всех ресурсов.

[stepanp]

Неужели в 2.4 он стал сносно по скорости работать?

[scottKey]

Вопрос сносности это всё же субъективный вопрос, есть объективные тесты с цифрами – разница очень существенная. Также могу сказать что разработчики Gradle обещали ускорить и следующие версии, т.е. 2.8/2.9 должны быть еще быстрее, но тестов я не проводил.

[forceLain]

Мне кажется, самая главная полезность — это осознание, что gradle — это не только система сборки, но и язык программирования (groovy), который в процессе билда дает возможность создавать и рушить вселенные, ну или еще что-нибудь полезное. У нас, к примеру, генерируется файл с историей версий (релизов) на основе гит тэгов.

Кусочек скрипта

def String[] tags = formatTagNames(getTagList())
def AppHistory appHistory = getAppHistory(tags)
def String jsonHistory = new GsonBuilder().setPrettyPrinting().create().toJson(appHistory)
new File("app_history.json").withWriter{ it << jsonHistory }

[scottKey]

Спасибо за полезный пример!
Стоит уточнить что Gradle использует Gradle DSL. Gradle DSL в свою очередь основан на Groovy, но расширяет его для более удобной работы с билд скриптами.
Если говорить о самом полезном в Gradle, думаю, это декларативность. Декларативность позволяет создавать и рушить вселенные очень удобно и легко, не задумываясь о очень многих вещах.