Tempi di avvio dell'app

Gli utenti si aspettano che le app si carichino rapidamente e siano reattive. Un'app con un tempo di avvio lento non soddisfa questa aspettativa e può deludere gli utenti. Questo tipo di esperienza scadente può indurre un utente a valutare negativamente la tua app sul Play Store o persino ad abbandonarla del tutto.

Questa pagina fornisce informazioni per ottimizzare il tempo di avvio dell'app, inclusa una panoramica del funzionamento interno della procedura di avvio, come profilare le prestazioni di avvio e alcuni problemi comuni relativi al tempo di avvio, con suggerimenti su come risolverli.

Informazioni sui diversi stati di avvio delle app

L'avvio dell'app può avvenire in uno dei tre stati: avvio a freddo, avvio a caldo o avvio rapido. Ogni stato influisce sul tempo necessario affinché l'app diventi visibile all'utente. In un avvio a freddo, l'app viene avviata da zero. Negli altri stati, il sistema deve portare l'app in esecuzione dal background al primo piano.

Ti consigliamo di eseguire sempre l'ottimizzazione in base all'ipotesi di un avvio a freddo. In questo modo, è possibile migliorare anche le prestazioni degli avvii a caldo.

Per ottimizzare l'app per l'avvio rapido, è utile capire cosa succede a livello di sistema e di app e come interagiscono in ciascuno di questi stati.

Due metriche importanti per determinare l'avvio dell'app sono il tempo di attesa per la prima schermata (TTID) e il tempo di attesa per il rendering completo (TTFD). TTID è il tempo necessario per visualizzare il primo frame, mentre TTFD è il tempo necessario per rendere l'app completamente interattiva. Entrambi sono ugualmente importanti, perché il TTID indica all'utente che l'app è in fase di caricamento, mentre il TTFD indica quando l'app è effettivamente utilizzabile. Se uno di questi è troppo lungo, l'utente potrebbe uscire dalla tua app prima ancora che venga caricata completamente.

Avvio a freddo

Un avvio a freddo si riferisce all'avvio di un'app da zero. Ciò significa che fino a questo avvio, il processo del sistema crea il processo dell'app. Gli avvii completi si verificano in casi come l'avvio dell'app per la prima volta dall'avvio del dispositivo o da quando il sistema ha chiuso l'app.

Questo tipo di avvio presenta la sfida maggiore per ridurre al minimo il tempo di avvio, perché il sistema e l'app svolgono più operazioni rispetto agli altri stati di lancio.

All'inizio di un avviamento a freddo, il sistema deve svolgere le tre attività seguenti:

1. Carica e avvia l'app.
2. Visualizza una finestra iniziale vuota per l'app subito dopo l'avvio.
3. Crea il processo dell'app.

Non appena il sistema crea il processo dell'app, quest'ultimo è responsabile delle fasi successive:

1. Crea l'oggetto app.
2. Avvia il thread principale.
3. Crea l'attività principale.
4. Aumentare artificialmente le visualizzazioni.
5. Disponi gli elementi sullo schermo.
6. Esegui il prelievo iniziale.

Quando il processo dell'app completa il primo disegno, il processo di sistema sostituisce la finestra di sfondo visualizzata con l'attività principale. A questo punto, l'utente può iniziare a utilizzare l'app.

La Figura 1 mostra come i processi di sistema e delle app si passano il lavoro a vicenda.

Possono verificarsi problemi di prestazioni durante la creazione dell'app e dell'attività.

Creazione di app

All'avvio dell'app, la finestra iniziale vuota rimane sullo schermo finché il sistema non termina di disegnare l'app per la prima volta. A questo punto, il processo di sistema scambia la finestra iniziale dell'app, consentendo all'utente di interagire con l'app.

Se esegui l'override di Application.onCreate() nella tua app, il sistema richiama il metodo onCreate() sull'oggetto app. Successivamente, l'app genera il thread principale, noto anche come thread dell'interfaccia utente, e gli assegna il compito di creare l'attività principale.

Da questo punto, i processi a livello di sistema e di app procedono in base alle fasi del ciclo di vita dell'app.

Creazione di attività

Dopo che il processo dell'app crea l'attività, questa esegue le seguenti operazioni:

1. Inizializza i valori.
2. Chiama i costruttori.
3. Chiama il metodo di callback, ad esempio Activity.onCreate(), appropriato per lo stato attuale del ciclo di vita dell'attività.

In genere, il metodo onCreate() ha il maggiore impatto sul tempo di caricamento, perché esegue il lavoro con il sovraccarico più elevato: caricamento e espansione delle visualizzazioni e inizializzazione degli oggetti necessari per l'esecuzione dell'attività.

Avvio tiepido

Un avvio tiepido comprende un sottoinsieme delle operazioni che vengono eseguite durante un avvio a freddo. Allo stesso tempo, rappresenta un overhead maggiore rispetto a un avvio a caldo. Esistono molti stati potenziali che possono essere considerati avvii a caldo, ad esempio i seguenti:

• L'utente esce dalla tua app, ma poi la riavvia. Il processo potrebbe continuare a essere eseguito, ma l'app deve ricreare l'attività da zero utilizzando una chiamata a onCreate().

• Il sistema rimuove l'app dalla memoria e l'utente la riavvia. Il processo e l'attività devono essere riavviati, ma l'attività può trarre vantaggio in qualche modo dal bundle dello stato dell'istanza salvato passato a onCreate().

Avvio a caldo

Un avvio a caldo della tua app ha un overhead inferiore rispetto a un avvio a freddo. In un avvio a caldo, il sistema porta l'attività in primo piano. Se tutte le attività dell'app sono ancora residenti in memoria, l'app può evitare di ripetere l'inizializzazione dell'oggetto, l'inflazione del layout e il rendering.

Tuttavia, se parte della memoria viene eliminata in risposta a eventi di riduzione della memoria, ad esempio onTrimMemory(), questi oggetti devono essere ricreati in risposta all'evento di avvio a caldo.

Un avvio a caldo mostra lo stesso comportamento sullo schermo di uno scenario di avvio a freddo. Il processo di sistema mostra una schermata vuota finché l'app non termina il rendering dell'attività.

Come identificare l'avvio dell'app in Perfetto

Per eseguire il debug dei problemi di avvio dell'app, è utile determinare cosa è incluso esattamente nella fase di avvio dell'app. Per identificare l'intera fase di avvio dell'app in Perfetto, segui questi passaggi:

1. In Perfetto, trova la riga con la metrica derivata Avvii app Android. Se non lo vedi, prova ad acquisire una traccia utilizzando l'app Tracciamento di sistema sul dispositivo.

   

2. Fai clic sulla sezione associata e premi m per selezionarla. Le parentesi vengono visualizzate intorno alla sezione e indicano la durata. La durata viene mostrata anche nella scheda Selezione corrente.

3. Blocca la riga Avvii di app per Android facendo clic sull'icona a forma di puntina, che è visibile quando tieni il puntatore sopra la riga.

4. Scorri fino alla riga con l'app in questione e fai clic sulla prima cella per espandere la riga.

5. Aumenta lo zoom sul thread principale, di solito in alto, premendo w (premi s, a, d per diminuire lo zoom, spostarti a sinistra e a destra, rispettivamente).

   

6. La sezione delle metriche derivate semplifica la visualizzazione esatta di ciò che è incluso nell'avvio dell'app, in modo da poter continuare il debug in modo più dettagliato.

Utilizzare le metriche per esaminare e migliorare le startup

Per diagnosticare correttamente le prestazioni del tempo di avvio, puoi monitorare le metriche che mostrano quanto tempo impiega la tua app ad avviarsi. Android offre diversi modi per mostrarti che la tua app ha un problema e ti aiuta a diagnosticarlo. Android vitals può avvisarti quando si verifica un problema e gli strumenti di diagnostica possono aiutarti a diagnosticarlo.

Vantaggi dell'utilizzo delle metriche per le startup

Android utilizza le metriche tempo di attesa per la prima schermata (TTID) e tempo di attesa per la schermata completa (TTFD) per ottimizzare gli avvii a freddo e a caldo delle app. Android Runtime (ART) utilizza i dati di queste metriche per precompilare in modo efficiente il codice per l'ottimizzazione dei futuri avvii.

Avvii più rapidi portano a un'interazione utente più sostenuta con la tua app, il che riduce i casi di uscita anticipata, riavvio dell'istanza o navigazione verso un'altra app.

Android vitals

