Разбиране на основите на 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 ще работят във фазата на Изпълнение, но всичко извън тези 2 блока ще бъде изпълнено по време на Конфигуриране.
Да приемем, че искате да изпълните задача с име anotherTask ще видите ред A1 -> Configuration phase от a1SampleTask отпечатан в изхода на конзолата за изпълнение. Конфигурирането на задачите се случва през цялото време, независимо от задачата, която сте избрали за изпълнение.
Свързване на задачите
Да приемем, че имате 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.
Приставката за скрипт е достатъчна за повечето от нашите предизвикателства. Ако искате да продължите по-нататък, като внедрите и споделите публично вашия плъгин, трябва да използвате двоичен плъгин. ShahRukh може да ви помогне с това!
Проектът на това ръководство
В случай, че искате да видите всичко по-горе и още някои свойства на Gradle Android, посетете моя примерен проект.
