Gradle-Build – Übersicht

Android-Apps werden in der Regel mit dem Build Gradle erstellt. System. Bevor wir uns mit der Konfiguration Ihres Builds befassen, sehen wir uns die Konzepte hinter dem Build erkunden, damit Sie das System als Ganzes betrachten können.

Was ist ein Build?

Ein Build-System wandelt Ihren Quellcode in eine ausführbare Anwendung um. Builds umfassen oft mehrere Tools zum Analysieren, Kompilieren, Verlinken und Verpacken oder Bibliothek verwenden. Gradle nutzt einen aufgabenbasierten Ansatz zum Organisieren und Ausführen diese Befehle ausführen.

Tasks kapseln Befehle, die ihre Eingaben in Ausgaben. Plug-ins definieren Aufgaben und ihre Konfiguration. Wird angewendet... ein Plug-in zu Ihrem Build hinzu, registriert seine Aufgaben und verbindet sie mithilfe der Ein- und Ausgaben... Wenn Sie z. B. das Android-Gradle-Plug-in (AGP) anwenden in Ihre Build-Datei einfügen, werden alle Aufgaben registriert, die zum Erstellen eines APK oder eines Android-Mediathek Mit dem Plug-in java-library können Sie eine JAR-Datei aus der Java-Quelle erstellen Code. Für Kotlin und andere Sprachen gibt es ähnliche Plug-ins, aber andere Plug-ins die Erweiterung von Plug-ins. Das Plug-in protobuf dient z. B. dazu, protobuf-Unterstützung für vorhandene Plug-ins wie AGP oder java-library.

Gradle bevorzugt Konvention gegenüber Konfiguration. Plug-ins bieten daher gute Standardwerte verwenden. Sie können den Build aber auch über eine deklarative domainspezifische Sprache (DSL). DSL ist so konzipiert, Du kannst also angeben, was erstellt werden soll, anstatt wie du es erstellen möchtest. Die Logik in verwaltet das Plug-in das „Wie“. Diese Konfiguration wird über mehrere Build-Dateien in Ihrem Projekt (und den Unterprojekten)

Aufgabeneingaben können Dateien und Verzeichnisse sowie andere Informationen sein, die als Java-Typen (Ganzzahl, Strings oder benutzerdefinierte Klassen). Ausgaben können nur im Verzeichnis erfolgen oder Dateien, da sie auf der Festplatte geschrieben werden müssen. Aufgabenausgabe mit einer anderen verbinden und verknüpft die Aufgaben miteinander, sodass eine vor der anderen ausgeführt werden muss.

Gradle unterstützt das Schreiben von beliebigem Code und Aufgabendeklarationen in Ihrem Build. kann es für Tools schwieriger sein, Ihren Build und die Sie verwalten müssen. Sie können beispielsweise Tests für Code in Plug-ins schreiben. aber nicht in Build-Dateien. Stattdessen sollten Sie die Build-Logik und die zu Plug-ins, die Sie oder eine andere Person definieren, und erklären Sie, und wollen diese Logik in Ihren Build-Dateien verwenden.

Was passiert, wenn ein Gradle-Build ausgeführt wird?

Gradle-Builds werden in drei Phasen ausgeführt. In jeder dieser Phasen werden verschiedene Teile Code, den Sie in Ihren Build-Dateien definieren.

• Mit der Initialisierung wird festgelegt, welche Projekte und Unterprojekte enthalten sind. und richtet Klassenpfade ein, die Ihre Build-Dateien und Plug-ins. Diese Phase konzentriert sich auf eine Einstellungsdatei, in der Sie Projekte für und die Speicherorte, von denen Plug-ins und Bibliotheken abgerufen werden sollen.
• Konfiguration registriert Aufgaben für jedes Projekt und führt den Build aus -Datei, um die Build-Spezifikation des Nutzers anzuwenden. Es ist wichtig zu verstehen, dass Ihr Konfigurationscode keinen Zugriff auf Daten oder Dateien hat, während der Ausführung.
• Bei der Ausführung erfolgt die eigentliche Erstellung der Builds. Ihrer Anwendung. Die Ausgabe ein gerichteter azyklischer Graph (Directed Acyclic Graph, DAG) von Aufgaben, die alle erforderlichen Build-Schritte darstellen, die vom Nutzer angefordert wurden (die Aufgaben, die in der Befehlszeile oder als Standardeinstellungen in den Build-Dateien bereitgestellt werden). Dieses Diagramm stellt die Beziehung zwischen Aufgaben dar, entweder explizit in der Deklaration oder basierend auf den Ein- und Ausgaben. Wenn eine Aufgabe eine Eingabe hat, die Ausgabe einer anderen Aufgabe ist, muss sie nach der anderen Aufgabe ausgeführt werden. Dieses Phase veraltete Aufgaben in der im Diagramm definierten Reihenfolge ausführt; wenn eine Aufgabe Eingaben seit der letzten Ausführung nicht geändert haben, wird sie von Gradle übersprungen.

Weitere Informationen finden Sie im Build-Lebenszyklus von Gradle.

Konfigurations-DSLs

Gradle verwendet eine domainspezifische Sprache (DSL), um die Konfiguration baut. Dieser deklarative Ansatz konzentriert sich auf die Angabe Ihrer Daten, anstatt eine Schritt-für-Schritt-Anleitung zu schreiben.