Android vitals può contribuire a migliorare le prestazioni della tua app avvisandoti su Play Console quando i tempi di avvio dell'app sono eccessivi.

Android vitals considera eccessivi i seguenti tempi di avvio per la tua app:

• L'avvio a freddo richiede almeno 5 secondi.
• L'avvio tiepido richiede 2 secondi o più.
• L'avvio rapido richiede almeno 1,5 secondi.

Android vitals utilizza la metrica tempo di attesa per la prima schermata (TTID). Per informazioni su come Google Play raccoglie i dati Android vitals, consulta la documentazione di Play Console.

Tempo di attesa per la prima schermata

Il tempo di attesa per la prima schermata (TTID) è il tempo necessario per visualizzare il primo frame dell'interfaccia utente dell'app. Questa metrica misura il tempo necessario a un'app per produrre il primo frame, inclusa l'inizializzazione del processo durante un avvio a freddo, la creazione dell'attività durante un avvio a freddo o tiepido e la visualizzazione del primo frame. Mantenere basso il TTID della tua app contribuisce a migliorare l'esperienza utente consentendo agli utenti di vedere l'app avviarsi rapidamente. L'ID pubblicità viene segnalato automaticamente per ogni app dal framework Android. Quando esegui l'ottimizzazione per l'avvio dell'app, ti consigliamo di implementare reportFullyDrawn per ottenere informazioni fino al TTFD.

TTID viene misurato come valore temporale che rappresenta il tempo totale trascorso che include la seguente sequenza di eventi:

• Avvio della procedura.
• Inizializzazione degli oggetti.
• Creazione e inizializzazione dell'attività.
• Gonfiaggio del layout.
• Disegno dell'app per la prima volta.

Recuperare l'ID TT

Per trovare l'ID dispositivo di test, cerca nello strumento a riga di comando Logcat una riga di output contenente un valore denominato Displayed. Questo valore è il TTID e ha un aspetto simile al seguente esempio, in cui il TTID è 3s534ms:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms

Per trovare l'ID pubblicità in Android Studio, disattiva i filtri nella visualizzazione Logcat dal menu a discesa dei filtri e poi trova l'ora Displayed, come mostrato nella figura 5. La disattivazione dei filtri è necessaria perché questo log viene pubblicato dal server di sistema, non dall'app stessa.

La metrica Displayed nell'output di Logcat non acquisisce necessariamente la quantità di tempo necessaria per caricare e visualizzare tutte le risorse. Esclude le risorse a cui non viene fatto riferimento nel file di layout o che l'app crea come parte dell'inizializzazione dell'oggetto. Esclude queste risorse perché il loro caricamento è un processo inline e non blocca la visualizzazione iniziale dell'app.

A volte la riga Displayed nell'output di Logcat contiene un campo aggiuntivo per il tempo totale. Ad esempio:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)

In questo caso, la misurazione della prima volta riguarda solo l'attività disegnata per prima. La misurazione del tempo total inizia all'avvio del processo dell'app e può includere un'altra attività avviata per prima, ma che non visualizza nulla sullo schermo. La misurazione del tempo total viene mostrata solo quando esiste una differenza tra i tempi di avvio della singola attività e quelli totali.

Ti consigliamo di utilizzare Logcat in Android Studio, ma se non utilizzi Android Studio, puoi misurare TTID anche eseguendo l'app con il comando shell adb Activity Manager. Ecco un esempio:

adb [-d|-e|-s <serialNumber>] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN

La metrica Displayed viene visualizzata nell'output di Logcat come in precedenza. La finestra del terminale mostra quanto segue:

Starting: Intent
Activity: com.example.app/.MainActivity
ThisTime: 2044
TotalTime: 2044
WaitTime: 2054
Complete

Gli argomenti -c e -a sono facoltativi e consentono di specificare <category> e <action>.

Tempo di attesa per la visualizzazione completa

Tempo alla visualizzazione completa (TTFD) è il tempo necessario affinché un'app diventi interattiva per l'utente. Viene segnalato come il tempo necessario per visualizzare il primo frame dell'interfaccia utente dell'app, nonché i contenuti caricati in modo asincrono dopo la visualizzazione del frame iniziale. In genere, si tratta dei contenuti principali caricati dalla rete o dal disco, come segnalato dall'app. In altre parole, il TTFD include il TTID e il tempo necessario per rendere utilizzabile l'app. Mantenere basso il TTFD della tua app contribuisce a migliorare l'esperienza utente consentendo agli utenti di interagire rapidamente con la tua app.

