Android → Все о Gradle

Давайте поговорим о настройках Gradle.

DexOptions
Вот схема опций:

android {
dexOptions {
incremental
preDexLibraries
jumboMode
javaMaxHeapSize
}
}


boolean incremental

Включить инкрементный режим для dx. Это имеет множество ограничений и может не работать. Используйте осторожно.
incremental: это означает, что Gradle будет использовать предыдущий файл dex и добавляет к ним новые изменения (не создавая их снова каждый раз).
При сборке выводится предупреждение: DSL element 'DexOptions.incremental' is obsolete and will be removed at the end of 2018.



boolean jumboMode

Включить jumbo-режим в dx (-force-jumbo).

boolean preDexLibraries

Использовать ли библиотеки pre-dex. Это может улучшить инкрементные сборки, но чистые сборки могут быть медленнее.

Добавляем свои поля в BuildConfig

BuildConfig — это автоматически генерируемый при сборке класс, который содержит только константы. Этот класс генерируется отдельно для каждого модуля в твоем проекте и по умолчанию включает в себя информацию об ID приложения, версии, типе сборки.
Для добавления констант в BuildConfig необходимо редактировать Gradle.

android {

defaultConfig {
applicationId "example.myawesomeapp"
minSdkVersion 16
targetSdkVersion 24
versionCode 1
versionName "MyApp-v1.0"
// Вот эти строки
buildConfigField "String", "SERVER", '"https://my-server.example"'
buildConfigField "long", "TIMEOUT ", "${1000 60 5}" // 5 минут
}
// Прочее
}


Добавляем свои данные в ресурсы
Принцип точно такой же, что и с BuildConfig, но позволяет добавлять значения в файл ресурсов. Но зачем добавлять ресурс из конфига, если проще это сделать, как обычно, в XML-файле? Просто потому, что в скрипте, так же как и в случае с BuildConfig.TIMEOUT, значение ресурса можно вычислить. Например, сохранить дату сборки:

resValue "string", "BUILD_TIME", "${System.currentTimeSeconds()}"

Gradle создаст специальный файл generated.xml примерно такого содержания (только, разумеется, с правильными угловыми скобочками):

[?xml version="1.0" encoding="utf-8"?]
[resources]
[!-- Automatically generated file. DO NOT MODIFY --]
[!-- Values from default config. --]
[string name="BUILD_TIME" translatable="false"]1471574224[/string]
[/resources]

И пусть тебя не смущает, что мы храним время в формате String. К сожалению, Android SDK не умеет хранить в ресурсах long, а в 32-битный integer время не влезет.
Создаем разные варианты сборки
Пожалуй, уже все Android-программисты знают о существовании встроенных типов сборок debug и release. Чуть меньше — о том, что можно создавать свои типы сборок. Еще меньше тех, кто дополнительно применяет productFlavors. Но давай по порядку.
Мы используем build types, чтобы иметь возможность собирать приложение с существенными отличиями. Эти отличия обычно связаны с тем, как мы собираем приложение: для отладки или для релиза, с обфускацией кода или без, каким сертификатом оно будет подписано.

buildTypes {

release {
minifyEnabled true // Включаем обфускацию
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-all.txt'
signingConfig signingConfigs.release // Указываем релизный конфиг для подписывания
}

debug {
minifyEnabled false // Отключаем обфускацию
signingConfig signingConfigs.debug // Указываем отладочный конфиг для подписывания
}

qa {
minifyEnabled false // Отключаем обфускацию
signingConfig signingConfigs.debug // Указываем отладочный конфиг для подписывания
testCoverageEnabled true // Включаем анализ покрытия тестами
}

}


Чтобы собрать нужный тип, выполняем команду gradle assemble<ИмяТипаСборки>, например gradle assembleDebug или gradle assembleQa


Есть два пути настройки Gradle. Ты можешь установить его на машину самостоятельно или использовать Gradle Wrapper внутри проекта. В первом случае Gradle будет доступен тебе глобально через команду gradle из консоли. Во втором случае сборку можно запускать через специальную программу-обертку — gradlew. Второй способ предпочтительнее, так как может работать с любой версией Gradle без переустановки. Тем более что при создании проекта в Android Studio этот способ работает по умолчанию. Подробнее о Gradle Wrapper ты можешь почитать по ссылке.


Product flavors дополняют build types и вносят еще один уровень гибкости в настройку сборки. Используй их, когда нужно, скажем так, не глобально изменить приложение, — это могут быть брендинг (иконки, цвета, тексты), окружение (адрес сервера, платформа, trial- или pro-версии).


productFlavors {

trial {
versionName "MyAwesomeApp-trial"
buildConfigField "String", "SERVER", '"https://trial.my-server.example"'
}

pro {
versionName "MyAwesomeApp-pro"
buildConfigField "String", "SERVER", '"https://pro.my-server.example"'
}
}
Добавил: javavirys ( 2018-08-14 10:19:54 )
Теги:Android Gradle JAVA
Рейтинг: + 0 -
Просмотров: 843

Специальные предложения