Il plug-in Android 4.0 per Gradle ha aggiunto il supporto per l'utilizzo di Kotlin nella build Gradle configurazione in sostituzione di Groovy, il linguaggio di programmazione tradizionalmente utilizzate nei file di configurazione Gradle.
Kotlin è preferito rispetto a Groovy per scrivere script Gradle, perché Kotlin è più leggibile e offre un migliore controllo in fase di compilazione e il supporto di IDE.
Sebbene Kotlin al momento offra una migliore integrazione nel codice di Android Studio un editor di testo rispetto a Groovy, le build che usano Kotlin tendono a essere più lente build utilizzando Groovy, quindi valuta le prestazioni delle build quando decidi se eseguire la migrazione.
Questa pagina fornisce informazioni di base sulla conversione del File di build Gradle da Groovy a Kotlin. Per una migrazione più completa consulta la documentazione di Gradle documentazione ufficiale.
Spostamenti
A partire da Android Studio Giraffe, i nuovi progetti utilizzano il modello DSL Kotlin
(build.gradle.kts
) per impostazione predefinita per la configurazione della build. Questo offre una migliore
di modifica rispetto a Groovy DSL (build.gradle
) con sintassi
evidenziazione, completamento del codice
e navigazione verso le dichiarazioni. Per saperne di più,
vedi il
Gradle Kotlin DSL Primer.
Termini comuni
Kotlin DSL: si riferisce principalmente al plug-in Android per Gradle Kotlin DSL. o, occasionalmente, al sottostante Gradle Kotlin DSL.
In questa guida alla migrazione, "Kotlin" e "Kotlin DSL" sono utilizzati in modo intercambiabile. Analogamente, "Groovy" e "Groovy DSL" sono utilizzati in modo intercambiabile.
Denominazione dei file di script
I nomi delle estensioni del file di script si basano sulla lingua in cui è scritto il file di build tra:
- I file di build Gradle scritti in Groovy utilizzano l'estensione del nome file
.gradle
. - I file di build Gradle scritti in Kotlin utilizzano il nome file
.gradle.kts
.
Converti la sintassi
Esistono alcune differenze generali nella sintassi tra Groovy e Kotlin, quindi devi applicare queste modifiche a tutti gli script di build.
Aggiungere parentesi alle chiamate di metodo
Groovy ti consente di omettere le parentesi nelle chiamate di metodo, mentre Kotlin richiede che li rappresentano. Per eseguire la migrazione della configurazione, aggiungi parentesi a questi tipi di . Questo codice mostra come configurare un'impostazione in Groovy:
compileSdkVersion 30
Si tratta dello stesso codice scritto in Kotlin:
compileSdkVersion(30)
Aggiungi =
alle chiamate di assegnazione
Il DSL Groovy ti consente di omettere l'operatore di assegnazione =
quando
mentre Kotlin lo richiede. Questo codice mostra come
Assegna le proprietà in Groovy:
java {
sourceCompatibility JavaVersion.VERSION_17
targetCompatibility JavaVersion.VERSION_17
}
Questo codice mostra come assegnare proprietà in Kotlin:
java {
sourceCompatibility = JavaVersion.VERSION_17
targetCompatibility = JavaVersion.VERSION_17
}
Converti stringhe
Ecco le differenze tra le stringhe tra Groovy e Kotlin:
- Virgolette doppie per le stringhe: Mentre Groovy consente di definire le stringhe usando virgolette singole, Kotlin richiede virgolette doppie.
-
Interpolazione di stringhe su espressioni tratteggiate: in Groovy, puoi utilizzare solo il prefisso
$
per interpolazioni di stringhe sulle espressioni tratteggiate, ma Kotlin richiede di racchiudere le espressioni tratteggiate con parentesi graffe. Ad esempio, in Groovy puoi usare$project.rootDir
come mostrato nel seguente snippet:myRootDirectory = "$project.rootDir/tools/proguard-rules-debug.pro"
In Kotlin, invece, il codice precedente chiama
toString()
suproject
, non suproject.rootDir
. Per ottenere il valore della directory radice, aggrega l'espressione${project.rootDir}
con parentesi graffe:myRootDirectory = "${project.rootDir}/tools/proguard-rules-debug.pro"
Per saperne di più, vedi Modelli di stringa nella documentazione di Kotlin.
Rinominare le estensioni di file
Aggiungi .kts
a ogni file di build man mano che esegui la migrazione dei relativi contenuti. Ad esempio:
seleziona un file di build, ad esempio il file settings.gradle
. Rinomina il file in
settings.gradle.kts
e converti i contenuti del file in Kotlin. Assicurati che
viene comunque compilato dopo la migrazione di ciascun file di build.
Esegui prima la migrazione dei file più piccoli, fai esperienza e poi vai avanti. Puoi un mix di file di build Kotlin e Groovy in un progetto, quindi prenditi il tempo fare la mossa con attenzione.
Sostituisci def
con val
o var
Sostituisci def
con val
o var
, che è
come definisci le variabili in Kotlin.
Questa è una dichiarazione di variabile in Groovy:
def building64Bit = false
Si tratta dello stesso codice scritto in Kotlin:
val building64Bit = false
Aggiungi il prefisso is
alle proprietà booleane
Groovy utilizza la logica di detrazione delle proprietà
in base ai nomi delle proprietà. Per una proprietà booleana foo
, i relativi metodi dedotti
può essere getFoo
, setFoo
o isFoo
. Una volta convertito al Kotlin,
devi cambiare i nomi delle proprietà con i metodi dedotti
non supportati da Kotlin. Ad esempio, per
buildTypes
Elementi booleani DSL, devono essere preceduti dal prefisso is
. Questo codice
mostra come impostare proprietà booleane in Groovy:
android {
buildTypes {
release {
minifyEnabled true
shrinkResources true
...
}
debug {
debuggable true
...
}
...
Il seguente codice è lo stesso di Kotlin. Tieni presente che le proprietà hanno un prefisso
entro il giorno is
.
android {
buildTypes {
getByName("release") {
isMinifyEnabled = true
isShrinkResources = true
...
}
getByName("debug") {
isDebuggable = true
...
}
...
Converti elenchi e mappe
Gli elenchi e le mappe in Groovy e Kotlin vengono definiti con una sintassi diversa. Alla moda
utilizza []
, mentre Kotlin chiama esplicitamente i metodi di creazione delle raccolte utilizzando
listOf
o mapOf
. Assicurati di sostituire []
con listOf
o mapOf
quando
migrazione.
Ecco come definire un elenco in Groovy rispetto a Kotlin:
jvmOptions += ["-Xms4000m", "-Xmx4000m", "-XX:+HeapDumpOnOutOfMemoryError</code>"]
Si tratta dello stesso codice scritto in Kotlin:
jvmOptions += listOf("-Xms4000m", "-Xmx4000m", "-XX:+HeapDumpOnOutOfMemoryError")
Ecco come definire una mappa in Groovy rispetto a Kotlin:
def myMap = [key1: 'value1', key2: 'value2']
Si tratta dello stesso codice scritto in Kotlin:
val myMap = mapOf("key1" to "value1", "key2" to "value2")
Configura i tipi di build
Nella DSL Kotlin sono disponibili solo i tipi di build di debug e release in modo implicito. Tutti gli altri tipi di build personalizzati devono essere creati manualmente.
In Groovy puoi usare il debug, il rilascio e alcuni altri tipi di build senza
per prima cosa. Il seguente snippet di codice mostra una configurazione con
debug
, release
e
Build di benchmark
di testo in Groovy.
buildTypes {
debug {
...
}
release {
...
}
benchmark {
...
}
}
Per creare la configurazione equivalente in Kotlin, devi creare esplicitamente il
Tipo di build benchmark
.
buildTypes {
debug {
...
}
release {
...
}
register("benchmark") {
...
}
}
Migrazione da buildscript al blocco plug-in
Se la build utilizza
buildscript {}
per aggiungere plug-in al progetto, è necessario eseguire il refactoring in modo da utilizzare
plugins {}
bloccare. Il blocco plugins {}
semplifica l'applicazione dei plug-in
funziona bene con
catalogi delle versioni.
Inoltre, quando utilizzi il blocco plugins {}
nei file di build,
Android Studio è consapevole del contesto anche quando la build non va a buon fine. Questo contesto
aiuta ad apportare correzioni ai file DSL Kotlin perché consente all'IDE di Studio di
eseguire il completamento del codice e fornire altri suggerimenti utili.
Individuare gli ID plug-in
Mentre il blocco buildscript {}
aggiunge i plug-in al classpath della build utilizzando
il
Coordinate Maven
del plug-in, ad esempio com.android.tools.build:gradle:7.4.0
,
il blocco plugins {}
utilizza invece gli ID plug-in.
Per la maggior parte dei plug-in, l'ID plug-in è la stringa utilizzata quando vengono applicati
apply plugin
. Ad esempio, i seguenti ID plug-in fanno parte di
Plug-in Android Gradle:
com.android.application
com.android.library
com.android.lint
com.android.test
Puoi trovare l'elenco completo dei plug-in nel Repository Maven di Google.
Più ID plug-in possono fare riferimento ai plug-in Kotlin. Ti consigliamo di utilizzare l'ID plug-in con spazio dei nomi e il refactoring da abbreviazione a ID plug-in con spazio dei nomi tabella seguente:
ID plug-in in forma breve | ID plug-in con pacing dei nomi |
---|---|
kotlin |
org.jetbrains.kotlin.jvm |
kotlin-android |
org.jetbrains.kotlin.android |
kotlin-kapt |
org.jetbrains.kotlin.kapt |
kotlin-parcelize |
org.jetbrains.kotlin.plugin.parcelize |
Puoi anche cercare i plug-in nella Portale dei plug-in Gradle il repository centrale Maven e ai Repository Maven di Google. Letto Sviluppo di plug-in Gradle personalizzati per saperne di più sul funzionamento degli ID plug-in.
Esegui il refactoring
Una volta identificati gli ID dei plug-in utilizzati, procedi nel seguente modo:
Se hai ancora repository per i plug-in dichiarati in
buildscript {}
bloccalo, spostalo insettings.gradle
.Aggiungi i plug-in al blocco
plugins {}
nel livello più altobuild.gradle
file. Devi specificare l'ID e il del plug-in qui. Se il plug-in non richiede da applicare al progetto principale, usaapply false
.Rimuovi le voci
classpath
dal filebuild.gradle.kts
di primo livello.Applica i plug-in aggiungendoli al blocco
plugins {}
nel filebuild.gradle
a livello di modulo. Devi solo specificare il parametro perché la versione viene ereditata dal progetto principale.Rimuovi la chiamata
apply plugin
per il plug-in dal livello di modulobuild.gradle
file.
Ad esempio, questa configurazione utilizza il blocco buildscript {}
:
// Top-level build.gradle file
buildscript {
repositories {
google()
mavenCentral()
gradlePluginPortal()
}
dependencies {
classpath("com.android.tools.build:gradle:7.4.0")
classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.0")
...
}
}
// Module-level build.gradle file
apply(plugin: "com.android.application")
apply(plugin: "kotlin-android")
Questa è una configurazione equivalente che utilizza il blocco plugins {}
:
// Top-level build.gradle file
plugins {
id 'com.android.application' version '7.4.0' apply false
id 'org.jetbrains.kotlin.android' version '1.8.0' apply false
...
}
// Module-level build.gradle file
plugins {
id 'com.android.application'
id 'org.jetbrains.kotlin.android'
...
}
// settings.gradle
pluginManagement {
repositories {
google()
mavenCentral()
gradlePluginPortal()
}
}
Converti il blocco plug-in
L'applicazione dei plug-in dal blocco plugins {}
è simile a Groovy e Kotlin.
Il seguente codice mostra come applicare i plug-in in Groovy quando utilizzi
catalogi delle versioni:
// Top-level build.gradle file
plugins {
alias libs.plugins.android.application apply false
...
}
// Module-level build.gradle file
plugins {
alias libs.plugins.android.application
...
}
Il seguente codice mostra come fare la stessa cosa in Kotlin:
// Top-level build.gradle.kts file
plugins {
alias(libs.plugins.android.application) apply false
...
}
// Module-level build.gradle.kts file
plugins {
alias(libs.plugins.android.application)
...
}
Il seguente codice mostra come applicare i plug-in in Groovy quando non usando i cataloghi delle versioni:
// Top-level build.gradle file
plugins {
id 'com.android.application' version '7.3.0' apply false
...
}
// Module-level build.gradle file
plugins {
id 'com.android.application'
...
}
Il seguente codice mostra come fare la stessa cosa in Kotlin:
// Top-level build.gradle.kts file
plugins {
id("com.android.application") version "7.3.0" apply false
...
}
// Module-level build.gradle.kts file
plugins {
id("com.android.application")
...
}
Per ulteriori dettagli sul blocco plugins {}
, consulta la sezione Applicazione
plug-in
nella documentazione di Gradle.
Vari
Per gli esempi di codice Kotlin per altre funzionalità, vedi quanto segue pagine della documentazione:
- Se disponi di una configurazione ProGuard, consulta Abilitare la riduzione, l'offuscamento e l'ottimizzazione.
- Se hai un blocco
signingConfig {}
, leggi l'articolo Rimuovere le informazioni sulla firma da i tuoi file di build. - Se utilizzi proprietà a livello di progetto, consulta Configurare le proprietà a livello di progetto proprietà.
Problemi noti
Attualmente, un problema noto è che la velocità di compilazione potrebbe essere più lenta con Kotlin che con Groovy.
Come segnalare problemi
Per istruzioni su come fornire le informazioni necessarie per classificare il problema, consulta Dettagli relativi agli strumenti di creazione e ai bug Gradle. Poi, segnala un bug utilizzando l'app Issue Tracker pubblico.
Altre risorse
Per un esempio pratico dei file di build Gradle scritti con Kotlin, consulta la sezione App di esempio Now in Android su GitHub.