Il sistema determina l'ID TTID quando Choreographer chiama il metodo onDraw() dell'attività e quando sa di chiamarlo per la prima volta. Tuttavia, il sistema non sa quando determinare il TTFD perché ogni app si comporta in modo diverso. Per determinare il TTFD, l'app deve segnalare al sistema quando raggiunge lo stato di disegno completo.

Recuperare TTFD

Per trovare TTFD, segnala lo stato completamente disegnato chiamando il metodo reportFullyDrawn() di ComponentActivity. Il metodo reportFullyDrawn segnala quando l'app è completamente disegnata e in uno stato utilizzabile. Il TTFD è il tempo trascorso da quando il sistema riceve l'intent di avvio dell'app a quando viene chiamato reportFullyDrawn(). Se non chiami reportFullyDrawn(), non viene segnalato alcun valore TTFD.

Per misurare il TTFD, chiama reportFullyDrawn() dopo aver disegnato completamente la UI e tutti i dati. Non chiamare reportFullyDrawn() prima che la finestra della prima attività venga disegnata e visualizzata come misurato dal sistema, perché in questo caso il sistema riporta il tempo misurato dal sistema. In altre parole, se chiami reportFullyDrawn() prima che il sistema rilevi TTID, il sistema segnala TTID e TTFD come lo stesso valore, ovvero il valore TTID.

Quando utilizzi reportFullyDrawn(), Logcat mostra un output simile al seguente esempio, in cui il TTFD è 1 s 54 ms:

system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms

L'output di Logcat a volte include un orario total, come descritto in Tempo alla visualizzazione iniziale.

Se i tempi di visualizzazione sono più lenti di quanto desideri, puoi provare a identificare i colli di bottiglia nel processo di avvio.

Puoi utilizzare reportFullyDrawn() per segnalare lo stato completamente estratto nei casi di base in cui sai che è stato raggiunto lo stato completamente estratto. Tuttavia, nei casi in cui i thread in background devono completare il lavoro in background prima di raggiungere lo stato di disegno completo, devi ritardare reportFullyDrawn() per una misurazione TTFD più accurata. Per scoprire come ritardare reportFullyDrawn(), consulta la sezione successiva.

Migliorare la precisione della tempistica di avvio

Se la tua app esegue il caricamento differito e la visualizzazione iniziale non include tutte le risorse, ad esempio quando l'app recupera le immagini dalla rete, potresti ritardare la chiamata a reportFullyDrawn fino a quando l'app non diventa utilizzabile, in modo da poter includere il popolamento dell'elenco nel benchmark tempistico.

Ad esempio, se la UI contiene un elenco dinamico, come un RecyclerView o un elenco pigro, questo potrebbe essere compilato da un'attività in background che viene completata dopo il primo disegno dell'elenco e, pertanto, dopo che la UI è stata contrassegnata come completamente disegnata. In questi casi, la compilazione dell'elenco non è inclusa nel benchmarking.

Per includere il popolamento dell'elenco nel calcolo del benchmark, recupera FullyDrawnReporter utilizzando getFullyDrawnReporter() e aggiungi un reporter nel codice dell'app. Rilascia il reporter dopo che l'attività in background ha completato il popolamento dell'elenco.

FullyDrawnReporter non chiama il metodo reportFullyDrawn() finché tutti i reporter aggiunti non vengono rilasciati. Se aggiungi un reporter fino al completamento del processo in background, i tempi includono anche il tempo necessario per compilare l'elenco nei dati di temporizzazione dell'avvio. Ciò non modifica il comportamento dell'app per l'utente, ma consente ai dati di avvio della tempistica di includere il tempo necessario per compilare l'elenco. reportFullyDrawn() viene chiamato solo dopo il completamento di tutte le attività, indipendentemente dall'ordine.

Il seguente esempio mostra come eseguire più attività in background contemporaneamente, con ognuna che registra il proprio reporter:

class MainActivity : ComponentActivity() {

