Mastering Gradle pentru Android: sarcini Gradle și Kotlin

Conţinut

Explorarea fișierelor de compilare Gradle
1. setări.gradle
2. build.gradle (nivel de proiect)
3. build.gradle (nivelul modulului)
Declararea dependențelor proiectului dvs.: biblioteci locale
Adăugarea unei dependențe de construire: depozite la distanță
Conectarea la un depozit la distanță
Declararea unei dependențe la distanță
Generarea mai multor APK-uri: Cum se creează variante de construire
Crearea unei sarcini personalizate Gradle
Construiește-ți proiectul cu ambalajul Gradle
Ce alte sarcini Gradle sunt disponibile?
Obținerea mai mult din Gradle: Adăugarea de pluginuri
Gradul Kotlin DSL
Înveliți

În loc de Java, XML sau Kotlin, aceste fișiere de compilare Gradle folosesc limbajul specific DSL (Baslow) bazat pe Groovy. Dacă nu sunteți familiarizați cu Groovy, atunci vom arunca o privire linie cu linie la fiecare dintre aceste fișiere de compilare Gradle, așa că până la sfârșitul acestui articol veți fi confortabil să citiți și să scrieți coduri Groovy simple.

Gradle își propune să vă ușureze viața, oferind un set de setări implicite pe care le puteți utiliza adesea cu configurația manuală minimă - atunci când sunteți gata să vă construiți proiectul, pur și simplu apăsați butonul „Rulați” de Android Studio și Gradle va începe procesul de construire Pentru dumneavoastră.

În ciuda abordării „convenției asupra configurației” a lui Gradle, dacă setările sale implicite nu îndeplinesc destul de bine nevoile dvs., atunci puteți personaliza, configura și extinde procesul de construire și chiar puteți regla setările Gradle pentru a îndeplini sarcini foarte specifice.

Deoarece scripturile Gradle sunt conținute în propriile fișiere, puteți modifica procesul de construire a aplicației în orice moment, fără a fi necesar să atingeți codul sursă al aplicației. În acest tutorial, vom modifica procesul de construire utilizând arome, variante de construire și o sarcină personalizată Gradle - totul fără vreodată atingând codul aplicației noastre.

Explorarea fișierelor de compilare Gradle

De fiecare dată când creați un proiect, Android Studio va genera aceeași colecție de fișiere de compilare Gradle. Chiar dacă importați un proiect existent în Android Studio, va fi valabil încă creați aceste fișiere Gradle exact și adăugați-le la proiectul dvs.

Pentru a începe să înțelegeți mai bine Gradle și sintaxa Groovy, să aruncăm o privire linie cu linie la fiecare dintre fișierele de construire Gradle din Android.

1. setări.gradle

Fișierul settings.gradle este locul în care veți defini toate modulele aplicației după nume, folosind cuvântul cheie „include”. De exemplu, dacă ai avea un proiect format dintr-o „aplicație” și un „secondModule”, atunci fișierul tău settings.gradle ar arăta astfel:

include: app,: secondmodule rootProject.name = MyProject

În funcție de dimensiunea proiectului dvs., acest fișier poate fi considerabil mai lung.

Pe parcursul procesului de construire, Gradle va examina conținutul fișierului setări.gradle al proiectului dvs. și va identifica toate modulele pe care acesta trebuie să le includă în procesul de construire.

2. build.gradle (nivel de proiect)

Fișierul build.gradle la nivel de proiect se află în directorul rădăcină al proiectului dvs. și conține setări la care se va aplica toate modulele dvs. (denumite și „proiecte” de Gradle).

Ar trebui să utilizați acest fișier pentru a defini eventualele pluginuri, depozite, dependențe și opțiuni de configurare care se aplică fiecărui modul din întregul proiect Android. Rețineți că, dacă definiți orice sarcini Gradle în fișierul build.gradle la nivel de proiect, atunci este încă posibil să înlocuiți sau să extindeți aceste sarcini pentru module individuale, prin editarea corespunzătoare a acestora Nivelul modulului fișier build.gradle.

Un fișier tip build.gradle la nivel de proiect va arăta astfel:

