Mastering Gradle per a Android: tasques Gradle i Kotlin

Content

Explorant els fitxers de creació de Gradle
1. settings.gradle
2. build.gradle (nivell de projecte)
3. build.gradle (nivell de mòdul)
Declaració de les dependències del vostre projecte: biblioteques locals
Afegir una dependència de creació: repositoris remots
Connexió a un dipòsit remot
Declaració d’una dependència remota
Generació de diversos APK: Com crear variants de creació
Creació d'una tasca Gradle personalitzada
Crea el teu projecte amb l’embolcall Gradle
Quines altres tasques de Gradle hi ha disponibles?
Treure més profit de Gradle: Afegir complements
El DSL Gradle Kotlin
Embalatge

En lloc de Java, XML o Kotlin, aquests fitxers de creació de Gradle utilitzen el llenguatge específic (DSL) basat en Groovy. Si no coneixeu Groovy, examinarem línia per línia cadascun d’aquests fitxers de creació de Gradle, així que al final d’aquest article us resultarà còmode llegir i escriure simple codi Groovy.

Gradle pretén facilitar la vostra vida, proporcionant un conjunt de configuracions predeterminades que sovint podeu utilitzar amb una configuració manual mínima. Quan esteu preparat per crear el vostre projecte, simplement premeu el botó "Executar" d'Android Studio i Gradle iniciarà el procés de creació. per tu.

Malgrat l'enfocament de "convenció sobre configuració" de Gradle, si la configuració predeterminada no compleix les vostres necessitats, podeu personalitzar, configurar i ampliar el procés de creació i, fins i tot, modificar la configuració de Gradle per realitzar tasques molt específiques.

Atès que els scripts de Gradle es troben en els seus propis fitxers, podeu modificar el procés de creació de l'aplicació en qualsevol moment sense necessitat de tocar el codi font de l'aplicació. En aquest tutorial, modificarem el procés de creació mitjançant sabors, variants de creació i una tasca Gradle personalitzada, tot sense sempre tocant el nostre codi d’aplicació.

Explorant els fitxers de creació de Gradle

Cada vegada que creeu un projecte, Android Studio generarà la mateixa col·lecció de fitxers de creació de Gradle. Tot i que importeu un projecte existent a Android Studio, serà així encara crea aquests fitxers Gradle exactament i afegeix-los al teu projecte.

Per començar a tenir una millor comprensió de Gradle i la sintaxi de Groovy, anem a fer una ullada de línia per línia a cadascun dels fitxers de creació de Gradle d'Android.

1. settings.gradle

El fitxer settings.gradle és el que definireu tots els mòduls de la vostra aplicació per nom, mitjançant la paraula clau "inclou". Per exemple, si teniu un projecte format per una "aplicació" i un "segonModule", el fitxer settings.gradle tindria un aspecte així:

incloure: app,: secondmodule rootProject.name = MyProject

Segons la mida del vostre projecte, aquest fitxer pot ser considerablement més llarg.

Durant el procés de creació, Gradle examinarà el contingut del fitxer settings.gradle del projecte i identificarà tots els mòduls que ha d’incloure en el procés de creació.

2. build.gradle (nivell de projecte)

El fitxer build.gradle a nivell de projecte es troba al directori arrel del projecte i conté la configuració a la qual s'aplicarà tot els vostres mòduls (també anomenats "projectes" de Gradle).

Heu d'utilitzar aquest fitxer per definir tots els plugins, dipòsits, dependències i opcions de configuració que s'apliquen a tots els mòduls del vostre projecte Android. Tingueu en compte que si definiu qualsevol tasca de Gradle dins del fitxer build.gradle a nivell de projecte, encara serà possible substituir o ampliar aquestes tasques per a mòduls individuals, editant-ne les corresponents nivell de mòdul fitxer build.gradle.

Un fitxer build.gradle típic a nivell de projecte semblarà així:

