Android Gradle Plugin 3.0.0 (октябрь 2017 г.)
В плагин Android Gradle версии 3.0.0 внесен ряд изменений, направленных на решение проблем с производительностью крупных проектов.
Например, на примере проекта-шаблона с примерно 130 модулями и большим количеством внешних зависимостей (но без кода и ресурсов) можно наблюдать улучшение производительности, аналогичное следующему:
| Версия плагина для Android + версия Gradle | Android-плагин 2.2.0 + Gradle 2.14.1 | Android-плагин 2.3.0 + Gradle 3.3 | Android-плагин 3.0.0 + Gradle 4.1 |
|---|---|---|---|
Настройка (например, запуск команды ./gradlew --help ) | ~2 мин. | ~9 с | ~2,5 с |
| Изменение в Java на одну строку (изменение реализации) | ~2 мин 15 с | ~29 с | ~6,4 с |
Некоторые из этих изменений нарушают работу существующих сборок. Поэтому вам следует это учесть.
Необходимо приложить усилия для миграции вашего проекта перед использованием нового плагина.
Если вы не заметили описанных выше улучшений производительности, пожалуйста, сообщите об ошибке и приложите трассировку сборки, полученную с помощью Gradle Profiler .
Для работы этой версии плагина для Android требуются следующие компоненты:
| Минимальная версия | Версия по умолчанию | Примечания | |
|---|---|---|---|
| Грэдл | 4.1 | 4.1 | Для получения более подробной информации см. раздел «Обновление Gradle» . |
| Инструменты сборки SDK | 26.0.2 | 26.0.2 | Установите или настройте инструменты сборки SDK. С этим обновлением вам больше не нужно указывать версию инструментов сборки — плагин по умолчанию использует минимально необходимую версию. Таким образом, теперь вы можете удалить свойство android.buildToolsVersion. |
3.0.1 (ноябрь 2017 г.)
Это небольшое обновление для поддержки Android Studio 3.0.1, включающее в себя общие исправления ошибок и улучшения производительности.
Оптимизации
- Улучшенная параллельная обработка многомодульных проектов за счет детализированного графа задач.
- При внесении изменений в зависимости Gradle ускоряет сборку, не перекомпилируя модули, не имеющие доступа к API этой зависимости. Вам следует ограничить доступ других модулей к API зависимостей, используя новые параметры конфигурации зависимостей Gradle :
implementation,api,compileOnlyиruntimeOnly. - Более высокая скорость инкрементальной сборки благодаря DEX-кодированию для каждого класса. Теперь каждый класс компилируется в отдельный DEX-файл, и перекодированию подвергаются только измененные классы. Также следует ожидать повышения скорости сборки для приложений, которые устанавливают
minSdkVersionравным 20 или ниже и используют устаревший многофайловый DEX-код . - Улучшена скорость сборки за счет оптимизации определенных задач с использованием кэшированных результатов. Чтобы воспользоваться преимуществами этой оптимизации, необходимо сначала включить кэширование сборки Gradle .
- Улучшена инкрементальная обработка ресурсов с использованием AAPT2, который теперь включен по умолчанию. Если у вас возникли проблемы при использовании AAPT2, пожалуйста, сообщите об ошибке . Вы также можете отключить AAPT2, установив параметр
android.enableAapt2=falseв файлеgradle.propertiesи перезапустив демон Gradle, выполнив команду./gradlew --stopиз командной строки.
Новые функции
- Управление зависимостями с учетом вариантов . При сборке определенного варианта модуля плагин теперь автоматически сопоставляет варианты зависимостей локальных библиотечных модулей с вариантом собираемого модуля.
- Включает новый плагин модуля функций для поддержки Android Instant Apps и Android Instant Apps SDK (который можно загрузить с помощью менеджера SDK ). Чтобы узнать больше о создании модулей функций с помощью нового плагина, прочитайте статью «Структура мгновенного приложения с несколькими функциями» .
- Встроенная поддержка использования некоторых языковых возможностей Java 8 и библиотек Java 8. Jack устарел и больше не требуется , поэтому для использования улучшенной поддержки Java 8, встроенной в стандартный набор инструментов, следует сначала отключить Jack. Для получения дополнительной информации см. раздел «Использование языковых возможностей Java 8» .
Добавлена поддержка запуска тестов с помощью Android Test Orchestrator , что позволяет запускать каждый тест вашего приложения в рамках отдельного вызова Instrumentation. Поскольку каждый тест выполняется в собственном экземпляре Instrumentation, любое общее состояние между тестами не накапливается на процессоре или в памяти вашего устройства. И даже если один тест завершится с ошибкой, он остановит только свой собственный экземпляр Instrumentation, поэтому остальные тесты продолжат работать.
- Добавлен
testOptions.executionдля определения необходимости использования оркестровки тестов на устройстве. Если вы хотите использовать Android Test Orchestrator , необходимо указатьANDROID_TEST_ORCHESTRATOR, как показано ниже. По умолчанию это свойство установлено вHOST, что отключает оркестровку на устройстве и является стандартным методом запуска тестов.
Классный
android { testOptions { execution 'ANDROID_TEST_ORCHESTRATOR' } }
Котлин
android { testOptions { execution = "ANDROID_TEST_ORCHESTRATOR" } }
- Добавлен
Новая конфигурация зависимости
androidTestUtilпозволяет установить другой вспомогательный APK-файл для тестирования перед запуском инструментальных тестов, например, Android Test Orchestrator:Классный
dependencies { androidTestUtil 'com.android.support.test:orchestrator:1.0.0' ... }
Котлин
dependencies { androidTestUtil("com.android.support.test:orchestrator:1.0.0") ... }
Добавлена
testOptions.unitTests.includeAndroidResourcesдля поддержки модульных тестов, требующих ресурсов Android, таких как Roboelectric . Если установить это свойство вtrue, плагин выполнит слияние ресурсов, активов и манифеста перед запуском модульных тестов. После этого ваши тесты смогут проверить файлcom/android/tools/test_config.propertiesв classpath на наличие следующих ключей:android_merged_assets: абсолютный путь к каталогу объединенных ресурсов.Примечание: Для модулей библиотеки объединенные ресурсы не содержат ресурсы зависимостей (см. проблему #65550419 ).
android_merged_manifest: абсолютный путь к объединенному файлу манифеста.android_merged_resources: абсолютный путь к каталогу объединенных ресурсов, который содержит все ресурсы модуля и все его зависимости.android_custom_package: имя пакета конечного класса R. Если вы динамически изменяете идентификатор приложения, это имя пакета может не совпадать с атрибутомpackageв манифесте приложения.
- Поддержка шрифтов в качестве ресурсов (новая функция, представленная в Android 8.0 (уровень API 26) ).
- Поддержка APK-файлов с поддержкой определенных языков в Android Instant Apps SDK версии 1.1 и выше.
Теперь вы можете изменить выходной каталог для вашего внешнего проекта, собранного нативно, как показано ниже:
Классный
android { ... externalNativeBuild { // For ndk-build, instead use the ndkBuild block. cmake { ... // Specifies a relative path for outputs from external native // builds. You can specify any path that's not a subdirectory // of your project's temporary build/ directory. buildStagingDirectory "./outputs/cmake" } } }
Котлин
android { ... externalNativeBuild { // For ndk-build, instead use the ndkBuild block. cmake { ... // Specifies a relative path for outputs from external native // builds. You can specify any path that's not a subdirectory // of your project's temporary build/ directory. buildStagingDirectory = "./outputs/cmake" } } }
- Теперь при сборке нативных проектов из Android Studio можно использовать CMake версии 3.7 или выше .
Новая конфигурация зависимостей
lintChecksпозволяет создавать JAR-файлы, определяющие пользовательские правила проверки кода, и упаковывать их в ваши AAR- и APK-проекты.Ваши пользовательские правила линтинга должны принадлежать отдельному проекту, который выводит один JAR-файл и содержит только зависимости,
compileOnly. Другие модули приложений и библиотек могут затем зависеть от вашего проекта линтинга, используя конфигурациюlintChecks:Классный
dependencies { // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file // and package it with your module. If the module is an Android library, // other projects that depend on it automatically use the lint checks. // If the module is an app, lint includes these rules when analyzing the app. lintChecks project(':lint-checks') }
Котлин
dependencies { // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file // and package it with your module. If the module is an Android library, // other projects that depend on it automatically use the lint checks. // If the module is an app, lint includes these rules when analyzing the app. lintChecks(project(":lint-checks")) }
Изменения в поведении
- В Android-плагине 3.0.0 удалены некоторые API, и ваша сборка будет нарушена, если вы будете их использовать. Например, вы больше не можете использовать API Variants для доступа к объектам
outputFile()или использоватьprocessManifest.manifestOutputFile()для получения файла манифеста для каждого варианта. Чтобы узнать больше, прочитайте раздел «Изменения API» . - Теперь вам не нужно указывать версию инструментов сборки (поэтому вы можете удалить свойство
android.buildToolsVersion). По умолчанию плагин автоматически использует минимально необходимую версию инструментов сборки для той версии плагина Android, которую вы используете. - Теперь вы можете включить/отключить обработку PNG-файлов в блоке
buildTypes, как показано ниже. Обработка PNG-файлов включена по умолчанию для всех сборок, кроме отладочных, поскольку она увеличивает время сборки для проектов, содержащих много PNG-файлов. Поэтому, чтобы сократить время сборки для других типов сборок, вам следует либо отключить обработку PNG-файлов, либо преобразовать изображения в формат WebP .Классный
android { buildTypes { release { // Disables PNG crunching for the release build type. crunchPngs false } } }
Котлин
android { buildTypes { release { // Disables PNG crunching for the release build type. isCrunchPngs = false } } }
- Теперь плагин для Android автоматически собирает исполняемые файлы, которые вы настраиваете во внешних проектах CMake.
- Теперь необходимо добавить обработчики аннотаций в путь к классам обработчиков, используя конфигурацию зависимости
annotationProcessor. - Использование устаревшего
ndkCompileтеперь более ограничено. Вместо этого вам следует перейти на использование CMake или ndk-build для компиляции нативного кода, который вы хотите упаковать в свой APK. Чтобы узнать больше, прочитайте статью «Переход с ndkCompile» .