Lightbuild-Projektstruktur

In einem Lightbuild-Projekt wird die App-Assembly vom App-Code getrennt: Ein App-Modul (oder eine „Anwendungsshell“) assembliert Ihre App und Bibliotheksmodule enthalten die Funktionen, die Benutzeroberfläche und die Geschäftslogik Ihrer App. Auf dieser Seite werden das Layout eines neuen Lightbuild-Projekts und die Rolle der einzelnen Module und Build-Dateien beschrieben.

Projektlayout

Die Standard-Lightbuild-Projektvorlage enthält die folgenden Build-Dateien und Module:

MyApp/
├── project.lightbuild.yaml  # Project-wide settings
├── app/                     # App module
│   ├── lightbuild.yaml
│   └── resolved.deps
└── app-core/                # Library module
    ├── lightbuild.yaml
    ├── resolved.deps
    └── src/                 # The app's source code

Das Projekt hat drei Build-Konfigurationsdateien: eine project.lightbuild.yaml-Datei im Stammverzeichnis und eine lightbuild.yaml-Datei in jedem Modul. Jedes Modul enthält auch eine resolved.deps-Datei. Weitere Informationen zu den Einstellungen in den einzelnen Konfigurationsdateien finden Sie in der Referenz zur Lightbuild-Konfiguration.

App-Modul

Lightbuild-Projekte verwenden ein App-Modul als Grundlage für Ihre App. Es wird auch als „Anwendungsshell“ bezeichnet, da es die Projektzusammenstellung übernimmt, ohne Quellcode zu enthalten. Alle Funktionen und die Logik bleiben in separaten Bibliotheksmodulen und die Anwendungsshell konzentriert sich auf die endgültige Konfiguration, z. B. Signierung und Optimierung.

In der Datei lightbuild.yaml des App-Moduls wird die type des Moduls auf application festgelegt und angegeben, wie die endgültige App zusammengestellt wird, einschließlich:

  • Die Identität der App: Anwendungs-ID, Versionscode und Versionsname
  • Die SDK-Anforderungen der App: die Versionen compileSdk, minSdk und targetSdk
  • Die Module, von denen die App abhängt, in diesem Beispiel app-core

Bibliotheksmodule

Bibliotheksmodule enthalten den Code, den das App-Modul zusammenstellt, z. B. die Funktionen, UI-Komponenten und Geschäftslogik Ihrer App. In der neuen Projektvorlage enthält das Bibliotheksmodul app-core die Datei MainActivity.kt mit Beispielcode.

In der Datei lightbuild.yaml eines Bibliotheksmoduls wird der Wert type des Moduls auf library festgelegt. Bibliotheksmodule definieren ihre compileSdk- und minSdk-Versionen, unterstützen aber nicht die Einstellung targetSdk. In der lightbuild.yaml-Datei eines Bibliotheksmoduls werden auch die Abhängigkeiten, KSP-Prozessoren und Tests des Moduls deklariert.

Mehrere App-Module

Ein Projekt kann mehrere App-Module haben. Lightbuild unterstützt keine Produktvarianten und benutzerdefinierten Build-Typen im herkömmlichen Sinne. Stattdessen erstellen Sie für jede Version Ihrer App ein separates App-Modul, z. B. für die Versionen dev und prod oder free und paid.

Jedes App-Modul hängt von den Bibliotheksmodulen ab, die für die jeweilige Version erforderlich sind. App-Module können Bibliotheksmodule gemeinsam nutzen, für versionsspezifischen Code und Einstellungen von verschiedenen Bibliotheksmodulen abhängig sein (z. B. separate Dependency Injection-Module (DI)) und Bibliotheksmodule für Funktionen weglassen, die in einer Version nicht enthalten sind.

Ein Projekt mit kostenlosen und kostenpflichtigen Versionen einer App kann beispielsweise die folgenden Module enthalten:

MyApp/
├── project.lightbuild.yaml
├── app-free/   # App module for the free version
├── app-paid/   # App module for the paid version
├── core/       # Library module that both versions use
├── di-free/    # DI module for the free version
├── di-paid/    # DI module for the paid version
└── premium/    # Library module for paid-only features

Die Datei app-paid/lightbuild.yaml der kostenpflichtigen Version hängt von allen Modulen der kostenpflichtigen Version ab:

android:
  applicationId: com.example.myapp.paid
  dependencies:
    module:
      - //core
      - //di-paid
      - //premium

Die Datei app-free/lightbuild.yaml der kostenlosen Version hängt vom freigegebenen Modul core und dem eigenen DI-Modul ab und lässt das Modul premium aus:

android:
  applicationId: com.example.myapp.free
  dependencies:
    module:
      - //core
      - //di-free

Jedes App-Modul hat eigene Einstellungen, z. B. die Anwendungs-ID und die Release-Signatur. So können Sie jede Version separat erstellen, installieren und veröffentlichen. Wenn Sie eine bestimmte Version erstellen möchten, geben Sie beim Ausführen des Befehls build das entsprechende App-Modul an. Beispiel:

lightbuild build app-free

Aufgelöste Abhängigkeiten

Jedes Modul in einem Lightbuild-Projekt enthält eine resolved.deps-Datei, in der alle aufgelösten Abhängigkeiten des Moduls, einschließlich transitiver Abhängigkeiten, aufgezeichnet werden. Lightbuild generiert diese Datei automatisch, sodass Abhängigkeiten nicht jedes Mal dynamisch aufgelöst werden müssen, wenn Sie Ihr Projekt öffnen oder erstellen. Sie sollten diese Datei nicht manuell bearbeiten.

Checken Sie Ihre resolved.deps-Dateien zusammen mit den lightbuild.yaml-Dateien Ihres Projekts in die Versionsverwaltung ein.

Wenn Sie Ihre Abhängigkeiten sperren möchten, z. B. in einem CI-Build, fügen Sie das Flag --locked-dependencies zu lightbuild resolve oder lightbuild test hinzu. Mit diesem Flag schlägt der Befehl fehl, wenn eine resolved.deps-Datei nicht mit den Abhängigkeiten des Moduls übereinstimmt, anstatt die Datei zu aktualisieren:

lightbuild resolve --locked-dependencies