Deklaratywne, gotowe do obsługi agentów kompilacje Androida z Lightbuild

Cześć!

Nazywam się Juan Sebastian Oviedo.

Jestem menedżerem produktu w zespole ds. doświadczeń deweloperów aplikacji na Androida.

Jestem tu ze Scottem i chętnie przedstawimy Wam Lightbuild, nowe eksperymentalne środowisko kompilacji aplikacji na Androida.

Omówię kontekst tego projektu, jego filozofię i powody, dla których uważamy, że nadszedł właściwy moment, aby przemyśleć sposób konfigurowania projektów aplikacji na Androida.

Omówię też, jak to nowe podejście przygotowuje nas na przyszłość tworzenia aplikacji na Androida.

Zacznijmy od kontekstu, czyli od tego, jak to działa obecnie.

Gradle i imperatywne skrypty kompilacji dają deweloperom możliwość programowego definiowania niemal wszystkich aspektów kompilacji.

Możesz na przykład użyć logiki, która dynamicznie oblicza kody wersji na podstawie historii Git, lub zdefiniować niestandardowe zadanie, które przekształca zasoby.

// build.gradle.kts
android {

  compileSdk = 37

  buildTypes {

    debug {

      // Custom logic in build script
      val commit = providers.exec {
        commandLine("git", "rev-parse",
                    "--short", "HEAD")
      }.standardOutput.asText.get()
       .trim()

      versionNameSuffix = "-$commit"

    }

  }

}

Oprócz Gradle istnieje AGP, czyli wtyczka Androida do obsługi Gradle, która wykorzystuje silnik do zwykłych obciążeń Gradle i dostosowuje go do łańcucha narzędzi Androida.

Gradle i AGP tworzą dynamiczny system, który umożliwia konfigurowanie kompilacji milionów aplikacji produkcyjnych.

Ze względu na tę elastyczność nasze narzędzia dla programistów działają w ramach określonego cyklu życia architektury.

Gdy otwierasz projekt, przełączasz gałęzie lub edytujesz plik kompilacji, IDE musi mieć przejrzystą mapę i dobrze rozumieć konfigurację projektu, aby móc obsługiwać funkcje takie jak uzupełnianie kodu i nawigacja po kodzie.

Pliki kompilacji są zapisywane w imperatywnym języku Turinga, więc jedynym ogólnym sposobem, aby środowisko IDE poznało konfigurację, jest uruchomienie skryptów kompilacji.

Podczas synchronizacji IDE system kompilacji przechodzi przez fazę konfiguracji.

Ocenia skrypty kompilacji, wykonuje logikę wtyczki i tworzy model projektu.

Dzięki temu widok projektu w Android Studio będzie zgodny z jego rzeczywistą konfiguracją.

Dla deweloperów najważniejsze jest tworzenie świetnych aplikacji na Androida i udostępnianie ich użytkownikom.

Zarządzanie skryptami kompilacji, aktualizowanie AGP i synchronizowanie projektu ze środowiskiem IDE wymaga jednak czasu i wysiłku.

W Google i w całym ekosystemie realizujemy kilka inicjatyw, które mają na celu ułatwienie deweloperom pracy w tym obszarze.

Inicjatywy takie jak Declarative Gradle i łańcuch narzędzi Kotlin mają na celu zastąpienie wykonywalnych skryptów kompilacji deklaratywną konfiguracją kompilacji.

W Android Studio dostępny jest asystent uaktualniania wtyczki Androida do obsługi Gradle, który przeprowadzi Cię przez zmiany wymagane do przejścia z jednej wersji wtyczki na inną.

Udostępniamy też umiejętność uaktualniania, którą agenci mogą zainstalować i postępować zgodnie z nią, aby uaktualnić AGP.

Inwestujemy też w takie obszary jak synchronizacja etapowa i odporna, aby deweloperzy mogli wygodniej synchronizować i importować swoje projekty.

Każde z tych działań dotyczy innego elementu układanki, dzięki czemu deweloperzy mogą poświęcać więcej czasu na tworzenie aplikacji, a mniej na budowanie projektów, zarządzanie plikami kompilacji i synchronizowanie projektów.

