| Key concepts | Set up your development environment | Build an RE SDK | Consume the RE SDK | Testing, and building for distribution |
Concetti fondamentali
Questa sezione illustra l'architettura di SDK Runtime, la modalità di installazione degli SDK abilitati per il runtime, la compatibilità con le versioni precedenti e come eseguire la migrazione degli SDK esistenti a SDK Runtime.
Glossario
- SDK abilitato per il runtime (RE SDK): un SDK progettato per funzionare nell'ambiente SDK Runtime e comunicare con l'app tramite la comunicazione interprocesso (IPC).
- SDK consapevole del runtime (RA SDK): un SDK non abilitato per il runtime, collegato all'app staticamente, che può contenere il codice SDK esistente e nuovo codice da chiamare nell'SDK abilitato per il runtime.
- A volte viene anche chiamato collegato in modo statico o SDK statico.
- Shim: una libreria Jetpack che consente di astrarre la comunicazione tra processi o la comunicazione interprocessuale (IPC) e di mantenere la stessa interfaccia app-SDK.
Architettura di SDK Runtime
L'SDK Runtime adotta un tipo di modello client-server.
La differenza principale è che il "client" (app) e il "server" (SDK abilitati al runtime) vengono eseguiti sullo stesso dispositivo e questa comunicazione avviene tra processi.
Per aiutarti a risolvere questi problemi, abbiamo creato le seguenti librerie e strumenti Jetpack per semplificare l'integrazione dell'SDK dell'app all'interno del runtime dell'SDK:
- Libreria shim:la libreria wrapper (o shim) consente di astrarre la comunicazione tra processi o la comunicazione inter-processo (IPC). Inoltre, contribuisce a mantenere la stessa interfaccia app-SDK.
- Libreria Backcompat: questa libreria gestisce la compatibilità con le versioni precedenti, assicurando che il tuo SDK sia compatibile indipendentemente dal fatto che il runtime dell'SDK sia disponibile o meno.
- Libreria UI:forniamo anche librerie per gestire la presentazione remota, come il recupero dell'interfaccia utente dall'SDK abilitato per il runtime o il ridimensionamento e il nuovo layout delle visualizzazioni.
Modifiche al flusso di installazione
Quando crei il tuo SDK abilitato per il runtime in Android Studio o in altri strumenti, crei un bundle SDK Android (ASB), un formato di pubblicazione per gli SDK abilitati per il runtime.
bundletool elabora l'ASB per produrre un APK per il tuo SDK abilitato per il runtime: questo APK separato contiene il codice dell'SDK, ma non il codice dell'app.
Il file manifest dell'app dichiara una dipendenza dal nome e dalla versione dell'SDK abilitato per il runtime e questa dipendenza viene risolta dall'app di installazione.
Una volta che l'APK dell'SDK è stato recuperato dal programma di installazione, inizia l'installazione dell'APK dell'SDK. In caso di esito positivo, viene installato l'APK dell'app.
Il flusso è diverso se l'app è installata su Android 13 e versioni precedenti e su dispositivi che non supportano l'ambiente SDK Runtime. In questo scenario, lo store installa un singolo APK contenente sia l'SDK abilitato per il runtime sia il codice dell'app. Per scoprire di più, leggi la sezione sulla distribuzione.
Ogni volta che un'app dipende da questo SDK in produzione, lo store crea l'APK SDK corretto da questo ASB e lo installa.
Compatibilità con le versioni precedenti
Poiché SDK Runtime è stato introdotto in Android 14, dovevamo supportare le versioni precedenti senza introdurre un overhead per gli sviluppatori di app o SDK.
Per gestire la compatibilità con le versioni precedenti su Android 13 e versioni precedenti, abbiamo introdotto una libreria Jetpack che può eseguire senza problemi l'SDK abilitato per il runtime, indipendentemente dal supporto del dispositivo per SDK Runtime.
Se segui questa guida, l'SDK abilitato per il runtime sarà compatibile con le versioni precedenti per impostazione predefinita e non dovrai eseguire altri passaggi.
Evidenziamo le azioni collegate alla compatibilità con le versioni precedenti nelle fasi pertinenti, ma in termini generali, devi assicurarti di aver dichiarato le dipendenze corrette e di utilizzare le classi *Compat, se applicabili.
Esegui la migrazione degli SDK esistenti
Se hai già un SDK di cui vuoi eseguire la migrazione al runtime, non devi eseguire il refactoring dell'intera base di codice in un'unica operazione. In alternativa, puoi scegliere di eseguire la migrazione della logica dell'SDK esistente in modo incrementale nel nuovo SDK abilitato per il runtime.
Per eseguire la migrazione di un SDK esistente nell'ambiente di runtime SDK, consigliamo le tre fasi che seguono:
- Creazione di un SDK abilitato per il runtime per il periodo di transizione insieme a un SDK completo consapevole del runtime. In questo modo puoi eseguire la migrazione incrementale della logica di business dal tuo SDK esistente e avere una piattaforma di test per i test A/B.
- Spostamento di tutta la logica di business dell'SDK esistente in uno stato stabile insieme a un SDK aware del runtime sottile per semplificare la migrazione delle app
- Supporto delle app interessate con migrazione completa per utilizzare direttamente il tuo SDK abilitato per il runtime senza un SDK aware del runtime ridotto
Fase 1 - Periodo di transizione: SDK Thick consapevole del runtime
Puoi iniziare scegliendo di mantenere parte della logica di business nell'SDK sensibile al runtime. Si tratta di un SDK o di un wrapper in-app consapevole del runtime.
Questo approccio ti consente di mantenere tutte o alcune delle funzionalità dell'SDK nella libreria di app statica, insieme a un SDK appena creato abilitato per il runtime.
In questo modo puoi eseguire la migrazione incrementale dei casi d'uso nell'SDK abilitato per il runtime e testare l'SDK abilitato per il runtime rispetto all'SDK esistente.
In questa fase, lo sviluppatore di app non deve modificare il modo in cui utilizza l'SDK, perché è la libreria dell'app statica (SDK consapevole del runtime) a svolgere il lavoro necessario per utilizzare l'SDK consapevole del runtime.
Fase 2 - Stato stabile: SDK Thin consapevole del runtime
A differenza dell'SDK sensibile al runtime completo, un wrapper sottile o un SDK sensibile al runtime sottile (RA_SDK sottile) contiene solo il codice di chiamata dell'SDK abilitato al runtime e la traduzione dell'API nell'SDK della libreria con link statico.
A questo punto, dovresti aver eseguito la migrazione di tutto il codice dell'SDK dall'SDK della libreria di app statica all'SDK abilitato per il runtime.
Gli sviluppatori di app non devono apportare modifiche rispetto alla fase 1 perché l'SDK in-app thin consapevole del runtime gestisce le chiamate all'SDK abilitato per il runtime all'interno del runtime SDK.
Fase 3: migrazione completa
In questa fase finale, hai eseguito la migrazione di tutte le funzionalità dell'SDK nell'SDK abilitato al runtime e hai rimosso tutte le librerie statiche dall'app.
A questo punto, i client dell'app non devono più includere le librerie nelle loro build, ma devono solo elencare le dipendenze dell'SDK nel file manifest e includere le chiamate dell'SDK nel codice dell'app.
Le chiamate dell'SDK vengono inoltrate dal sistema all'ambiente di runtime dell'SDK, dove viene caricato automaticamente l'SDK abilitato per il runtime.
Passaggio 2: configura l'ambiente di sviluppo