    sealed interface ActivityState {
        data object LOADING : ActivityState
        data object LOADED : ActivityState
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            var activityState by remember {
                mutableStateOf(ActivityState.LOADING as ActivityState)
            }
            fullyDrawnReporter.addOnReportDrawnListener {
                activityState = ActivityState.LOADED
            }
            ReportFullyDrawnTheme {
                when(activityState) {
                    is ActivityState.LOADING -> {
                        // Display the loading UI.
                    }
                    is ActivityState.LOADED -> {
                        // Display the full UI.
                    }
                }
            }
            SideEffect {
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
            }
        }
    }
}

public class MainActivity extends ComponentActivity {
    private FullyDrawnReporter fullyDrawnReporter;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        fullyDrawnReporter = getFullyDrawnReporter();
        fullyDrawnReporter.addOnReportDrawnListener(() -> {
            // Trigger the UI update.
            return Unit.INSTANCE;
        });

        new Thread(new Runnable() {
            @Override
            public void run() {
                fullyDrawnReporter.addReporter();
                // Do the background work.
                fullyDrawnReporter.removeReporter();
            }
        }).start();
        new Thread(new Runnable() {
            @Override
            public void run() {
                fullyDrawnReporter.addReporter();
                // Do the background work.
                fullyDrawnReporter.removeReporter();
            }
        }).start();
    }
}

Se la tua app utilizza Jetpack Compose, puoi utilizzare le seguenti API per indicare lo stato completamente disegnato:

• ReportDrawn: indica che il composable è immediatamente pronto per l'interazione.
• ReportDrawnWhen: accetta un predicato, ad esempio list.count > 0, per indicare quando il composable è pronto per l'interazione.
• ReportDrawnAfter: accetta un metodo di sospensione che, una volta completato, indica che il composable è pronto per l'interazione.

Identificare i colli di bottiglia

Per cercare colli di bottiglia, puoi utilizzare il CPU Profiler di Android Studio. Per saperne di più, consulta Esaminare l'attività della CPU con CPU Profiler.

Puoi anche ottenere informazioni sui potenziali colli di bottiglia tramite la tracciatura in linea all'interno dei metodi onCreate() delle tue app e delle tue attività. Per informazioni sulla tracciabilità in linea, consulta la documentazione delle funzioni Trace e la panoramica della tracciabilità del sistema.

Risolvere i problemi comuni

Questa sezione illustra diversi problemi che spesso influiscono sulle prestazioni di avvio delle app. Questi problemi riguardano principalmente l'inizializzazione di oggetti app e attività, nonché il caricamento delle schermate.

Inizializzazione pesante dell'app

Le prestazioni di avvio possono risentirne quando il codice esegue l'override dell'oggetto Application ed esegue operazioni pesanti o logica complessa durante l'inizializzazione dell'oggetto. L'app potrebbe sprecare tempo durante l'avvio se le sottoclassi Application eseguono inizializzazioni che non devono ancora essere eseguite.

Alcune inizializzazioni potrebbero essere completamente inutili, ad esempio quando si inizializzano le informazioni sullo stato per l'attività principale quando l'app viene avviata in risposta a un intent. Con un intent, l'app utilizza solo un sottoinsieme dei dati di stato inizializzati in precedenza.

Altre sfide durante l'inizializzazione dell'app includono eventi di garbage collection che sono di impatto o numerosi oppure I/O del disco che si verificano contemporaneamente all'inizializzazione, il che blocca ulteriormente il processo di inizializzazione. La garbage collection è un aspetto da considerare soprattutto con il runtime Dalvik; Android Runtime (ART) esegue la garbage collection in modo simultaneo, riducendo al minimo l'impatto di questa operazione.

Diagnosticare il problema

Puoi utilizzare la traccia del metodo o la traccia incorporata per provare a diagnosticare il problema.

Tracciamento del metodo

L'esecuzione di CPU Profiler rivela che il metodo callApplicationOnCreate() alla fine chiama il metodo com.example.customApplication.onCreate. Se lo strumento mostra che l'esecuzione di questi metodi richiede molto tempo, esplora ulteriormente per vedere cosa sta succedendo.

Tracciamento in linea

Utilizza la tracciatura in linea per esaminare i probabili responsabili, tra cui:

• La funzione onCreate() iniziale della tua app.
• Qualsiasi oggetto singleton globale inizializzato dalla tua app.
• Qualsiasi I/O del disco, deserializzazione o ciclo stretto che potrebbe verificarsi durante il collo di bottiglia.

Soluzioni al problema

