Struktura projektu Lightbuild

Projekt Lightbuild oddziela kompilację aplikacji od jej kodu: moduł aplikacji (lub „powłoka aplikacji”) kompiluje aplikację, a moduły biblioteki zawierają funkcje, interfejs i logikę biznesową aplikacji. Na tej stronie opisujemy układ nowego projektu Lightbuild oraz rolę każdego modułu i pliku kompilacji.

Układ projektu

Domyślny szablon projektu Lightbuild zawiera te pliki i moduły kompilacji:

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

Projekt ma 3 pliki konfiguracji kompilacji: plik project.lightbuild.yaml w katalogu głównym i plik lightbuild.yaml w każdym module. Każdy moduł ma też plik resolved.deps. Szczegółowe informacje o ustawieniach w poszczególnych plikach konfiguracji znajdziesz w dokumentacji konfiguracji Lightbuild.

Moduł aplikacji

Projekty Lightbuild używają modułu aplikacji jako podstawy aplikacji. Jest on również nazywany „powłoką aplikacji”, ponieważ obsługuje kompilację projektu bez kodu źródłowego. Wszystkie funkcje i logika pozostają w osobnych modułach biblioteki, a powłoka aplikacji skupia się na ostatecznej konfiguracji, takiej jak podpisywanie i optymalizacja.

Plik lightbuild.yaml modułu aplikacji ustawia type modułu na application i określa, jak ma być złożona ostateczna aplikacja, w tym:

  • tożsamość aplikacji: identyfikator aplikacji, kod wersji i nazwa wersji;
  • Wymagania aplikacji dotyczące pakietu SDK: wersje compileSdk, minSdk i targetSdk
  • moduły, od których zależy aplikacja, w tym przykładzie app-core;

Moduły biblioteki

Moduły biblioteki zawierają kod, który jest składany przez moduł aplikacji, np. funkcje aplikacji, komponenty interfejsu i logikę biznesową. W nowym szablonie projektu moduł biblioteki app-core zawiera plik MainActivity.kt z przykładowym kodem.

Plik lightbuild.yaml modułu biblioteki ustawia wartość type modułu na library. Moduły biblioteki definiują wersje compileSdk i minSdk, ale nie obsługują ustawienia targetSdk. Plik lightbuild.yaml modułu biblioteki deklaruje też zależności modułu, procesory KSP i testy.

Wiele modułów aplikacji

Projekt może zawierać więcej niż 1 moduł aplikacji. Lightbuild nie obsługuje wariantów usługi ani niestandardowych typów kompilacji w tradycyjnym sensie. Zamiast tego tworzysz osobny moduł aplikacji dla każdej wersji aplikacji, np. dev i prod lub free i paid.

Każdy moduł aplikacji zależy od modułów biblioteki, których potrzebuje jego wersja. Moduły aplikacji mogą współdzielić moduły bibliotek, korzystać z różnych modułów bibliotek w przypadku kodu i ustawień zależnych od wersji (np. oddzielnych modułów wstrzykiwania zależności) i pomijać moduły bibliotek w przypadku funkcji, których dana wersja nie zawiera.

Na przykład projekt z bezpłatną i płatną wersją aplikacji może zawierać te moduły:

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

Plik app-paid/lightbuild.yaml wersji płatnej zależy od wszystkich modułów wersji płatnej:

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

Plik app-free/lightbuild.yaml wersji bezpłatnej zależy od udostępnionego modułu core i własnego modułu DI, ale nie zawiera modułu premium:

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

Każdy moduł aplikacji ma własne ustawienia, takie jak identyfikator aplikacji i podpisywanie wersji, dzięki czemu możesz tworzyć, instalować i publikować każdą wersję osobno. Aby utworzyć konkretną wersję, podczas uruchamiania polecenia build określ jej moduł aplikacji. Przykład:

lightbuild build app-free

Rozwiązane zależności

Każdy moduł w projekcie Lightbuild zawiera plik resolved.deps, który rejestruje wszystkie rozwiązane zależności modułu, w tym zależności przechodnie. Lightbuild generuje ten plik automatycznie, dzięki czemu nie musi dynamicznie rozwiązywać zależności za każdym razem, gdy otwierasz lub kompilujesz projekt. Nie należy edytować tego pliku ręcznie.

Prześlij pliki resolved.deps do systemu kontroli wersji razem z plikami lightbuild.yaml projektu.

Aby zablokować zależności, na przykład w kompilacji CI, dodaj flagę --locked-dependencies do lightbuild resolve lub lightbuild test. Jeśli użyjesz tej flagi, polecenie nie powiedzie się, gdy plik resolved.deps nie będzie zgodny z zależnościami modułu, zamiast aktualizować plik:

lightbuild resolve --locked-dependencies