| Key concepts | Set up your development environment | Build an RE SDK | Consume the RE SDK | Testing, and building for distribution |
Kluczowych pojęć
W tej sekcji opisujemy architekturę środowiska wykonawczego SDK, sposób instalowania pakietów SDK używanych w czasie działania aplikacji, zgodność wsteczną oraz sposób przenoszenia istniejących pakietów SDK do środowiska wykonawczego SDK.
Słowniczek
- Pakiet SDK używany w czasie działania aplikacji: pakiet SDK przeznaczony do działania w środowisku wykonawczym SDK i komunikowania się z aplikacją za pomocą komunikacji międzyprocesowej (IPC).
- Pakiet SDK używany w czasie działania aplikacji (RA SDK): pakiet SDK nieużywany w czasie działania aplikacji, połączony z aplikacją statycznie, który może zawierać dotychczasowy kod pakietu SDK, a także nowy kod do wywoływania pakietu SDK używanego w czasie działania aplikacji.
- Czasami określa się to też jako statyczne połączenie lub statyczny pakiet SDK.
- Shim biblioteka Jetpack, która pomaga w abstrakcyjnej komunikacji między procesami lub komunikacji międzyprocesowej (IPC) oraz utrzymuje ten sam interfejs pakietu SDK aplikacji.
Architektura środowiska wykonawczego SDK
Środowisko wykonawcze SDK korzysta z modelu klient-serwer.
Główna różnica polega na tym, że „klient” (aplikacja) i „serwer” (zestawy SDK z włączonym środowiskiem wykonawczym) działają na tym samym urządzeniu, a komunikacja odbywa się między procesami.
Aby pomóc Ci w rozwiązaniu tych problemów, stworzyliśmy te biblioteki i narzędzia Jetpack, które upraszczają integrację pakietów SDK aplikacji w środowisku wykonawczym pakietu SDK:
- Biblioteka pośrednicząca: biblioteka otoki (lub pośrednik) pomaga w abstrakcyjnej komunikacji między procesami lub komunikacji międzyprocesowej (IPC). Pomaga też zachować ten sam interfejs aplikacji i pakietu SDK.
- Biblioteka zgodności wstecznej: ta biblioteka obsługuje zgodność wsteczną, dzięki czemu pakiet SDK jest zgodny niezależnie od tego, czy środowisko wykonawcze pakietu SDK jest dostępne.
- Biblioteka interfejsu: udostępniamy też biblioteki do obsługi prezentacji zdalnej, np. pobierania interfejsu z pakietu SDK z włączonym środowiskiem wykonawczym lub zmiany rozmiaru i układu widoków.
Zmiany w procesie instalacji
Gdy tworzysz pakiet SDK używany w czasie działania aplikacji w Android Studio lub innych narzędziach, tworzysz pakiet Android SDK (ASB), czyli format publikowania pakietów SDK używanych w czasie działania aplikacji.
bundletool przetwarza pakiet ASB, aby utworzyć plik APK dla pakietu SDK używanego w czasie działania aplikacji. Ten osobny plik APK zawiera kod pakietu SDK, ale nie zawiera kodu aplikacji.
Plik manifestu aplikacji deklaruje zależność od nazwy i wersji pakietu SDK z włączonym środowiskiem wykonawczym, a ta zależność jest rozwiązywana przez aplikację instalującą.
Gdy instalator pobierze plik APK pakietu SDK, rozpocznie się instalacja od instalacji pliku APK pakietu SDK. Po pomyślnym zakończeniu następuje instalacja pliku APK aplikacji.
Proces jest inny, jeśli aplikacja jest zainstalowana na urządzeniach z Androidem 13 lub starszym oraz na urządzeniach, które nie obsługują środowiska wykonawczego SDK. W takim przypadku sklep instaluje pojedynczy plik APK zawierający zarówno pakiet SDK z włączonym środowiskiem wykonawczym, jak i kod aplikacji. Więcej informacji znajdziesz w sekcji dotyczącej dystrybucji.
Gdy aplikacja w wersji produkcyjnej korzysta z tego pakietu SDK, sklep z aplikacjami tworzy z tego pliku ASB odpowiedni plik APK pakietu SDK i go instaluje.
Zgodność wsteczna
Środowisko wykonawcze SDK zostało wprowadzone w Androidzie 14, więc musieliśmy zapewnić obsługę starszych wersji bez obciążania deweloperów pakietów SDK ani aplikacji.
Aby zapewnić zgodność wsteczną na Androidzie 13 i starszych wersjach, wprowadziliśmy bibliotekę Jetpack, która może bezproblemowo uruchamiać pakiet SDK wywoływany w czasie działania aplikacji niezależnie od tego, czy urządzenie obsługuje środowisko wykonawcze SDK.
Postępując zgodnie z tym przewodnikiem, domyślnie zapewnisz zgodność wsteczną pakietu SDK z włączonym środowiskiem wykonawczym. Nie musisz wykonywać żadnych dodatkowych czynności.
Na odpowiednich etapach wyróżniamy działania związane z kompatybilnością wsteczną, ale ogólnie rzecz biorąc, musisz mieć pewność, że zadeklarowano odpowiednie zależności i w stosownych przypadkach używasz klas *Compat.
Migracja istniejących pakietów SDK
Jeśli masz pakiet SDK, który chcesz przenieść do środowiska wykonawczego, nie musisz od razu refaktoryzować całego kodu. Zamiast tego możesz stopniowo przenosić istniejącą logikę pakietu SDK do nowego pakietu SDK z obsługą środowiska wykonawczego.
Aby przeprowadzić migrację istniejącego pakietu SDK do środowiska wykonawczego pakietu SDK, zalecamy wykonanie tych 3 etapów:
- Utworzenie pakietu SDK wywoływanego w czasie działania aplikacji, który będzie obowiązywać w okresie przejściowym, oraz jego odpowiednika, czyli pakietu SDK wywoływanego w czasie działania aplikacji, który będzie obowiązywać po zakończeniu okresu przejściowego. Dzięki temu możesz stopniowo przenosić logikę biznesową z dotychczasowego pakietu SDK i korzystać z platformy testowej do przeprowadzania testów A/B.
- Przeniesienie całej dotychczasowej logiki biznesowej pakietu SDK do stanu stabilnego wraz z odpowiednim uproszczonym pakietem SDK uwzględniającym środowisko wykonawcze, aby ułatwić migrację aplikacji.
- Obsługa zainteresowanych aplikacji poprzez pełną migrację, aby mogły korzystać z Twojego pakietu SDK z włączonym środowiskiem wykonawczym bezpośrednio, bez cienkiego pakietu SDK z włączonym środowiskiem wykonawczym.
Etap 1. Okres przejściowy: pakiet SDK z obsługą środowiska wykonawczego
Możesz zacząć od zachowania części logiki biznesowej w zestawie SDK uwzględniającym środowisko wykonawcze. Nazywamy to pakietem SDK z pełną obsługą środowiska wykonawczego lub otoczką w aplikacji.
Dzięki temu możesz zachować wszystkie lub niektóre funkcje pakietu SDK w statycznej bibliotece aplikacji wraz z nowo utworzonym pakietem SDK z włączonym środowiskiem wykonawczym.
Dzięki temu możesz stopniowo przenosić przypadki użycia do pakietu SDK z włączonym środowiskiem wykonawczym i testować go w porównaniu z dotychczasowym pakietem SDK.
Na tym etapie deweloper aplikacji nie musi niczego zmieniać w sposobie korzystania z Twojego pakietu SDK, ponieważ to Twoja statyczna biblioteka aplikacji (pakiet SDK z informacjami o środowisku wykonawczym) wykonuje pracę niezbędną do korzystania z pakietu SDK z informacjami o środowisku wykonawczym.
Etap 2. Stan stabilny: pakiet SDK z informacjami o środowisku wykonawczym
W przeciwieństwie do rozbudowanego pakietu SDK z obsługą środowiska wykonawczego cienka otoczka lub cienki pakiet SDK z obsługą środowiska wykonawczego (cienki RA_SDK) zawiera w statycznie połączonym pakiecie SDK biblioteki tylko kod tłumaczenia interfejsu API i kod wywoływania pakietu SDK z obsługą środowiska wykonawczego.
Na tym etapie musisz przenieść cały kod pakietu SDK z pakietu SDK statycznej biblioteki aplikacji do pakietu SDK z włączonym środowiskiem wykonawczym.
Deweloperzy aplikacji nie muszą wprowadzać żadnych zmian w stosunku do fazy 1, ponieważ w aplikacji cienki pakiet SDK z włączonym środowiskiem wykonawczym obsługuje wywoływanie pakietu SDK z włączonym środowiskiem wykonawczym w środowisku wykonawczym SDK.
Etap 3. Pełna migracja
W tej ostatniej fazie wszystkie funkcje pakietu SDK zostały przeniesione do pakietu SDK z włączonym środowiskiem wykonawczym, a z aplikacji usunięto wszystkie biblioteki statyczne.
W tym momencie klienci aplikacji nie muszą już uwzględniać bibliotek w swoich kompilacjach, ale wystarczy, że wymienią zależności pakietu SDK w pliku manifestu i uwzględnią wywołania pakietu SDK w kodzie aplikacji.
System przekierowuje wywołania pakietu SDK do środowiska wykonawczego SDK, w którym automatycznie wczytuje się pakiet SDK używany w czasie działania aplikacji.
Krok 2. Skonfiguruj środowisko programistyczne