Ads
Comments 17
+2
Выключаем Crashlytics

В предыдущем проекте пришёл к выводу, что получается очень удобно если просто вынести все метрики и аналитики в отдельный флавор. Таким образом, в дев-версию сборки, где не нужен крашлитикс и аналитика, соответствующие зависимости даже не попадут в classpath.
Для этого:
dependencies {
    productionCompile("com.crashlytics.sdk.android:crashlytics:$fabricVersion") { transitive = true; }
}
0
Тоже хорошое решение, но если вариантов которым будет необходим крашлитикс и аналитика несколько, то прийдется дублировать.
0
Не обязательно. Можно сделать через flavor dimensions. Например, есть дименшен device: phone, tablet, wear; и есть дименшен environment: production, develop, marketing. На выходе получаем device.count * environment.count * buildType.count вариантов (18 вариантов сборки).
0
Да, всё верно. И насколько я понимаю вы используете как phoneProductionDebug, так и phoneProductionRelease варианты сборки?
0
Оба варианта используются, в итоге. Релиз берёт CI-машина, а дебаг обычно собирается только на локальных машинах, если нужен.
0
А указание resConfigs влияет только на последний шаг сборки, грубо говоря, только на размер apk? Т.е. разнообразный мёржинг ресурсов остаётся и на скорость сборки это не влияет?
0
Да, всё верно. Ресурсы подготовит, смержит, а уже во время запаковки – выкинет.
0
Напрашивается вопрос — а зачем?) Я, конечно, детально со всеми этапами не знаком, но на лицо куча лишних действий)
0
Этот аспект отражён в статье, только ради уменьшения размера apk.
0
Я понял, что ради уменьшения)
Я не понимаю, для чего готовить и мержить ресурсы, которые в результате будут выкинуты.

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

Но если говорить о произвольной выборке в пределах выбранного варианта, то Вы забываете про lint проверки. Некоторые проблемы с ресурсами выяляются только на этапе сборки. Это и отсутствие переводов строк, и коллизии/баги с 9патч. Представьте себе обработку 10-20 языков, по 2-5 тысяч записей в каждом, в фоне во время основной работы с проектом. Могу ошибаться, но по-моему логичнее незначительно увеличить время сборки, но убедиться в корректности всех ресурсов.
+1
Вопрос сносности это всё же субъективный вопрос, есть объективные тесты с цифрами – разница очень существенная. Также могу сказать что разработчики Gradle обещали ускорить и следующие версии, т.е. 2.8/2.9 должны быть еще быстрее, но тестов я не проводил.
+3
Мне кажется, самая главная полезность — это осознание, что 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 }

+1
Спасибо за полезный пример!
Стоит уточнить что Gradle использует Gradle DSL. Gradle DSL в свою очередь основан на Groovy, но расширяет его для более удобной работы с билд скриптами.
Если говорить о самом полезном в Gradle, думаю, это декларативность. Декларативность позволяет создавать и рушить вселенные очень удобно и легко, не задумываясь о очень многих вещах.
Only those users with full accounts are able to leave comments.  , please.