№9 (сентябрь 2016)

CODING
ЗАВОДНОЙ
СКРИПТИНГ
ДЛЯ ANDROID
ЗНАКОМИМСЯ
С КРУТОЙ СИСТЕМОЙ
АВТОМАТИЧЕСКОЙ
СБОРКИ GRADLE
Артур Глызин
Большинство программистов, разрабатывающих
для Android, хотя бы слышали о системе автоматической
сборки Gradle. При этом, по моим наблюдениям, лишь немногие
из использующих эту систему кодеров уделяют достаточно
времени, чтобы как следует изучить ее возможности
:). Самая частая причина звучит так: «Да ладно, это ж
просто скрипт сборки, у меня есть задачи поважнее».
А ведь на самом деле Gradle может быть очень полезен как для простой настройки
сборки, так и для решения весьма нестандартных задач! Об этом
и пойдет речь сегодня.
ANDROID GRADLE PLUGIN
Gradle сам по себе ничего не знает о том, как билдить Android-проект, в этом
ему помогает плагин, который разрабатывается вместе с Android SDK. Если
ты только недавно начал осваивать программирование под Android, то мог
и не заметить, что в главном сборочном скрипте build.gradle студия самостоятельно
добавляет зависимость от этого плагина.
А в скрипте твоего основного модуля этот плагин автоматически подключается
строчкой apply plugin: 'com.android.application'. Именно поэтому
у тебя в скрипте есть секция android { ... }, в которой ты указываешь версию
Build Tools, версии SDK для сборки и прочее.
Перед тем как мы попытаемся глубже разобраться в работе самого Gradle,
я покажу тебе несколько полезных вещей, которые умеет делать этот плагин
и о которых ты мог не знать.
Добавляем свои поля в BuildConfig
BuildConfig — это автоматически генерируемый при сборке класс, который содержит
только константы. Этот класс генерируется отдельно для каждого модуля
в твоем проекте и по умолчанию включает в себя информацию об ID приложения,
версии, типе сборки.
Редактирование вручную этого файла бесполезно, так как он все равно перезатрется
новыми данными при сборке. Зато Android-плагин может добавлять
в него те поля, которые ты скажешь.
Первый параметр — тип константы, второй — имя, третий — значение, все
просто. Заметь, что значение поля TIMEOUT вычисляется на этапе сборки
и в BuildConfig попадет уже как число 300 000. Теперь ты можешь конфигурировать
свой любимый HTTP-клиент, просто ссылаясь на константы в BuildConfig.
Добавляем свои данные в ресурсы
Принцип точно такой же, что и с BuildConfig, но позволяет добавлять значения
в файл ресурсов. Но зачем добавлять ресурс из конфига, если проще
это сделать, как обычно, в XML-файле? Просто потому, что в скрипте, так же
как и в случае с BuildConfig.TIMEOUT, значение ресурса можно вычислить. Например,
сохранить дату сборки:
Gradle создаст специальный файл generated.xml примерно такого содержания:
И пусть тебя не смущает, что мы храним время в формате String. К сожалению,
Android SDK не умеет хранить в ресурсах long, а в 32-битный integer время
не влезет.
Создаем разные варианты сборки
Пожалуй, уже все Android-программисты знают о существовании встроенных
типов сборок debug и release. Чуть меньше — о том, что можно создавать
свои типы сборок. Еще меньше тех, кто дополнительно применяет
productFlavors. Но давай по порядку.
...Все Android-программисты знают о существовании встроенных типов
сборок debug и release. Чуть меньше — о том, что можно создавать свои типы
сборок. Еще меньше тех, кто дополнительно применяет productFlavors.
Мы используем build types, чтобы иметь возможность собирать приложение
с существенными отличиями. Эти отличия обычно связаны с тем, как мы собираем
приложение: для отладки или для релиза, с обфускацией кода или без,
каким сертификатом оно будет подписано.
Чтобы собрать нужный тип, выполняем команду gradle assemble,
например gradle assembleDebug или gradle assembleQa.
INFO
Есть два пути настройки Gradle. Ты можешь установить его на машину самостоятельно
или использовать Gradle Wrapper внутри проекта. В первом случае
Gradle будет доступен тебе глобально через команду gradle из консоли.
Во втором случае сборку можно запускать через специальную программу-обертку
— gradlew. Второй способ предпочтительнее, так как может работать
с любой версией Gradle без переустановки. Тем более что при создании проекта
в Android Studio этот способ работает по умолчанию. Подробнее о Gradle
Wrapper ты можешь почитать по ссылке.
Product flavors дополняют build types и вносят еще один уровень гибкости в настройку
сборки. Используй их, когда нужно, скажем так, не глобально изменить
приложение, — это могут быть брендинг (иконки, цвета, тексты), окружение
(адрес сервера, платформа, trial- или pro-версии).
Build type и product flavor в сумме дают так называемый итоговый Build Variant,
собрать который можно по схеме gradle assemble.
Если ты хочешь запустить эти сборки не из консоли, а из студии, открой
вкладку Build Variants и выбери то, что тебе нужно, из списка, как на рис. 1.
Рис. 1. Выбор Build Variant в Android Studio
Каждая из секций buildTypes и productFlavors {...} может иметь свои
buildConfigField {...}, resValue, versionName и другие параметры, которые
будут приоритетнее, чем те, что объявлены в defaultConfig {...}.
Настраиваем информацию о приложении
Имея несколько вариантов сборок, ты точно захочешь их идентифицировать
или различать после установки. Как раз для этого у Android-плагина есть парочка
параметров — applicationIdSuffix и versionNameSuffix, которые добавляют
к существующему ID приложения и к существующей версии то, что ты
пожелаешь.
С таким конфигом команда gradle assembleTrialRelease соберет тебе приложение
с applicationId="example.myawesomeapp.release" и названием версии
MyAwesomeApp-trial.
Заканчивая тему с Android-плагином для Gradle, нужно сказать, что это
только часть его возможностей. Плагин постоянно развивается и приобретает
новые фичи. На сайте tools.android.com есть подробный гайд по его использованию.
GRADLE DSL
А теперь давай попробуем разобраться, почему конфигурация сборки
в Gradle называется скриптом, из чего состоит этот скрипт и почему он выглядит
так, как выглядит. Gradle часто называют объединением систем сборки Ant
и Maven. С одной стороны, Gradle, как и Maven, обеспечивает декларативный
подход к сборке, когда программист лишь объявляет нужные значения и параметры,
а система сама знает, как сделать всю остальную работу самостоятельно.
Именно этим мы занимались в предыдущей части.
С другой стороны, Gradle, как и Ant, умеет выполнять команды, но пишутся
они не в XML-файле, а уже с помощью Gradle DSL (domain-specific programming
language), написанном на Groovy. В мире Gradle эти команды называются
Tasks (задачи). Задачи можно делать зависимыми от других задач и таким образом
строить граф их выполнения. По сути, цепочка задач и установленные
параметры и есть скрипт сборки приложения.
В прошлой части статьи, когда мы выполняли команды вроде gradle
assembleRelease, на самом деле мы запускали уже готовую одноименную задачу.
Она не взялась из ниоткуда, ее нам подготовил Android-плагин. Ты всегда
можешь посмотреть список доступных команд, выполнив gradle tasks.
Попробуй, и ты увидишь, как много задач тебе уже предоставлено.
Рис. 2. Типичный набор задач в Android-проекте
Стандартные команды ты можешь изучить, запуская их с помощью gradle
help или gradle install. А как насчет собственных задач? Легко — давай же
скорее напишем Hello Gradle!
Добавь эту задачу в свой build-скрипт, и ты сможешь запустить ее gradle hello.
Она появится также в списке задач (gradle tasks) в разделе Other tasks. Если
ты знаком с Groovy, ты сразу заметишь, что тело задачи — это просто замыкание
(closure) с кодом, печатающим слова. Вся мощь Gradle и заключается в том,
что в теле задачи можно писать Groovy-код, а значит, можно создавать задачи,
делающие что угодно, если это можно уложить в программный код.
Прежде чем мы напишем что-то действительно полезное, давай я тебе покажу
еще пару примеров манипулирования задачами.
Пример 1: добавляем зависимости к задаче
Мы написали две задачи, печатающие отдельно слова Hello и world. Операция