Oprócz tego zadaliśmy sobie szersze pytanie.

A gdybyśmy zmienili sposób konfigurowania projektów od podstaw?

Gdy przyjrzymy się architekturze nowoczesnych aplikacji na Androida, zauważymy wyraźną zmianę w kierunku silnej modularyzacji.

Duże bazy kodu często zawierają dziesiątki, a nawet setki modułów: moduły interfejsu, moduły funkcji, moduły domeny i moduły danych.

Chociaż aplikacja główna może czasami wymagać niestandardowego pakowania, zdecydowana większość tych modułów biblioteki jest zgodna ze standardowym, powtarzalnym wzorcem.

Nie muszą mieć w plikach kompilacji dowolnego kodu wykonywalnego.

Wystarczy, że jasno określisz ich strukturę i zależności.

Ta obserwacja doprowadziła nas do stworzenia Lightbuild.

Lightbuild opiera się na 2 filarach.

Po pierwsze, używa deklaratywnej składni konfiguracji, co zapewnia wyraźne oddzielenie konfiguracji kompilacji od logiki.

Po drugie, zapewnia szybką synchronizację IDE dzięki wcześniejszemu rozwiązywaniu zależności.

Omówię szczegółowo każdy z tych filarów, aby pokazać, jak wpływają one na Twoją codzienną pracę.

Zacznijmy od podstaw deklaratywnej konfiguracji kompilacji.

Spójrz na plik po lewej stronie ekranu.

Reprezentuje konfigurację modułu w danym dniu.

// build.gradle.kts

plugins {
   alias(libs.plugins.android.library)
   alias(libs.plugins.kotlin.compose)
}

val gitCommit = providers.exec {
   commandLine("git", "rev-parse", "--short", "HEAD")
}.standardOutput.asText.get().trim()

android {
   namespace = "com.example.app"
   compileSdk = 37

   defaultConfig {
       minSdk = 24
       buildConfigField("String", "GIT_COMMIT",
                        "\"$gitCommit\"")
   }
   buildFeatures {
        compose = true
        buildConfig = true
   }
}

