Понимание основ build.gradle
Это не будет статья, содержащая расширенную информацию о Gradle и Groovy/Kotlin. Основная цель будет заключаться в том, чтобы предоставить основные «советы и рекомендации» для повседневных задач разработчика Android.
Что может быть хуже, чем пренебрежение файлом build.gradle? Имея два файла build.gradle, которыми можно пренебречь! Может ли все пойти еще хуже? Безусловно, вы можете добавить больше модулей в свое приложение, и вот вам больше файлов сборки, которыми можно пренебречь!
В чем разница между всеми этими файлами?
Существует файл Gradle верхнего уровня. В Android Studio вы увидите его как build.gradle (Project: project_name), а другие файлы сборки для модуля build.gradle (Module: project_name.module_name).
Файл сборки верхнего уровня предоставляет конфигурацию для самого Gradle до buildscript и для всех модулей проекта до allprojects.
Файл сборки для модуля предоставляет информацию о конфигурации и выполнении модуля, к которому он принадлежит.
Просмотреть все задачи Gradle в Android Studio
В Android Studio вы можете увидеть все задачи Gradle в этой части IDE.
Если вы не видите папку Tasks, я не могу дать вам больше информации о том, как заставить ее работать… но LeMimit определенно может показать вам путь.
Теперь, когда у вас есть Tasks, вы можете дважды щелкнуть, чтобы запустить любой из них.
Давайте код
В этом примере мы предполагаем, что у нас есть проект с двумя вариантами (simple, advanced).
Вставить библиотеки из общедоступного репо
Обычный способ вставить библиотеку — перейти в раздел dependencies файла сборки каждого модуля и написать implementation 'androidx.appcompat:appcompat:1.2.0'.
Зависимости на вкус
Мы можем добавить новую библиотечную зависимость для каждого варианта. Это можно сделать, написав simpleImplementation 'androidx.appcompat:appcompat:1.2.0', чтобы добавить зависимость для версии simple нашего приложения.
Вставка библиотек для локальной папки или репозитория
В некоторых уникальных обстоятельствах нам может потребоваться добавить зависимости из нашей локальной папки. Обычно мы добавляем библиотеку в папку libs модуля, который будем использовать.
Для нашего примера допустим, что у нас есть локальная библиотека balloon.aar.
Это библиотека skydoves/Balloon, которую я скачал для демонстрационных целей.
Если вы хотите добавить все библиотеки для всех вариантов в вашу папку libs, вы можете написать implementation fileTree(dir: 'libs', include:['*.aar']) в разделе dependencies файла сборки каждого модуля.
Помимо добавления библиотеки в виде файла, вы можете создать папку, которая будет вести себя как репозиторий. Мы должны написать flatDir { dirs “repo" } в файле сборки верхнего уровня, как показано ниже:
Теперь мы готовы добавить библиотеку, расположенную в папке repo, записав implementation (name:"balloon", ext:"aar") в раздел dependencies файла сборки каждого модуля.
Фазы Gradle
Gradle имеет 3 отдельных этапа сборки.
В этом разделе мы увидим, как писать инструкции по сборке для этапа Настройка и Выполнение.
doFirst и doLast перейдут в фазу Выполнение, но все, что находится за пределами этих двух блоков, будет выполнено во время Настройки.
Допустим, вы хотите запустить задачу с именем anotherTask. вы увидите строку A1 -> Configuration phase из a1SampleTask, напечатанную в выводе Run Console. Конфигурация задач происходит постоянно, независимо от того, какую задачу вы выбрали для выполнения.
Объединение задач
Допустим, у вас есть 2 задачи ( a1SampleTask, a2SampleTask), которые вы хотите выполнить с некоторой связью между ними.
Если вы хотите выполнить a2SampleTask, но a1SampleTask всегда должна выполняться раньше, вы можете связать их, привязав по одной к каждой другое (a2SampleTask.dependsOn(a1SampleTask)).
Гораздо более легкая связь — a2SampleTask.mustRunAfter(a1SampleTask). Когда вы выполняете только a2SampleTask, он не запускает a1SampleTask. Но если вы хотите выполнить a2SampleTask и a1SampleTask вместе, он всегда выполняет a1SampleTask перед a2SampleTask.
Динамические задачи
Некоторые задачи зависят от задач, которых не существует с самого начала. Некоторые задачи и свойства создаются позже, например, варианты приложений.
Вы не можете создать задачу так, как мы видели раньше, и работать с таким вариантом, как simpleDebugSampleTask. Если вы хотите запустить приложение после его установки (что заставляет вас зависеть от вариантов приложения), вы должны создать динамическую задачу, подобную этой:
В этом примере вы должны проверить variant и его задачу install, которая также является динамической, прежде чем создавать свою собственную задачу.
Реализация плагина
У нас есть 2 способа написать плагин для Gradle (бинарный плагин и плагин скрипта). Для этого примера мы собираемся создать динамическую задачу для изменения имени экспортированного apk-файла.
Создайте новый файл outputFilesHandling.gradle в вашем модуле app и создайте в нем динамическую задачу (для переименования экспортированного apk-файла).
Затем вы можете перейти к своему модулю app и применить эту задачу (apply from: outputFilesHandling.gradle"). Убедитесь, что вы используете apply from вместо apply plugin.
Плагина сценария достаточно для большинства наших задач. Если вы хотите пойти дальше, реализовав и опубликовав свой плагин, вам нужно использовать бинарный плагин. В этом поможет Шахрукх!
Проект этого руководства
Если вы хотите увидеть все вышеперечисленное и некоторые другие свойства Gradle для Android, посетите мой пример проекта.