buildscript {repositories {google () jcenter ()} dependències {classpath com.android.tools.build:gradle:3.5.0-alpha06 // NOTA: No col·loqueu aquí les vostres dependències de l'aplicació; pertanyen // als mòduls individuals build.gradle files}} allprojects {repositories {google () jcenter ()}} tasca neta (tipus: Eliminar) {delete rootProject.buildDir}

Aquest fitxer build.gradle a nivell de projecte es divideix en els blocs següents:

Buildscript. Conté configuracions que són necessàries per realitzar la creació.
Repositoris Gradle és responsable de localitzar les dependències del vostre projecte i fer-les disponibles a la vostra creació. Tot i això, no totes les dependències provenen del mateix dipòsit, per la qual cosa haureu de definir tots els dipòsits que hauria de cercar Gradle per tal de recuperar les dependències del vostre projecte.
Dependències. Aquesta secció conté les vostres dependències del complement, que es descarreguen i s’emmagatzemen a la memòria cau local. Hauries no definiu qualsevol dependència del mòdul dins d'aquest bloc.
Tots els projectes. Aquí és on definiu els repositoris als quals haurien d’estar disponibles tot dels mòduls del vostre projecte.

3. build.gradle (nivell de mòdul)

Aquest és el fitxer build.gradle a nivell de mòdul que està present en tots els mòduls al llarg del vostre projecte. Si el vostre projecte Android consta de diversos mòduls, també constarà de fitxers build.gradle a nivell de mòduls múltiples.

Cada fitxer build.gradle a nivell de mòdul conté el nom del paquet del projecte, el nom de versió i el codi de versió, a més del SDK mínim i objectiu d’aquest mòdul en concret.

Un fitxer build.gradle a nivell de mòdul també pot tenir el seu propi conjunt d’instruccions i dependències de creació. Per exemple, si creeu una aplicació amb un component Wear OS, el vostre projecte Android Studio constarà d’un mòdul de smartphone / tauleta i un mòdul Wear separats, ja que s’orienten per a dispositius completament diferents, aquests mòduls tenen un canvi dràsticament diferent. dependències!

Un fitxer bàsic build.gradle a nivell de mòdul normalment semblarà així:

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}}} dependències {implement fileTree (dir: libs, include:) implementació androidx.appcompat: appcompat: 1.0.2 implementació 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}

Analitzem de manera detallada cadascuna d’aquestes seccions:

Aplica plugin. Aquesta és una llista dels complements necessaris per crear aquest mòdul. El complement com.android.application és necessari per configurar el procés de creació específic per a Android, de manera que s’afegeix automàticament.
androide. Aquí és on heu de posar totes les opcions específiques de la plataforma del mòdul.
compileSdkVersion. Aquest és el nivell d’API amb què es compila aquest mòdul. No podeu utilitzar funcions d’una API superior a aquest valor.
buildToolsVersion. Això indica la versió del compilador. A Gradle 3.0.0 i versions posteriors, buildToolsVersion és opcional; si no especifiqueu un valor buildToolsVersion, Android Studio serà per defecte a la versió més recent de Eines de creació.
defaultConfig. Inclou opcions que s'aplicaran a totes les versions de creació de l'aplicació, com ara les versions de depuració i publicació.
applicationId. Aquest és l'identificador únic de l'aplicació.
minSdkVersion. Aquest paràmetre defineix el nivell més baix d’API que suporta aquest mòdul.
targetSdkVersion. Aquest és el nivell màxim d’API amb què s’ha provat la vostra aplicació. L’ideal seria que hagueu de provar l’aplicació amb l’última API, cosa que significa que el valor targetSdkVersion sempre serà igual al valor compileSdkVersion.
versionCode. Aquest és un valor numèric per a la versió de la vostra aplicació.
versionName Es tracta d’una cadena fàcil d’utilitzar, que representa la versió de l’aplicació.
buildTypes. De manera predeterminada, Android admet dos tipus de creació: depuració i alliberament. Podeu utilitzar els blocs de "depuració" i "alliberament" per especificar la configuració específica del tipus de l'aplicació.
dependències. Aquí és on definireu les biblioteques de les quals depèn aquest mòdul.

Declaració de les dependències del vostre projecte: biblioteques locals

Podeu posar a l’abast una o més dependències del projecte mitjançant una funcionalitat addicional disponible als vostres projectes Android. Aquestes dependències poden ser locals o es poden emmagatzemar en un dipòsit remot.