Che il problema risieda in inizializzazioni non necessarie o in I/O del disco, la soluzione è l'inizializzazione differita. In altre parole, inizializza solo gli oggetti necessari immediatamente. Anziché creare oggetti statici globali, passa a un pattern singleton in cui l'app inizializza gli oggetti solo la prima volta che ne ha bisogno.

Inoltre, valuta la possibilità di utilizzare un framework di iniezione delle dipendenze come Hilt che crea oggetti e dipendenze quando vengono inseriti per la prima volta.

Se la tua app utilizza content provider per inizializzare i componenti dell'app all'avvio, valuta la possibilità di utilizzare la libreria di avvio delle app.

Inizializzazione attività intensa

La creazione di attività spesso comporta un lavoro con costi generali elevati. Spesso, ci sono opportunità per ottimizzare questo lavoro al fine di ottenere miglioramenti delle prestazioni. Questi problemi comuni includono:

• Gonfiaggio di layout grandi o complessi.
• Blocco del disegno dello schermo su disco o I/O di rete.
• Caricamento e decodifica delle bitmap.
• Rasterizzazione degli oggetti VectorDrawable.
• Inizializzazione di altri sottosistemi dell'attività.

Diagnosticare il problema

Anche in questo caso, sia il tracciamento dei metodi sia il tracciamento in linea possono essere utili.

Tracciamento del metodo

Quando utilizzi il Profiler CPU, presta attenzione ai costruttori di sottoclassi Application e ai metodi com.example.customApplication.onCreate() della tua app.

Se lo strumento mostra che l'esecuzione di questi metodi richiede molto tempo, esplora ulteriormente per vedere cosa sta succedendo.

Tracciamento in linea

Utilizza la tracciatura in linea per esaminare i probabili responsabili, tra cui:

• La funzione onCreate() iniziale della tua app.
• Qualsiasi oggetto singleton globale che inizializza.
• Qualsiasi I/O del disco, deserializzazione o ciclo stretto che potrebbe verificarsi durante il collo di bottiglia.

Soluzioni al problema

Esistono molti potenziali colli di bottiglia, ma due problemi comuni e rimedi sono i seguenti:

• Più grande è la gerarchia di oggetti View, più tempo impiega l'app per eseguire l'inflate. Ecco due passaggi che puoi seguire per risolvere il problema:
  • Appiattisci la gerarchia di oggetti View riducendo i layout ridondanti o nidificati.
  • Non gonfiare le parti dell'interfaccia utente che non devono essere visibili durante l'avvio. Utilizza invece un oggetto ViewStub come segnaposto per le sotto-gerarchie che l'app può espandere in un momento più opportuno.
• L'inizializzazione di tutte le risorse sul thread principale può anche rallentare l'avvio. Per risolvere il problema:
  • Sposta tutta l'inizializzazione delle risorse in modo che l'app possa eseguirla in modo differito su un thread diverso.
  • Consenti all'app di caricare e visualizzare le tue visualizzazioni, quindi aggiorna in un secondo momento le proprietà visive che dipendono da bitmap e altre risorse.

Schermate iniziali personalizzate

Potresti notare un tempo aggiuntivo aggiunto durante l'avvio se in precedenza hai utilizzato uno dei seguenti metodi per implementare una schermata iniziale personalizzata in Android 11 (livello API 30) o versioni precedenti:

• Utilizzando l'attributo del tema windowDisablePreview per disattivare la schermata iniziale vuota disegnata dal sistema durante l'avvio.
• Utilizzando un Activity dedicato.

A partire da Android 12, è obbligatoria la migrazione all'API SplashScreen. Questa API consente un avvio più rapido e ti permette di modificare la schermata iniziale nei seguenti modi:

• Imposta un tema per modificare l'aspetto della schermata iniziale.
• Controlla per quanto tempo viene visualizzata la schermata iniziale con windowSplashScreenAnimationDuration.
• Personalizza l'animazione della schermata iniziale e gestisci l'animazione per chiudere la schermata iniziale.

Inoltre, la libreria di compatibilità esegue il backporting dell'API SplashScreen per abilitare la compatibilità con le versioni precedenti e per creare un aspetto coerente per la visualizzazione della schermata iniziale in tutte le versioni di Android.

Per maggiori dettagli, consulta la guida alla migrazione della schermata iniziale.