dependencies {
  implementation(platform(libs.androidx.compose.bom))
  implementation(libs.androidx.compose.ui)
  implementation(libs.androidx.compose.ui.graphics)
  ...

Ten plik zawiera kod wykonywalny, więc może zawierać definicje zmiennych lokalnych, wywołania niestandardowych funkcji pomocniczych lub wtyczek konwencji, instrukcje warunkowe i definicje zadań w wierszu.

Aby środowisko IDE wiedziało, co ta konfiguracja rozwiązuje, musi uruchomić skrypt.

Teraz spójrz na plik po prawej stronie ekranu.

To jest konfiguracja Lightbuild dla podobnego modułu.

# lightbuild.yaml

group: "com.example"
version: "1.0.0"

platform: android
type: library

android:
 namespace: "com.example.app"
 compileSdk:
   version:
     release:
       apiLevel: 37
 minSdk:
   version:
     release:
       apiLevel: 24
 dependencies:
   maven:
     - androidx.core:core-ktx:1.10.1
     - androidx.lifecycle:lifecycle-runtime-ktx:2.6.1
     - androidx.activity:activity-compose:1.8.0

Ten plik zawiera wyłącznie dane deklaratywne.

Nie ma definicji zmiennych lokalnych, wywołań niestandardowych funkcji pomocniczych ani instrukcji warunkowych czy definicji zadań wbudowanych.

Wyraźnie określa typ modułu, jego cele SDK i zależności.

Jeśli do Twojego zespołu dołączy nowy inżynier i otworzy ten plik, nie będzie musiał rozszyfrowywać żadnych niestandardowych idiomów kompilacji, a każdy moduł Lightbuild w każdym projekcie Lightbuild będzie używał tego samego, łatwego do odczytania języka.

Rozdzielenie konfiguracji i logiki jest bardzo przydatne dla człowieka, ale jeszcze bardziej rewolucyjne w przypadku przepływów pracy wspomaganych przez Agent Assist.

Gdy deweloperzy wdrażają agentów w ramach przepływu pracy, agenci muszą mieć możliwość odczytywania i modyfikowania konfiguracji kompilacji.

Nie ma jednak możliwości przewidzenia skutków ubocznych zmiany konfiguracji bez faktycznego skompilowania projektu.

Dodanie pojedynczego wiersza do pliku konfiguracji może spowodować konflikt ze zmienną obliczaną dynamicznie w innym miejscu projektu lub z wtyczką konwencji.

W Lightbuild konfiguracja projektu jest deterministycznym, statycznym wykresem danych.

Oznacza to, że agenty mogą sprawdzać ten wykres, analizować topologię modułu i modyfikować ją za pomocą znanego schematu.

Agent może wyświetlić listę modułów, listę zależności i ich wersji, zaktualizować zależności, a nawet dodać zupełnie nowy moduł funkcji, po prostu odczytując i zapisując uporządkowane dane.

Dzięki temu konfiguracja projektu staje się kluczowym elementem przepływów pracy wspomaganych przez agenta.

Warto też podkreślić, że Lightbuild nie jest wtyczką do systemu kompilacji, ale interfejsem do silnika kompilacji.

Wersja testowa Lightbuild, którą dziś udostępniamy, używa Gradle jako silnika wykonawczego.

Jednak podejście architektoniczne, które zastosowaliśmy w przypadku Lightbuild, sprawia, że Android Studio, czyli IDE, widzi i traktuje projekt jako projekt Lightbuild.

Przejdźmy teraz do drugiego filaru, który dotyczy produktywności i płynności pracy programistów: szybkiej synchronizacji IDE.

Nawet jeśli deweloperzy używają agentów w ramach przepływu pracy, Android Studio pozostaje niezbędnym narzędziem do zadań interaktywnych, takich jak sprawdzanie podglądów interfejsu Compose, przechodzenie przez kod w debugerze w ramach analizowania problemu czy analizowanie wydajności za pomocą profilera.

Konfiguracja projektu jest deterministycznym, statycznym wykresem danych, więc IDE nie musi przechodzić przez fazę oceny skryptu ani wykonywać kodu wtyczki, aby zrozumieć projekt.

Niezależnie od tego, czy otwierasz projekt, edytujesz plik kompilacji czy przełączasz gałęzie, IDE może szybko przetworzyć te informacje i udostępnić Ci narzędzia.

Jednym z powodów, dla których ta szybkość i niezawodność są możliwe, jest sposób, w jaki Lightbuild obsługuje zależności.

Zwykle, gdy deklarujesz zależność, system kompilacji musi przejść przez drzewo zależności przechodnich, aby zebrać informacje o wersji i rozwiązać konflikty.

W Lightbuild, gdy zmieniają się zależności, narzędzie automatycznie oblicza informacje o zależnościach przechodnich i zapisuje je w pliku resolved.deps w każdym katalogu modułu.

Dzięki temu, gdy projekt zostanie ponownie otwarty w przyszłości lub przebudowany, ani IDE, ani narzędzie do kompilacji nie będą musiały ponownie obliczać informacji o zależnościach przechodnich.

Zalecamy sprawdzenie tych plików w systemie kontroli źródła, aby po wysłaniu zmian do sprawdzenia przez członków zespołu mogli oni zobaczyć, czy nastąpiły jakieś zmiany w informacjach o zależnościach przechodnich, a ich komputery nie musiały ponownie obliczać tych informacji.

Dodatkowo, sprawdzając te informacje w systemie kontroli źródła, sprawiasz, że Ty, Twoi współpracownicy i potoki CI/CD możecie za każdym razem tworzyć kompilacje z tymi samymi wersjami zależności.

Z przyjemnością informujemy, że Lightbuild jest dostępny we wczesnej wersji przedpremierowej w Android Studio Canary, a także w ramach samodzielnych narzędzi interfejsu wiersza poleceń.

Pamiętaj, że ta wersja Lightbuild jest eksperymentalna, więc nie ma wszystkich funkcji potrzebnych do tworzenia i utrzymywania aplikacji produkcyjnej.

W aplikacjach produkcyjnych nadal używaj AGP i Gradle, a Lightbuild wypróbuj w projektach demonstracyjnych i eksperymentalnych.

Możesz zacząć korzystać z tego rozwiązania już dziś, odwiedzając stronę goo.gle/lightbuild. Czekamy na Twoje opinie, które pomogą nam ulepszać ten produkt.

Teraz przekażę głos Scottowi, który pokaże Lightbuild w akcji.

Dziękuję, Juan.

Nazywam się Scott Myers.

Jestem inżynierem ds. relacji z programistami aplikacji na Androida. Od jakiegoś czasu pracujemy nad Lightbuild i chętnie pokażemy, jak można już dziś zacząć korzystać z tego narzędzia.

Najpierw wejdź na stronę, o której wspomniał Juan, czyli goo.gle/lightbuild, lub po prostu wyszukaj Lightbuild.

Powinna otworzyć się strona dokumentacji, na której znajdziesz wszystkie kroki, które musisz wykonać, aby zacząć, w tym instalację wersji Canary Android Studio. Pamiętaj, że jest to nadal wersja testowa, a nie stabilna wersja Android Studio.

Dostępny jest też interfejs wiersza poleceń Lightbuild, który możesz zainstalować, aby w pełni korzystać z możliwości agentowych Lightbuild.

Gdy już to skonfigurujesz, tak jak ja na moim komputerze, będziesz mieć najnowszą wersję Android Studio Canary.

Teraz pokażę, jak utworzyć przykładowy projekt Lightbuild. Możesz to zrobić nawet dzisiaj.

Najpierw otworzę kreator nowego projektu.

Wybiorę Empty Activity (Pusta aktywność) i kliknę Next (Dalej).

Teraz zobaczysz normalny ekran szczegółów projektu, ale na dole jest nowa opcja.

W sekcji języka konfiguracji kompilacji możesz wybrać Lightbuild.

Zanim klikniesz Zakończ, przypomni Ci, że jest to funkcja eksperymentalna.

Jak widać, nasz projekt jest zsynchronizowany ze środowiskiem IDE i gotowy do pracy.

Przyjrzyjmy się teraz strukturze typowego projektu Lightbuild.

To jest domyślny szablon Androida, który otrzymujesz podczas tworzenia nowej aplikacji.

Wyświetla tylko „Hello, world!”.

To prosty sposób na rozpoczęcie.

Na poziomie głównym naszego projektu znajduje się plik o nazwie project.lightbuild.yaml.

To daje nam globalne ustawienia dla całego projektu.

Możesz więc nadać projektowi nazwę, wyświetlić listę wszystkich modułów w projekcie, określić, z których repozytoriów zewnętrznych pobierasz zależności, a następnie wskazać wersje, które są stosowane globalnie do różnych części projektu.

Widzimy, że mamy tu 2 moduły: app i app-core.

Dzieje się tak, ponieważ wszystkie projekty Lightbuild mają co najmniej 2 moduły.

Dzieje się tak, ponieważ wymagany jest co najmniej 1 moduł aplikacji i co najmniej 1 moduł biblioteki.

Za chwilę wyjaśnię dlaczego.

Najpierw przyjrzyjmy się temu modułowi aplikacji.

Jeśli rozwinę ten moduł, zobaczysz, że na poziomie głównym znajduje się plik lightbuild.yaml, który ma każdy moduł.

Znajdziesz tu kilka podstawowych informacji.

Pracujemy oczywiście nad platformą Androida.

Ten moduł jest typu aplikacji.

Możesz wyświetlić listę docelowych wersji pakietu SDK, identyfikator aplikacji itd., a następnie listę wszystkich modułów, od których zależy ten moduł aplikacji.

W tym module aplikacji, który różni się nieco od standardowego szablonu Androida, interesujące jest to, że w folderze źródłowym nic nie ma.

Dlatego w Lightbuild moduły aplikacji nie zawierają żadnego kodu źródłowego.

Dzieje się tak, ponieważ ten moduł aplikacji nie będzie się często zmieniać, ale jego utworzenie zajmuje trochę czasu.

Jeśli więc cały kod aplikacji przechowujesz w modułach biblioteki, każda kompilacja będzie przebiegać szybciej, ponieważ nie będzie trzeba ponownie obliczać i przepakowywać wszystkiego w module aplikacji.

Przyjrzyjmy się teraz modułowi app-core, czyli modułowi biblioteki, od którego zależy ten moduł aplikacji.

Jak widać, ten moduł zawiera kod źródłowy.

Zawiera on naszą główną logikę.

Wyświetla tylko „Hello, world!”.

Jeśli spojrzę na plik lightbuild.yaml w tym module, zobaczę, że jest to typ biblioteki.

Tutaj też ustawia numery wersji pakietu SDK, ale zawiera listę wszystkich zależności zewnętrznych, które mamy w tym module.

Deklaruje też nasze testy jednostkowe i testy z instrumentacją.

Przyjrzyjmy się teraz innemu plikowi, który możesz tu zauważyć. Juan już trochę o nim mówił. W każdym module znajduje się plik resolved.deps.

Ten plik jest generowany automatycznie przez Lightbuild.

Oznacza to, że nie należy go edytować ręcznie, ale będzie on zawierał listę wszystkich rozwiązanych zależności w tym module.

Wszystkie zależności i zależności przechodnie są już tutaj.

Oznacza to, że gdy aplikacja zostanie otwarta w IDE lub gdy chcesz utworzyć kompilację, nie musisz się nad tym zastanawiać, ponieważ zostało to już wcześniej ustalone i sprawdzone w projekcie.

Teraz przyjrzyjmy się przykładowi, jak Lightbuild ułatwia deweloperom synchronizację projektów.

Wróciłem do ustawień globalnych na poziomie głównym project.lightbuild.yaml, gdzie znajduje się lista wszystkich modułów w mojej aplikacji.

Zwykle podczas edytowania plików konfiguracji lub konfiguracji kompilacji pojawia się przycisk synchronizacji, który wymaga trochę czasu na przetworzenie wszystkich tych elementów ze względu na procesy, które opisał Juan, gdzie musi wykonać częściową kompilację, uruchamiając wszystkie skrypty kompilacji, a następnie zsynchronizować ten model z IDE.

Wprowadźmy więc dość dużą zmianę w tym małym projekcie.

Usuniemy jeden z modułów.

Zanim kliknę przycisk zapisu, moduł jest rozpoznawany przez IDE, ponieważ jest pogrubiony.

Rozpoznał katalog źródłowy i katalogi testowe.

Gdy tylko kliknę „Zapisz” po wprowadzeniu tej zmiany, zobaczysz, że ten moduł natychmiast zniknie z projektu.

Jeśli cofnę tę zmianę i kliknę Zapisz, wszystko wróci do poprzedniego stanu.

To przykład szybkiej synchronizacji IDE, którą Lightbuild wprowadza do projektów.

Możesz też używać wszystkich standardowych poleceń, które znasz z Android Studio.

Możesz kliknąć przycisk uruchamiania.

Skompiluje aplikację i uruchomi ją tutaj.

Ta aplikacja demonstracyjna nie jest zbyt duża, ale powiększę ją, aby pokazać, że wyświetla „Hello Android”.

Możesz przeprowadzać testy tak jak zwykle, przechodząc do pliku testowego i uruchamiając go z poziomu rynny, tak jak tutaj.

W tle wywołuje Lightbuild, aby przeprowadzić te testy.

Wszystko działa zgodnie z oczekiwaniami.

Teraz chcę pokazać, jak używać Lightbuild poza Android Studio, w innym przepływie agentowym.

Do tego służy wiersz poleceń.

W interfejsie wiersza poleceń Lightbuild uruchomię podstawowe polecenie pomocy.

I tak, wszystkie literówki, które widzicie dzisiaj w tym projekcie, są moje.

Lightbuild będzie mieć kilka różnych wbudowanych poleceń, takich jak… O, przepraszam, uruchamiam to poza projektem.

Ciągle mi to powtarza.

Tak, prezentacja na żywo.

Zanim uruchomię jakiekolwiek polecenia Lightbuild, utworzę projekt Lightbuild.

W tym celu użyję android create, czyli naszego standardowego narzędzia wiersza poleceń do tworzenia nowych szablonów projektów.

Użyję szablonu empty-activity-lightbuild, nazwę aplikację Lightbuild Demo i umieszczę ją w katalogu wyjściowym demo.

Jeśli teraz wejdę do tego katalogu i wpiszę lightbuild -h, zobaczę wszystkie polecenia dostępne w Lightbuild.

Mamy więc wiele rzeczy, których można się spodziewać: kompilowanie, czyszczenie, testowanie.

ale jest też kilka nowych.

Polecenie resolve analizuje zależności projektu i generuje pliki resolved.deps, które pokazałem wcześniej.

Jest też polecenie zapytania, które pozwala Tobie i Twoim agentom lepiej zrozumieć strukturę projektu.

Najpierw pokażę nowe polecenie zapytania.

Jeśli więc spojrzę na strukturę tego projektu za pomocą wiersza poleceń, jest ona taka sama jak w wersji demonstracyjnej Android Studio.

ale nie mówi mi to zbyt wiele o tym, jak jest ułożony mój projekt.

Jeśli więc wykonam zapytanie Lightbuild i sprawdzę na przykład ten moduł aplikacji, użyję tej specjalnej składni, aby powiedzieć: „Pokaż mi wszystko, co znajduje się w tym module aplikacji”.

Otrzymuję tę tabelę z różnymi celami, które mogę utworzyć w module aplikacji.

Zawiera więc pliki APK i pakiety aplikacji na Androida zarówno dla plików binarnych debugowania, jak i plików binarnych wersji.

Jeśli uruchomię tylko cel aplikacji, zostanie skompilowane wszystko.

Można też określić dane wyjściowe jako JSON.

Dzięki temu… Przepraszam.

Wszystkie moje literówki są dziś prawdziwe.

Skorzystam z interaktywnej pomocy Lightbuild, aby upewnić się, że robię to prawidłowo.

Hmm…

Tak, powinno działać.

OK.

Jeśli ktoś może mi powiedzieć, co robię źle, zapraszam do rozmowy po tej prezentacji.

Zamiast tej tabeli możesz też wyświetlać polecenia Lightbuild w formacie JSON, co jest łatwiejsze dla agentów.

--format json…

O, format.

O, przepraszam.

Dziękujemy.

To jest opinia dewelopera na żywo.

Dziękujemy.

OK, tak. Jest też polecenie wyjściowe, które mogę zademonstrować, być może z Twoją pomocą.

Jeśli więc zamiast elementów docelowych wygeneruję pliki, zobaczę lokalizacje wszystkich plików binarnych w kompilacji.

To po prostu sposób, w jaki Ty i Twoi agenci możecie odkrywać i lepiej rozumieć projekt z poziomu wiersza poleceń za pomocą Lightbuild.

Następnie, oczywiście, jest polecenie lightbuild resolve, o którym wspomniałem wcześniej, które wygeneruje wszystkie pliki resolved.deps.

Ta wersja ma też kilka dodatkowych funkcji.

Na przykład istnieje parametr zablokowanych zależności, dzięki któremu zamiast generować te pliki, po prostu porównuje zawartość plików z zależnościami zadeklarowanymi w konfiguracji kompilacji.

Jeśli wystąpią jakieś różnice, powiadomi Cię o tym i nie uda się utworzyć kompilacji.

W ten sposób pliki rozwiązanych zależności mogą działać jako pliki blokady. Jeśli na przykład tworzysz aplikację w systemie CI/CD do produkcji, chcesz wiedzieć, czy podczas tej kompilacji zmieniają się jakieś zależności.

Lightbuild ma też wbudowaną funkcję testowania. Możesz też uruchomić wszystkie testy w tym module biblioteki, na przykład bezpośrednio z wiersza poleceń.

Chcę pokazać jeszcze jedną rzecz.

Just that it also has the help available that will give you a very complete list of all the building of all the parameters and sub commands that you can use.

Jest on dostępny dla Twojego agenta, więc jest to wynik dla agenta.

OK.

Skoro widzieliśmy już kilka prostych projektów z Lightbuild, chcę pokazać, jak wygląda nieco bardziej ambitny projekt.

Zespół Androida udostępnia przykładową aplikację Now in Android, która zawiera niektóre z najnowszych funkcji Androida, pokazuje, jak ich używać, i przedstawia sprawdzone metody.

Jest to aplikacja o wysokim stopniu modułowości.

Jest podzielony na około 32 moduły.

Tak to wygląda w GitHubie.

Wracam do Android Studio, gdzie wcześniej użyłem już agenta.

Używałem Gemini Argon do przekonwertowania projektu aplikacji na Androida Now in Android na Lightbuild.

Nie opublikowaliśmy tego, zrobiłem to sam.

Jak widać, mimo że ten projekt w project.lightbuild.yaml zawiera wszystkie te różne moduły, został otwarty i zsynchronizowany z tym IDE bardzo szybko.

Kolejną rzeczą, na którą warto zwrócić uwagę w tym projekcie, jest to, że użyto w nim pewnych wersji kompilacji lub specjalnych konfiguracji kompilacji, aby uzyskać zarówno kompilację demonstracyjną, jak i produkcyjną, z których każda miała nieco inny sposób prezentowania aplikacji.

Wersja demonstracyjna korzysta z wbudowanych źródeł danych, a wersja produkcyjna pobiera dane z sieci.

Aby to zrobić za pomocą Lightbuild, który obsługuje różne konfiguracje kompilacji lub warianty usługi, przejdź do modułu aplikacji i określ, że jest to na przykład aplikacja demonstracyjna.

Będzie więc korzystać ze wszystkich podstawowych komponentów, ale też pobierać specjalne ustawienia tylko dla wersji demonstracyjnej aplikacji.

W ten sposób możesz mieć wiele modułów aplikacji.

Każda z nich może reprezentować na przykład płatną lub bezpłatną wersję aplikacji.

Nadal korzystasz z zalet modułu aplikacji, który jest pustą powłoką bez kodu, dzięki czemu kompiluje się znacznie szybciej. Gdy zmieniają się biblioteki, tylko one muszą zostać ponownie skompilowane, aby można było ponownie skompilować aplikację.

Sprawdźmy, czy aplikacja na Androida Now in Android ze wszystkimi 32 modułami jest prawidłowo kompilowana za pomocą Lightbuild.

Tak, jest.

Chcę też podkreślić, że z eksperymentów takich jak ten dowiedzieliśmy się, że Lightbuild nie zawsze obsługuje wszystkie funkcje kompilacji, których możesz potrzebować.

Na przykład aplikacja Now in Android korzysta z wtyczki Hilt, aby używać Hilt, a Lightbuild nie obsługuje jeszcze tego typu rozwiązań.

Agentowi udało się znaleźć obejście i dodać obsługę Hilt bez wprowadzania większych zmian w kodzie projektu.

Cały kod we wszystkich tych modułach jest taki sam jak w oryginalnym repozytorium.

But that's something to de-- definitely keep in mind for when you're experimenting and demoing Lightbuild yourself, is that not everything in your current project is going to be supported in terms of build configuration.

Dlatego Lightbuild jest nadal w wersji testowej i jest dostępny tylko w Android Studio Canary.

Teraz chciałbym wrócić do slajdów.

Podsumowując, Lightbuild to nowa platforma do kompilacji na Androida, która jest obecnie w fazie eksperymentalnej.

Ma deklaratywną konfigurację kompilacji, więc nie uruchamiasz żadnego kodu wykonywalnego w konfiguracjach kompilacji, co odblokowuje wiele świetnych funkcji, takich jak szybka synchronizacja IDE i wydajniejsze kompilacje.

Zapewnia najwyższej klasy obsługę agentów AI, w wierszu poleceń, i ma wszystkie te funkcje, które pomogłeś mi dzisiaj zademonstrować.

Zachęcamy do wypróbowania tej funkcji i używania jej w projektach demonstracyjnych i eksperymentalnych.

Juan i ja oraz niektórzy inżynierowie z zespołu będziemy na stoisku agentowej AI, aby odpowiedzieć na Wasze pytania.

Dziękuję bardzo.