| 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 opisaliśmy architekturę środowiska uruchomieniowego SDK, sposób instalowania pakietów SDK używanych w czasie działania, zgodność z wersjami starszymi oraz migrację dotychczasowych pakietów SDK do środowiska uruchomieniowego SDK.
Słowniczek
- Pakiet SDK używany w czasie działania aplikacji (RE SDK): pakiet SDK przeznaczony do działania w środowisku wykonawczym SDK i komunikujący się z aplikacją za pomocą komunikacji międzyprocesowej (IPC).
- Pakiet SDK uwzględniający czas działania: pakiet SDK, który nie jest używany w czasie działania, ale jest połączony ze statyczną aplikacją. Może zawierać dotychczasowy kod SDK oraz nowy kod do wywołania pakietu SDK używanego w czasie działania.
- Czasami nazywa się to linkowaniem statycznym lub statycznym pakietem SDK.
- Shim: biblioteka Jetpack, która ułatwia abstrakcyjną komunikację między procesami lub komunikację między procesami (IPC) i utrzymuje ten sam interfejs pakietu SDK aplikacji.
Architektura środowiska wykonawczego SDK
Środowisko wykonawcze pakietu SDK korzysta z modelu klient-serwer.
Główna różnica polega na tym, że „klient” (aplikacja) i „serwer” (interfejsy SDK włączone w czasie wykonywania) działają na tym samym urządzeniu, a komunikacja odbywa się między procesami.
Aby ułatwić Ci rozwiązanie tych problemów, opracowaliśmy te biblioteki i narzędzia Jetpack, które upraszczają integrację pakietu SDK aplikacji z pakietem SDK Runtime:
- Biblioteka shim: biblioteka opakowania (lub shim) ułatwia abstrakcyjną komunikację między procesami lub komunikację między procesami (IPC). Pomaga też zachować ten sam interfejs pakietu SDK aplikacji.
- Biblioteka zgodna wstecznie: ta biblioteka zapewnia zgodność wsteczną, dzięki czemu pakiet SDK jest zgodny niezależnie od tego, czy środowisko uruchomieniowe pakietu SDK jest dostępne.
- Biblioteka interfejsu: udostępniamy też biblioteki do obsługi prezentacji zdalnej, na przykład pobierania interfejsu z pakietu SDK z włączonym czasem wykonywania lub zmiany rozmiaru i układu widoków.
Zmiany w procesie instalacji
Gdy kompilujesz pakiet SDK używanych w czasie działania w Android Studio lub innych narzędziach, tworzysz pakiet Android SDK (ASB), czyli format publikowania pakietów SDK używanych w czasie działania.
Narzędzie bundletool przetwarza pakiet ASB, aby wygenerować plik APK dla pakietu SDK używanego w czasie działania aplikacji. Ten oddzielny 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ę instalacyjną.
Gdy instalator pozyska pakiet APK pakietu SDK, rozpocznie się instalacja pakietu APK pakietu SDK. Po pomyślnym zakończeniu procesu następuje instalacja pliku APK aplikacji.
Proces jest inny, jeśli aplikacja jest zainstalowana na Androidzie 13 lub starszym oraz na urządzeniach, które nie obsługują środowiska wykonawczego SDK. W tym scenariuszu sklep instaluje jeden plik APK zawierający zarówno pakiet SDK z włączonym środowiskiem wykonawczym, jak i kod aplikacji. Aby dowiedzieć się więcej, przeczytaj sekcję dotyczącą dystrybucji.
Gdy aplikacja korzysta z tego pakietu SDK w wersji produkcyjnej, sklep z aplikacjami tworzy 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ę wcześniejszych wersji bez wprowadzania dodatkowych obciążeń dla deweloperów pakietu SDK lub aplikacji.
Aby zapewnić zgodność wsteczną na Androidzie 13 i starszych, wprowadziliśmy bibliotekę Jetpack, która może płynnie uruchamiać środowisko wykonawcze pakietu SDK niezależnie od obsługi środowiska wykonawczego pakietu SDK na urządzeniu.
Postępowanie zgodnie z tym przewodnikiem spowoduje, że pakiet SDK z włączonym środowiskiem wykonawczym będzie domyślnie zgodny w steczkę. Nie musisz wykonywać żadnych dodatkowych czynności.
W odpowiednich momentach opisujemy, jakie działania należy podjąć w związku z wsteczną zgodnością, ale ogólnie należy zadbać o to, aby zadeklarować odpowiednie zależności i używać klas *Compat, gdy jest to możliwe.
Migracja istniejących pakietów SDK
Jeśli masz istniejący pakiet SDK, który chcesz przenieść do środowiska wykonawczego, nie musisz od razu przerabiać całej bazy kodu. Zamiast tego możesz stopniowo przenosić logikę dotychczasowego pakietu SDK do nowego pakietu SDK z włączonym środowiskiem wykonawczym.
Aby przenieść istniejący pakiet SDK do środowiska wykonawczego pakietu SDK, zalecamy wykonanie tych 3 etapów:
- Tworzenie pakietu SDK używanego w czasie działania w okresie przejściowym wraz z odpowiednim pakietem SDK obsługującym środowisko uruchomieniowe. Dzięki temu możesz stopniowo przenosić logikę biznesową z dotychczasowego pakietu SDK i zyskać platformę do testów A/B.
- Przeniesienie całej logiki biznesowej obecnego pakietu SDK do stanu stabilnego wraz z odpowiednim cienkim pakietem SDK obsługującym czas wykonywania, aby ułatwić migrację aplikacji.
- zapewnienie zainteresowanym aplikacjom pełnej migracji na pakiet SDK z włączonym środowiskiem wykonawczym, który można używać bezpośrednio bez cienkiego pakietu SDK z włączonym środowiskiem wykonawczym;
Etap 1. Okres przejściowy: gruby pakiet SDK obsługujący środowisko wykonawcze
Możesz zacząć od pozostawienia części logiki biznesowej w pakiecie SDK zależnym od środowiska uruchomieniowego. Nazywamy to grubym pakietem SDK świadomym czasu działania lub opakowaniem w aplikacji.
Dzięki temu wszystkie lub niektóre funkcje pakietu SDK będą dostępne w bibliotece statycznej aplikacji, a także w nowo utworzonym pakiecie SDK z włączonym środowiskiem wykonawczym.
Dzięki temu możesz stopniowo przenosić przypadki użycia do pakietu SDK obsługującego środowisko wykonawcze i testować go w porównaniu z dotychczasowym pakietem SDK.
Na tym etapie deweloper aplikacji nie musi wprowadzać żadnych zmian w sposobie korzystania z Twojego pakietu SDK, ponieważ to statyczna biblioteka aplikacji (pakiet SDK zależny od środowiska uruchomieniowego) wykonuje czynności niezbędne do korzystania z Twojego pakietu SDK zależnego od środowiska uruchomieniowego.
Etap 2. Stan stabilny: smukły pakiet SDK obsługujący środowisko uruchomieniowe
W przeciwieństwie do grubego pakietu SDK obsługującego środowisko uruchomieniowe cienki pakiet SDK obsługujący środowisko uruchomieniowe (cienki RA_SDK) zawiera tylko tłumaczenie interfejsu API i kod wywoływania pakietu SDK w bibliotece połączonej statycznie.
Na tym etapie powinieneś przenieść cały kod SDK ze statycznej biblioteki aplikacji do pakietu SDK z włączonym środowiskiem wykonawczym.
Deweloperzy aplikacji nie muszą wprowadzać żadnych zmian z fazy 1, ponieważ interfejs wykonawczy SDK w aplikacji obsługuje wywoływanie pakietu SDK z włączonym środowiskiem wykonawczym w środowisku wykonawczym pakietu SDK.
Etap 3. Pełna migracja
W tej ostatniej fazie przenosisz wszystkie funkcje pakietu SDK do pakietu SDK z wbudowanym środowiskiem uruchomieniowym i usuwasz z aplikacji wszystkie biblioteki statyczne.
W tej chwili klienci aplikacji nie muszą już uwzględniać Twoich bibliotek w kompilacji, ale tylko wymieniać zależności pakietu SDK w pliku manifestu i umieszczać wywołania pakietu SDK w kodzie aplikacji.
System przekierowuje wywołania pakietu SDK do środowiska wykonawczego pakietu SDK, gdzie automatycznie wczytuje się pakiet SDK używany w czasie działania.
