Panoramica della creazione di Gradle

Le app per Android in genere vengono create utilizzando la build di Gradle di un sistema operativo completo. Prima di addentrarci nei dettagli di come configurare la build, esplora i concetti alla base della build in modo da poter vedere il sistema nel suo complesso.

Che cos'è una build?

Un sistema di compilazione trasforma il codice sorgente in un'applicazione eseguibile. Spesso le build prevedono più strumenti per analizzare, compilare, collegare e pacchettizzare un'applicazione o una libreria. Gradle utilizza un approccio basato sulle attività per organizzare ed eseguire questi comandi.

Le attività incapsulano comandi che traducono i loro input in come output. I plug-in definiscono le attività e la relativa configurazione. Applicazione in corso un plug-in per la tua build ne registra le attività e le collega utilizzando i loro input e output... Ad esempio, l'applicazione del plug-in Android Gradle (AGP). al file di build registreranno tutte le attività necessarie per creare un APK oppure Raccolta Android. Il plug-in java-library ti consente di creare un jar dal codice sorgente Java le API nel tuo codice. Esistono plug-in simili per Kotlin e per altre lingue, ma esistono altri plug-in hanno lo scopo di estendere i plug-in. Ad esempio, il plug-in protobuf ha lo scopo di aggiungere il supporto di protobuf a plug-in esistenti come AGP o java-library.

Gradle preferisce la convenzione rispetto alla configurazione, quindi i plug-in avranno una buona predefiniti pronti all'uso, ma puoi configurare ulteriormente la build tramite Domain-Specific Language (DSL) dichiarativa. La DSL è progettata quindi puoi specificare cosa creare, anziché come crearlo. La logica in i plug-in gestiscono l'"how". Questa configurazione viene specificata file di build nel tuo progetto (e progetti secondari).

Gli input delle attività possono essere file e directory, nonché altre informazioni codificate Tipi Java (numero intero, stringhe o classi personalizzate). Gli output possono essere solo directory così come devono essere scritti su disco. Collegare l'output di un'attività a un'altra l'input attività, collega le attività in modo che una debba essere eseguita prima dell'altra.

Sebbene Gradle supporti la scrittura di dichiarazioni di codice e attività arbitrari nella build questo può rendere più difficile per gli strumenti comprendere la build da mantenere. Ad esempio, puoi scrivere test per il codice all'interno dei plug-in ma non nei file di build. Dovresti invece limitare la logica e l'attività di build dichiarazioni ai plug-in (definiti da te o da qualcun altro) e dichiarando vuoi utilizzare quella logica nei tuoi file di build.

Cosa succede quando viene eseguita una build Gradle?

Le build di Gradle vengono eseguite in tre fasi. Ognuna di queste fasi esegue parti diverse di codice che definisci nei tuoi file di build.

• L'inizializzazione determina quali progetti e sottoprogetti vengono inclusi in la build e imposta percorsi di classe contenenti i file di build e o plug-in. Questa fase è incentrata su un file di impostazioni in cui dichiari i progetti build e le posizioni da cui recuperare plug-in e librerie.
• Il campo Configurazione registra le attività per ogni progetto ed esegue la build per applicare la specifica build dell'utente. È importante comprendere che il codice di configurazione non avrà accesso a dati o file generati durante l'esecuzione.
• L'esecuzione esegue l'effettivo "creazione" della tua applicazione. L'output di configurazione è un Directed Acyclic Graph (DAG) di attività, che rappresentano tutti i passaggi di build richiesti richiesti dall'utente (il attività fornite sulla riga di comando o come predefinite nei file di build). Questo rappresenta la relazione tra le attività, esplicita nel dichiarazione o sulla base dei suoi input e output. Se un'attività ha un input che è l'output di un'altra attività, deve essere eseguita dopo l'altra. Questo esegue le attività obsolete nell'ordine definito nel grafico; se un'attività non sono cambiati dall'ultima esecuzione, Gradle la ignorerà.

Per maggiori informazioni, consulta il ciclo di vita della creazione di Gradle.

DSL di configurazione

Gradle utilizza una lingua specifica del dominio (DSL) per configurare le build. Questo approccio dichiarativo si concentra sulla specifica dei dati anziché scrivere istruzioni dettagliate (imperative).

Gli annunci DSL cercano di facilitare per tutti, esperti di dominio e programmatori, contribuire a un progetto, definendo un piccolo linguaggio che rappresenta i dati in un in modo più naturale. I plug-in Gradle possono estendere il DSL per configurare i dati per svolgere le proprie attività.

