scottKey Nov 19 2015 at 16:15

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

6 min

43K

red_mad_robot corporate blogDevelopment of mobile applications*Development for Android*Gradle*

Tutorial

+29

Comments 17

archinamon Nov 19 2015 at 18:06

Выключаем Crashlytics

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

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

scottKey Nov 19 2015 at 21:35

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

archinamon Nov 20 2015 at 18:45

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

scottKey Nov 20 2015 at 21:17

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

archinamon Nov 20 2015 at 21:55

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

scottKey Nov 20 2015 at 22:21

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

agent10 Nov 19 2015 at 19:28

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

scottKey Nov 19 2015 at 20:13

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

agent10 Nov 19 2015 at 20:16

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

scottKey Nov 19 2015 at 20:29

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

agent10 Nov 19 2015 at 20:45

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

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

scottKey Nov 19 2015 at 21:29

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

archinamon Nov 20 2015 at 18:53

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

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

stepanp Nov 19 2015 at 19:43

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

-1

scottKey Nov 19 2015 at 20:18

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

forceLain Nov 20 2015 at 06:04

Мне кажется, самая главная полезность — это осознание, что 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 Nov 20 2015 at 21:24

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