DSLs versuchen, es für alle, Domainexperten und Programmierer, einfacher zu machen, zu einem Projekt beitragen, indem Sie eine kleine Sprache definieren, die Daten in einem auf natürlichere Weise. Gradle-Plug-ins können DSL erweitern, um die Daten zu konfigurieren, für ihre Aufgaben benötigen.

Die Konfiguration des Android-Teils Ihres Builds könnte beispielsweise so aussehen:

Kotlin

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

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

Cool

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

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

Im Hintergrund sieht der DSL-Code in etwa so aus:

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

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

    val defaultConfig: DefaultConfig

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

Jeder Block in der DSL wird durch eine Funktion dargestellt, die eine Lambda-Funktion konfigurieren können, sowie eine Eigenschaft mit demselben Namen, um darauf zuzugreifen. Dadurch wird der Code in Ihren Build-Dateien sich eher wie eine Datenspezifikation an.

Hinweis :Weitere Informationen dazu, wie Sie diese Funktion in Kotlin nutzen können, finden Sie unter Typsichere Builder. Weitere Informationen zu DSLs im Allgemeinen finden Sie unter das Buch Domain Specific Languages von Martin Fowler und Rebecca Parsons.

Externe Abhängigkeiten

Mit dem Maven-Build-System wurde eine dependency-Spezifikation eingeführt. Speicher- und Verwaltungssystems. Bibliotheken werden gespeichert in Repositories (Server oder Verzeichnisse) mit Metadaten, und Abhängigkeiten von anderen Bibliotheken. Sie legen fest, Repositories für die Suche, Versionen der Abhängigkeiten, die Sie verwenden möchten, und lädt das Build-System sie während des Builds herunter.

Maven-Artefakte werden anhand von Gruppennamen (Unternehmen, Entwickler usw.), Artefakt identifiziert Name (der Name der Bibliothek) und die Version dieses Artefakts. Das ist normalerweise dargestellt als group:artifact:version.

Dieser Ansatz verbessert das Build-Management erheblich. Sie werden oft solche die als Maven-Repositories bezeichnet werden, Artefakte gepackt und veröffentlicht werden. Diese Repositories und Metadaten wurden in verschiedenen Build-Systemen wiederverwendet, darunter Gradle (und Gradle kann diese Repositories). Öffentliche Repositories ermöglichen die Freigabe für alle Nutzer und Unternehmens-Repositories halten interne Abhängigkeiten intern.

Sie können Ihr Projekt auch in Unterprojekte modularisieren. (in Android Studio auch als „Module“ bezeichnet), die auch als Abhängigkeiten. Jedes Unterprojekt liefert Ausgaben (z. B. JAR-Dateien), die von Unterprojekten oder Ihrem übergeordneten Projekt genutzt werden. Dies kann die Build-Dauer verkürzen indem Sie isolierte Teile isolieren, die neu aufgebaut werden müssen. Verantwortlichkeiten in der Anwendung.

Wie Sie Abhängigkeiten angeben, erfahren Sie unter Build hinzufügen Abhängigkeiten.

Varianten erstellen

Wenn Sie eine Android-App erstellen, sollten Sie in der Regel mehrere Varianten enthalten. Varianten enthalten unterschiedlichen Code oder werden mit unterschiedlichen und bestehen aus Build-Typen und Produkt-Geschmacksrichtungen.

Build-Typen variieren die deklarierten Build-Optionen. Standardmäßig richtet AGP die Option „Release“ und „debug“ Sie können diese anpassen und weitere hinzufügen (z. B. für Staging oder interne Tests).

Ein Debug-Build verringert oder verschleiert Ihre Anwendung nicht, wodurch die alle Symbole so zu erstellen, wie sie sind. Außerdem wird die Anwendung als "debuggable" ist, indem es mit einem generischen Schlüssel zur Fehlerbehebung signiert wird und der Zugriff auf den App-Dateien auf dem Gerät installiert. Auf diese Weise können Sie Daten in Dateien und Datenbanken gespeichert haben.

Ein Release-Build optimiert die Anwendung, signiert sie mit Ihrem Releaseschlüssel und die installierten Anwendungsdateien schützt.

Mithilfe von Produktvarianten können Sie die eingeschlossene Quelle und Abhängigkeit ändern. Varianten für die Anwendung. Beispielsweise können Sie „Demo“ erstellen, und „vollständig“ App-Varianten oder vielleicht „kostenlos“ und „bezahlt“ Geschmacksrichtungen. Sie schreiben Ihre gemeinsame Quelle in einem „Haupt“. source set-Verzeichnis und die Quelle in einem nach dem Flavor benannten Quellsatz zu überschreiben oder hinzuzufügen.

AGP erstellt Varianten für jede Kombination aus Build-Typ und Produktgeschmack. Wenn nicht definieren, werden die Varianten nach den Build-Typen benannt. Wenn Sie beide definieren, heißt die Variante <flavor><Buildtype>. Mit der Funktion „Build“ release und debug sowie die Geschmacksrichtungen demo und full, erstellt AGP Varianten:

• demoRelease
• demoDebug
• fullRelease
• fullDebug

Nächste Schritte

Nachdem Sie nun die Build-Konzepte kennengelernt haben, werfen Sie einen Blick in die Android-Build-Anleitung Struktur in Ihrem Projekt.