Ad esempio, la configurazione della parte Android della tua build potrebbe avere il seguente aspetto:

android {
    namespace = "com.example.app"
    compileSdk = 34
    // ...

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 34
        // ...
    }
}

android {
    namespace 'com.example.myapplication'
    compileSdk 34
    // ...

    defaultConfig {
        applicationId "com.example.myapplication"
        minSdk 24
        // ...
    }
}

Dietro le quinte, il codice DSL è simile a questo:

fun Project.android(configure: ApplicationExtension.() -> Unit) {
    ...
}

interface ApplicationExtension {
    var compileSdk: Int
    var namespace: String?

    val defaultConfig: DefaultConfig

    fun defaultConfig(configure: DefaultConfig.() -> Unit) {
        ...
    }
}

Ogni blocco nella DSL è rappresentato da una funzione che prende una funzione lambda configurarla e una proprietà con lo stesso nome per accedervi. Ciò rende nei file di build sono più simili a una specifica dei dati.

Dipendenze esterne

Il sistema di compilazione Maven ha introdotto una specifica di dipendenza, di archiviazione e gestione. Le librerie sono archiviate in repository (server o directory), con metadati che includono la loro versione e le loro dipendenze da altre librerie. Devi specificare quali nei repository per cercare, le versioni delle dipendenze che vuoi utilizzare e e il sistema di compilazione li scarica durante la build.

Gli artefatti Maven sono identificati da nome del gruppo (azienda, sviluppatore e così via), artefatto nome (il nome della libreria) e la versione dell'artefatto. In genere si tratta di una situazione rappresentato come group:artifact:version.

Questo approccio migliora notevolmente la gestione delle build. Spesso sentirai una voce simile chiamato "repository Maven", ma si basa sul modo in cui vengono pacchettizzati e pubblicati. Questi repository e metadati sono stati riutilizzate in diversi sistemi di build, tra cui Gradle (e Gradle può pubblicare in questi repository). I repository pubblici consentono la condivisione per tutti e i repository aziendali mantengono le dipendenze interne.

Puoi anche modularizzare il progetto in progetti (noti anche come "moduli" in Android Studio), che possono essere utilizzati anche come delle dipendenze. Ogni sottoprogetto produce output (come jar) che possono essere consumato dai progetti secondari o dal progetto di primo livello. Questo può migliorare i tempi di compilazione isolando le parti che devono essere ricostruite e creando e le responsabilità nell'applicazione.

Approfondiremo come specificare le dipendenze in Aggiungere build delle dipendenze.

Varianti della build

Quando crei un'applicazione Android, in genere conviene realizzare varianti. Le varianti contengono codice diverso o sono create con e sono composte da tipi di build e versioni di prodotti.

I tipi di build variano in base alle opzioni di build dichiarate. Per impostazione predefinita, AGP configura "release" e "debug" tipi di build, ma puoi regolarli e aggiungerne altri (ad esempio per gestione temporanea o test interni).

Una build di debug non minimizza né offusca l'applicazione, accelerandone per costruire e conservare tutti i simboli così come sono. Inoltre, contrassegna l'applicazione come "debuggable", firmandolo con una chiave di debug generica e abilitando l'accesso al i file di app installati sul dispositivo. Ciò permette di esplorare i dati salvati in file e database durante l'esecuzione dell'applicazione.

Una build di release ottimizza l'applicazione, la firma con la chiave di rilascio e protegge i file delle applicazioni installate.

Utilizzando le versioni di prodotto, puoi modificare l'origine e la dipendenza incluse varianti dell'applicazione. Ad esempio, puoi creare "demo" e "completo" versioni per la tua applicazione, o magari "senza costi" e "a pagamento" sapori. Scrivi l'origine comune in un file "main" set di origine e sostituisci o aggiungi la sorgente in un insieme di origini denominato in base al sapore.

AGP crea varianti per ogni combinazione di tipo di build e versione del prodotto. Se non definisci le versioni, le varianti prendono il nome dai tipi di build. Se definisci entrambi, la variante è denominata <flavor><Buildtype>. Ad esempio, con build tipi release e debug e i gusti demo e full, AGP creerà varianti:

• demoRelease
• demoDebug
• fullRelease
• fullDebug

Passaggi successivi

Ora che conosci i concetti relativi alla build, dai un'occhiata alla Guida di del tuo progetto.