Per declarar una dependència d’un fitxer JAR local, haureu d’afegir aquesta JAR al directori “libs” del vostre projecte.

A continuació, podeu modificar el fitxer build.gradle a nivell de mòdul per declarar una dependència d'aquest fitxer. Per exemple, aquí estem declarant una dependència d’un JAR de “mylibrary”.

fitxers d'implementació (libs / mylibrary.jar)

Alternativament, si la vostra carpeta "libs" contenia diverses JAR, pot ser més fàcil afirmar que el vostre projecte depèn de tots els fitxers ubicats a la carpeta "libs", per exemple:

file file d'implementació (dir: libs, inclou:)

Afegir una dependència de creació: repositoris remots

Si una biblioteca es troba en un dipòsit remot, haureu de complir els passos següents:

Definiu el repositori on es troba aquesta dependència.
Declarar la dependència individual.

Connexió a un dipòsit remot

El primer pas és dir a Gradle quin dipòsit (o repositoris) ha de comprovar, per recuperar totes les dependències del vostre projecte. Per exemple:

repositoris {google () jcenter ()}}

Aquí, la línia "jcenter ()" assegura que Gradle comprovarà el dipòsit de JCenter, que és un dipòsit públic gratuït allotjat a bintray.

Alternativament, si vostè o la seva organització mantenen un dipòsit personal, haureu d'afegir l'URL d'aquest dipòsit a la declaració de dependència. Si el dipòsit està protegit amb contrasenya, també haureu de proporcionar la vostra informació d’inici de sessió, per exemple:

repositoris {mavenCentral () maven {// Configurar la URL de destinació // url "http://repo.mycompany.com/myprivaterepo"} maven {credencials {nom d'usuari myUsername contrasenya myPassword} url "http://repo.mycompany.com / myprivaterepo "}

Si hi ha una dependència dins de diversos dipòsits, Gradle seleccionarà la versió "millor" d'aquesta dependència, basada en factors com l'edat de cada dipòsit i la versió estàtica.

Declaració d’una dependència remota

El següent pas és declarar la dependència del fitxer build.gradle a nivell de mòdul. Afegiu aquesta informació al bloc "dependències" mitjançant qualsevol de les accions següents:

Implementació Es tracta d’una dependència normal que necessiteu sempre que creeu el vostre projecte. Una dependència de "implementació" estarà present tot les seves construccions.
Implementació de la prova. Aquesta és una dependència necessària per compilar la font de prova de la sol·licitud i executar proves basades en JVM. Quan marqueu una dependència com a "Testimplementation", Gradle sabrà que no haurà d'executar tasques per a aquesta dependència durant una creació normal, cosa que pot ajudar a reduir el temps de creació.
Implementació d'Android. Es tracta d’una dependència que és necessària quan s’executen proves en un dispositiu, per exemple, el marc Espresso és una “implementació Androidestest habitual”.

Definim una dependència remota mitjançant una de les paraules clau anteriors, seguida dels atributs de grup, nom i versió de la dependència, per exemple:

dependencies {implement fileTree (dir: libs, include:) implementació androidx.appcompat: appcompat: 1.0.2 implementació 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}

Generació de diversos APK: Com crear variants de creació

De vegades, potser haureu de crear diverses versions de l'aplicació. Per exemple, és possible que vulgueu publicar una versió gratuïta i una versió de pagament, que inclou algunes funcions addicionals.

Aquesta és una tasca de creació amb la qual Gradle us pot ajudar, així que anem a veure com modificareu el procés de creació per crear diversos APK a partir d’un sol projecte:

Obre el fitxer strings.xml i suprimeix la cadena de nom de l'aplicació original.
A continuació, definiu els noms de cada sabor de producte que voleu crear; en aquest cas, estic fent servir:

La meva aplicació gratuïta La meva aplicació de pagament

Obriu el fitxer AndroidManifest.xml i substituïu Android: label = "@ string / app_name" per:

Android: label = "$ {appName}"

Obriu el fitxer build.gradle a nivell de mòdul i afegiu el següent al bloc "Android":

tasteDimensions "mode" productFlavors {free {dimension "mode" applicationIdSuffix ".free" manifestPlaceholders =} pagat {dimension "mode" applicationIdSuffix ".paid" manifestPlaceholders =}}}

Anem a desglossar el que passa aquí:

saborDimensions. El complement d'Android crea variants de creació combinant sabors des de diferents dimensions. Aquí, creem una dimensió de sabor que consisteix en versions “gratuïtes” i “de pagament” de la nostra aplicació. A partir del codi anterior, Gradle generarà quatre variants de creació: paidDebug, paidRelease, freeDebug i freeRelease.
Sabors de producte Això especifica una llista de sabors i la seva configuració, que en el codi anterior es paguen i són gratuïts.
Gratuït / de pagament. Aquests són els noms dels nostres dos sabors de productes.
Dimensió. Hem d’especificar un valor de paràmetre “dimensió”; en aquest cas, faig servir "mode".
applicationIdSuffix. Com que volem crear diverses versions de la nostra aplicació, hem de donar a cada APK un identificador d’aplicació únic.
manifestPlaceholders. Cada projecte té un fitxer Manifest únic que conté informació important sobre la configuració del vostre projecte. Quan creeu diverses variants de creació, normalment haureu de modificar algunes d’aquestes propietats del manifest a l’hora de creació. Podeu utilitzar els fitxers de creació de Gradle per especificar entrades de manifest exclusives per a cada variant de creació, que s'inseriran al manifest a l'hora de creació. Al codi anterior, estem modificant el valor "appName" segons si Gradle crea la versió gratuïta o de la nostra aplicació de pagament.

Creació d'una tasca Gradle personalitzada

De vegades és possible que necessiteu personalitzar el procés de creació mitjançant Gradle tasques.

Una tasca és una col·lecció anomenada d’accions que Gradle executarà a mesura que realitzi una compilació, per exemple generant un Javadoc. De manera predeterminada, Gradle admet moltes tasques, però també podeu crear tasques personalitzades, que poden ser útils si teniu en compte un conjunt molt específic d’instruccions de creació.

En aquesta secció, crearem una tasca Gradle personalitzada que iterarà a través de totes les variants de creació del nostre projecte (paidDebug, paidRelease, freeDebug i freeRelease), crearem una data i una hora de selecció i, a continuació, afegirem aquesta informació a cada APK generat.

Obriu el fitxer build.gradle a nivell de mòdul i afegiu el següent:

tasca addDateAndTime () {// Iterate a través de totes les variants de build de sortida // android.applicationVariants.all {variant -> // Iterate a través de tots els fitxers APK // variant.outputs.all {output -> // Crea una instància de data i hora actuals, en el format especificat // def dateAndTime = new Date (). format ("aaaa-MM-dd: HH-mm") // Afegiu aquesta informació al nom de fitxer de l'APK // def fileName = variant. nom + "_" + dataAndTime + ".apk" output.outputFileName = nom_arxiu}}}

A continuació, hem de dir-li a Gradle Quan hauria d'executar aquesta tasca. Durant la creació, Gradle identifica tot el que necessita per descarregar i totes les tasques que ha d'executar i les ordena en un gràfic acíclic dirigit (DAG). Gradle executarà totes aquestes tasques, segons l’ordre definit al seu DAG.

Per a la meva aplicació, faré servir el mètode "quanReady", que garanteix que la nostra tasca s'anomenarà un cop hagi poblat el DAG i Gradle estigui preparat per començar a executar les seves tasques.

Afegiu el següent al fitxer build.gradle a nivell de mòdul:

// Executeu aquesta tasca // gradle.taskGraph.whenReady {addDateAndTime}

Posem la nostra tasca personalitzada i el nostre codi de variant de creació a prova, mitjançant la creació d'aquest projecte mitjançant una ordre Gradle.

Crea el teu projecte amb l’embolcall Gradle

Heu publicat ordres de Gradle mitjançant l'embolcall de Gradle ("gradlew"). Aquest script és la forma preferida per iniciar una creació de Gradle, ja que fa que l'execució de la creació sigui independent de la vostra versió de Gradle. Aquesta separació pot ser útil si col·laboreu amb altres que potser no necessàriament tenen instal·lada la mateixa versió de Gradle.

Quan publiqueu les ordres d'embolcall de Gradle, fareu servir "gradlew" per a sistemes operatius com Unix, inclosos macOS i "gradlew.bat" per a Windows. Tinc un Mac, així que faré servir ordres “gradlew”.

Podeu publicar ordres de Gradle des de Android Studio:

A la barra d'eines d'Android Studio, seleccioneu "Veure> Eines Windows> Terminal". S'obre un plafó Terminal a la part inferior de la finestra IDE.
Introduïu la següent comanda al Terminal:

./gradlew build

Android Studio hauria de semblar una cosa així:

Premeu la tecla "Enter" del teclat. Gradle ara crearà el vostre projecte.

Gradle emmagatzema tots els APK generats al directori d'aplicacions / construccions / sortides / apk del vostre projecte, així que aneu a aquest directori. La carpeta "APK" ha de contenir diverses carpetes i subcarpetes; assegureu-vos que Gradle ha generat un APK per a cadascuna de les vostres variants de creació i que a cada fitxer s'ha afegit la informació de data i hora correcta.

Quines altres tasques de Gradle hi ha disponibles?

A més de totes les tasques personalitzades que pugueu crear, Gradle admet una llista de tasques predefinides fora de la caixa. Si teniu curiositat per veure exactament quines tasques estan disponibles, aleshores:

Obriu la finestra Terminal d'Android Studio, si encara no està oberta (si seleccioneu "Veure> Eines Windows> Terminal" a la barra d'eines d'Android Studio).
Escriviu el següent al terminal:

tasques ./gradlew -q

Premeu la tecla "Enter" del teclat.

Aquesta tasca de “tasques” s’executa ara i, al cap d’uns moments, el Terminal mostrarà una llista de totes les tasques disponibles per a aquest projecte, completades amb una breu descripció de cada tasca.

Treure més profit de Gradle: Afegir complements

Gradle s’envia amb diversos connectors preinstal·lats, però podeu ampliar Gradle afegint nous plugins. Aquests complements posen a la vostra disposició les tasques noves als vostres projectes Android, per exemple, el complement Java inclou tasques que us permeten compilar codi font Java, executar proves d'unitats i crear un fitxer JAR, com "compileJava", "compileText", "jar", "Javadoc" i "net".

Per aplicar un complement, afegiu la declaració "aplicar plugin" al fitxer build.gradle a nivell de mòdul, seguit del nom del connector. Per exemple, aquí apliquem el complement Java:

aplicar plugin: java

Si teniu curiositat per veure quins complements hi ha disponibles, feu una ullada a la cerca de complements de Gradle, que proporciona un registre complet de connectors Gradle.

El DSL Gradle Kotlin

De manera predeterminada, escriureu els vostres scripts de creació de Gradle mitjançant el Groovy DSL, però si sou un dels molts desenvolupadors que han adoptat Kotlin per al desenvolupament d'Android, potser preferiu escriure els vostres scripts de creació a Kotlin.

A diferència de Groovy, Kotlin és un llenguatge de programació mecanografiada, de manera que si feu el canvi, els fitxers de creació seran compatibles amb les funcions d’automplenament automàtic i codi de navegació del codi font d’Android Studio. A més, passar de Groovy a Kotlin significa que fareu servir el mateix llenguatge de programació al vostre projecte, cosa que pot fer que el desenvolupament sigui més senzill, sobretot si no coneixeu massa Groovy!

Si voleu començar a escriure la vostra lògica de creació a Kotlin, haureu de configurar el DSL de Gradle Kotlin i seguiu les instruccions de la guia de migració.

Embalatge

En aquest article explorem l'eina de gestió de dependències i automatització per a Android Studio. Hem examinat com Gradle automatitza el procés de creació fora de caixa, i com podeu modificar el procés de creació mitjançant l’edició dels fitxers de creació Gradle del vostre projecte, inclosa la creació de tasques de Gradle personalitzades i la generació de diverses variants de creació d’un sol projecte.

Heu estès Gradle per automatitzar altres parts del procés de creació d'Android? Feu-nos-ho saber als comentaris a continuació!