buildscript {repositorii {google () jcenter ()} dependențe {classpath com.android.tools.build:gradle:3.5.0-alpha06 // NOTĂ: Nu plasați dependențele de aplicație aici; ele aparțin // în modulul individual build.gradle files}} allprojects {repositories {google () jcenter ()}} task clean (tip: Șterge) {șterge rootProject.buildDir}

Acest fișier build.gradle la nivel de proiect este împărțit în următoarele blocuri:

Buildscript. Aceasta conține setări care sunt necesare pentru a realiza compilarea.
Repozitorii. Gradle este responsabilă de localizarea dependențelor proiectului dvs. și de a le face disponibile în construcția dvs. Cu toate acestea, nu toate dependențele provin din același depozit, așa că va trebui să definiți toate depozitele pe care Gradle ar trebui să le caute, pentru a prelua dependențele proiectului.
Dependențe. Această secțiune conține dependențele dvs. de plugin, care sunt descărcate și stocate în memoria cache locală. Tu ar trebui nu definiți orice dependență de module din acest bloc.
Allprojects. Aici veți defini depozitele care ar trebui să fie disponibile toate din modulele proiectului dvs.

3. build.gradle (nivelul modulului)

Acesta este fișierul build.gradle la nivel de modul, care este prezent în fiecare modul pe întregul proiect. Dacă proiectul dvs. Android constă din mai multe module, atunci acesta va consta, de asemenea, din mai multe fișiere build.gradle la nivel de modul.

Fiecare fișier build.gradle la nivel de modul conține numele pachetului, numele versiunii și codul versiunii, plus SDK-ul minim și țintă pentru acest modul.

Un fișier build.gradle la nivel de modul poate avea, de asemenea, propriul său set unic de instrucțiuni de construire și dependențe. De exemplu, dacă creați o aplicație cu o componentă Wear OS, proiectul dvs. Android Studio va consta dintr-un smartphone / tabletă separat și un modul Wear - din moment ce vizează dispozitive complet diferite, aceste module au un drastic diferit dependențe!

Un fișier de bază build.gradle la nivel de modul va arăta de obicei în felul acesta:

apply plugin: com.android.application android {compileSdkVersion 28 defaultConfig {applicationId "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 versionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner.AndilesJUneritAndroidJUn getDefaultProguardFile (proguard-android-optimize.txt), proguard-rules.pro}}} dependențe {implement fileTree (dir: libs, include:) implementare androidx.appcompat: appcompat: 1.0.2 implementare androidx.constraintlayout: constraintlayout: 1.1. 3 testImplementation junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: espresso-core: 3.1.1}

Să aruncăm o privire mai atentă la fiecare din aceste secțiuni:

aplicați plugin. Aceasta este o listă a pluginurilor necesare pentru a construi acest modul. Pluginul com.android.application este necesar pentru a configura procesul de compilare specific Android, astfel încât acesta este adăugat automat.
Android. Aici trebuie să plasați toate opțiunile specifice platformei modulului.
compileSdkVersion. Acesta este nivelul API cu care este compilat acest modul. Nu puteți utiliza funcții dintr-o API mai mare decât această valoare.
buildToolsVersion. Aceasta indică versiunea compilatorului. În Gradle 3.0.0 și o versiune ulterioară, buildToolsVersion este opțional; dacă nu specificați o valoare buildToolsVersion, Android Studio va fi implicit la cea mai recentă versiune a Instrumentelor de construire.
defaultConfig. Acesta conține opțiuni care vor fi aplicate tuturor versiunilor de compilare ale aplicației dvs., cum ar fi versiunile de depanare și versiune.
applicationId. Acesta este identificatorul unic al aplicației dvs.
minSdkVersion. Acest parametru definește cel mai scăzut nivel de API suportat de acest modul.
targetSdkVersion. Acesta este nivelul maxim de API cu care a fost testată cererea dvs. În mod ideal, ar trebui să testați aplicația folosind cea mai recentă API, ceea ce înseamnă că valoarea targetSdkVersion va fi întotdeauna egală cu valoarea compileSdkVersion.
versionCode. Aceasta este o valoare numerică pentru versiunea dvs. de aplicație.
versionName. Acesta este un șir ușor de utilizat, care reprezintă versiunea dvs. de aplicație.
buildTypes. În mod implicit, Android acceptă două tipuri de compilare: debug și release. Puteți utiliza blocurile „debug” și „release” pentru a specifica setările specifice tipului aplicației dvs.
dependențe. De aici veți defini orice biblioteci de care depinde acest modul.

Declararea dependențelor proiectului dvs.: biblioteci locale

Puteți pune la dispoziție funcționalități suplimentare proiectelor dvs. Android, adăugând una sau mai multe dependențe de proiect. Aceste dependențe pot fi locale sau pot fi stocate într-un depozit la distanță.

Pentru a declara o dependență de un fișier JAR local, va trebui să adăugați JAR în directorul „libs” al proiectului.

Puteți modifica apoi fișierul build.gradle la nivel de modul pentru a declara o dependență de acest fișier. De exemplu, aici declarăm o dependență de un JAR „bibliotecar”.

fișiere de implementare (libs / mylibrary.jar)

În mod alternativ, dacă folderul dvs. „libs” conținea mai multe JAR-uri, atunci ar putea fi mai ușor să afirmați că proiectul dvs. depinde de toate fișierele din folderul „libs”, de exemplu:

file file de implementare Tree (dir: libs, include:)

Adăugarea unei dependențe de construire: depozite la distanță

Dacă o bibliotecă se află într-un depozit la distanță, va trebui să parcurgeți următorii pași:

Definiți depozitul în care se află această dependență.
Declarați dependența individuală.

Conectarea la un depozit la distanță

Primul pas este să îi spui lui Gradle ce depozit (sau depozite) trebuie să verifice, pentru a prelua toate dependențele proiectului tău. De exemplu:

depozite {google () jcenter ()}}

Aici, linia „jcenter ()” asigură că Gradle va verifica depozitul JCenter, care este un depozit public gratuit, găzduit la bintray.

În mod alternativ, dacă dvs. sau organizația dvs. întrețineți un depozit personal, ar trebui să adăugați adresa URL a acestui depozit la declarația de dependență. Dacă depozitul este protejat cu parolă, va trebui să furnizați și informațiile de conectare, de exemplu:

depozite {mavenCentral () maven {// Configurați URL-ul țintă // url "http://repo.mycompany.com/myprivaterepo"} maven {credențiale {nume utilizator myUsername parola myPassword} url "http://repo.mycompany.com / myprivaterepo "}

Dacă o dependență este prezentă în mai multe depozite, atunci Gradle va selecta cea mai „bună” versiune a acestei dependențe, bazată pe factori precum vârsta fiecărui depozit și versiunea statică.

Declararea unei dependențe la distanță

Următorul pas este declararea dependenței din fișierul dvs. build.gradle la nivel de modul. Adăugați aceste informații la blocul „dependențe”, folosind una dintre următoarele:

Punerea în aplicare. Aceasta este o dependență normală de care ai nevoie ori de câte ori îți construiești proiectul. O dependență de „implementare” va fi prezentă toate construirea ta.
Testimplementation. Aceasta este o dependență care este necesară pentru a compila sursa de testare a aplicației și pentru a rula teste bazate pe JVM. Când marcați o dependență drept „Testimplementation”, Gradle va ști că nu trebuie să execute sarcini pentru această dependență în timpul unei compilări normale, ceea ce poate ajuta la reducerea timpului de construire.
Androidtestimplementation. Aceasta este o dependență care este necesară atunci când executați teste pe un dispozitiv, de exemplu, cadrul Espresso este o „implementare AndroidTest comună”.

Definim o dependență la distanță, folosind unul dintre cuvintele cheie de mai sus, urmate de grupul, numele și atributele versiunii dependenței, de exemplu:

dependences {implement fileTree (dir: libs, include:) implementare androidx.appcompat: appcompat: 1.0.2 implementare androidx.constraintlayout: constraintlayout: 1.1.3 testImplementation junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: espresso-core: 3.1.1}

Generarea mai multor APK-uri: Cum se creează variante de construire

Uneori, poate fi necesar să creați mai multe versiuni ale aplicației. De exemplu, poate doriți să lansați o versiune gratuită și o versiune plătită, care include câteva funcții suplimentare.

Aceasta este o sarcină de construire cu care Gradle vă poate ajuta, așadar, să ne uităm la modul în care veți modifica procesul de construire pentru a crea mai multe APK-uri dintr-un singur proiect:

Deschideți fișierul dvs. strings.xml și ștergeți șirul de nume al aplicației originale.
Apoi, definiți numele fiecărei arome de produs pe care doriți să le creați; în acest caz, folosesc:

Aplicația mea gratuită Aplicația mea plătită

Deschideți fișierul dvs. AndroidManifest.xml și înlocuiți android: label = ”@ string / app_name” cu:

android: label = "$ {appName}"

Deschideți fișierul build.gradle la nivel de modul și adăugați următoarele în blocul „Android”:

saveDimensiuni "mode" productFlavors {free {dimension "mode" applicationIdSuffix ".free" manifestPlaceholders =} plătit {dimensiunea "mode" applicationIdSuffix ".pagat" manifestPlaceholders =}}}

Să dezvăluim ce se întâmplă aici:

flavorDimensions. Pluginul Android creează variante de compilare combinând arome de diferite dimensiuni. Aici, creăm o dimensiune de aromă constând din versiunile „gratuite” și „plătite” ale aplicației noastre. Pe baza codului de mai sus, Gradle va genera patru variante de compilare: paidDebug, paidRelease, freeDebug și freeRelease.
productFlavors. Aceasta specifică o listă de arome și setările lor, care în codul de mai sus sunt „plătite” și „gratuite”.
Gratuit / plătit. Acestea sunt numele celor două arome ale produselor noastre.
Dimensiune. Trebuie să specificăm o valoare a parametrului „dimensiune”; în acest caz, folosesc „modul”.
applicationIdSuffix. Din moment ce dorim să creăm mai multe versiuni ale aplicației noastre, trebuie să oferim fiecărui APK un identificator de aplicație unic.
manifestPlaceholders. Fiecare proiect are un singur fișier Manifest care conține informații importante despre configurația proiectului. Atunci când creați mai multe variante de construire, de obicei doriți să modificați unele dintre aceste proprietăți Manifest la momentul construirii. Puteți utiliza fișierele de construire Gradle pentru a specifica intrările unice ale Manifestului pentru fiecare variantă de construire, care vor fi apoi introduse în Manifestul dvs. la momentul construirii. În codul de mai sus, modificăm valoarea „appName” în funcție de faptul că Gradle creează versiunea gratuită sau plata plătită a aplicației noastre.

Crearea unei sarcini personalizate Gradle

Uneori poate fi necesar să personalizați procesul de construire, folosind Gradle sarcini.

O sarcină este o colecție numită de acțiuni pe care Gradle le va executa pe măsură ce execută o compilare, de exemplu, generând un Javadoc. Gradle acceptă în mod implicit o mulțime de sarcini, dar puteți crea, de asemenea, sarcini personalizate, care pot fi utile dacă aveți în minte un set foarte specific de instrucțiuni de construire.

În această secțiune, vom crea o sarcină Gradle personalizată, care va repeta toate variantele de construire a proiectului nostru (paidDebug, paidRelease, freeDebug și freeRelease), vom crea o dată și o dată și apoi vom adăuga aceste informații la fiecare APK generat.

Deschideți fișierul dvs. build.gradle la nivel de modul și adăugați următoarele:

task addDateAndTime () {// Iterate prin toate variantele de construire de ieșire // android.applicationVariants.all {varianta -> // Iterate prin toate fișierele APK // variant.outputs.all {output -> // Creați o instanță de data și ora curente, în formatul specificat // def dateAndTime = new Date (). format ("aaaa-MM-dd: HH-mm") // Adăugați aceste informații la numele de fișier al APK // def fileName = variantă. nume + "_" + dateAndTime + ".apk" output.outputFileName = fileName}}}

În continuare, trebuie să-i spunem lui Gradle cand ar trebui să execute această sarcină. În timpul unei compilări, Gradle identifică tot ce are nevoie pentru a descărca și toate sarcinile pe care trebuie să le execute și le aranjează într-un grafic Acyclic direcționat (DAG). Gradle va executa apoi toate aceste sarcini, în conformitate cu ordinea definită în DAG-ul său.

Pentru aplicația mea, voi folosi metoda „whenReady”, care asigură că sarcina noastră va fi apelată după ce DAG-ul va fi completat, iar Gradle va fi gata să înceapă să-și execute sarcinile.

Adăugați următoarele în fișierul dvs. build.gradle la nivel de modul:

// Executați această sarcină // gradle.taskGraph.whenReady {addDateAndTime}

Să ne punem sarcina personalizată și codul nostru de variantă pentru testare, construind acest proiect folosind o comandă Gradle.

Construiește-ți proiectul cu ambalajul Gradle

Emiti comenzi Gradle folosind învelitorul Gradle („gradlew”). Acest script este modalitatea preferată de a porni o construire Gradle, deoarece face executarea independenței de versiunea dvs. Gradle. Această separare poate fi utilă dacă colaborezi cu alții care nu au neapărat instalată aceeași versiune a Gradle.

Când emiteți comenzile de învelire Gradle, veți folosi „gradlew” pentru sistemele de operare asemănătoare Unix, inclusiv macOS și „gradlew.bat” pentru Windows. Am un Mac, așa că voi folosi comenzile „gradlew”.

Puteți emite comenzi Gradle din interiorul Android Studio:

În bara de instrumente Android Studio, selectați „Vizualizare> Instrumente Windows> Terminal.” Acesta deschide un panou Terminal de-a lungul părții de jos a ferestrei IDE.
Introduceți următoarea comandă în terminal:

./gradlew build

Android Studio ar trebui să arate așa:

Apăsați tasta „Enter” de pe tastatură. Gradle va construi acum proiectul tău.

Gradle stochează toate APK-urile generate în directorul app / build / outputs / apk al proiectului dvs., așa că navigați la acest director. Dosarul „APK” ar trebui să conțină mai multe foldere și subfoldere; asigurați-vă că Gradle a generat un APK pentru fiecare dintre variantele de compilare și că informațiile corecte despre data și ora au fost adăugate la fiecare fișier.

Ce alte sarcini Gradle sunt disponibile?

În plus față de orice sarcini personalizate pe care le-ați putea crea, Gradle acceptă o listă de sarcini predefinite în afara casetei. Dacă sunteți curios să vedeți exact ce sarcini sunt disponibile, atunci:

Deschideți fereastra Terminal Android Studio, dacă nu este deja deschisă (selectând „Vizualizare> Instrumente Windows> Terminal” din bara de instrumente Android Studio).
Introduceți următoarele în terminal:

./gradlew -q sarcini

Apăsați tasta „Enter” de pe tastatură.

Această sarcină „sarcini” va fi rulată acum, iar după câteva momente Terminalul va afișa o listă a tuturor sarcinilor disponibile pentru acest proiect, completată cu o scurtă descriere a fiecărei sarcini.

Obținerea mai mult din Gradle: Adăugarea de pluginuri

Gradle se livrează cu o serie de pluginuri preinstalate, dar puteți extinde Gradle adăugând noi pluginuri. Aceste plugin-uri fac noi sarcini disponibile proiectelor dvs. Android, de exemplu, plugin-ul Java include activități care vă permit să compilați codul sursă Java, să rulați teste de unitate și să creați un fișier JAR, cum ar fi „compileJava”, „compileText”, „jar”. „Javadoc” și „curat”.

Pentru a aplica un plugin, adăugați declarația „aplicați plugin” în fișierul dvs. build.gradle la nivel de modul, urmată de numele pluginului. De exemplu, aici aplicăm pluginul Java:

aplicați plugin: java

Dacă sunteți curioși să vedeți ce pluginuri sunt disponibile, consultați căutarea pluginului Gradle, care oferă un registru complet al pluginurilor Gradle.

Gradul Kotlin DSL

În mod implicit, veți scrie scripturile dvs. de compilare Gradle folosind Groovy DSL, dar dacă sunteți unul dintre numeroșii dezvoltatori care au adoptat Kotlin pentru dezvoltarea Android, atunci preferați să scrieți scripturile de compilare în Kotlin.

Spre deosebire de Groovy, Kotlin este un limbaj de programare scris tipic, deci dacă faceți comutarea, atunci fișierele de compilare vor fi compatibile cu funcțiile de completare automată și de navigare a codului sursă de la Android Studio. În plus, trecerea de la Groovy la Kotlin înseamnă că veți folosi același limbaj de programare în cadrul proiectului dvs., ceea ce poate face dezvoltarea mai simplă - în special dacă nu sunteți prea familiar cu Groovy!

Dacă doriți să începeți să scrieți logica de construire în Kotlin, atunci va trebui să configurați DSL Gradle Kotlin și să urmați instrucțiunile din ghidul de migrare.

Înveliți

În acest articol, am explorat instrumentul de automatizare și gestionare a dependenței Android Studio. Am examinat modul în care Gradle automatizează procesul de construire în afara cazului și cum puteți modifica procesul de construire modificând fișierele de construire Gradle ale proiectului dvs., inclusiv crearea de sarcini Gradle personalizate și generarea mai multor variante de construire dintr-un singur proiect.

Ați extins Gradle pentru a automatiza alte părți ale procesului de construire Android? Spuneți-ne în comentariile de mai jos!