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 la schermata completa (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é TTID indica all'utente che l'app è in fase di caricamento, mentre 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 avvio.

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. Inizializza l'interfaccia utente.
5. Disegna l'interfaccia utente sullo schermo.

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.

Per saperne di più sulle fasi di layout in Compose, consulta Fasi di Jetpack Compose.

Durante la creazione dell'app e dell'attività host possono verificarsi problemi di prestazioni.

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à host dell'app.

Da questo punto, i processi a livello di sistema e 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 allo stato attuale del ciclo di vita dell'attività.

In genere, il metodo onCreate ha l'impatto maggiore sul tempo di caricamento. In un'app Jetpack Compose, l'overhead del metodo onCreate deriva spesso dalla composizione iniziale. Ciò accade quando l'app chiama setContent e richiama i composable di primo livello. Una gerarchia UI profonda o complessa oppure i composable che eseguono calcoli pesanti sul thread principale possono aumentare questo tempo di composizione.

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 in primo piano l'attività host della tua app. Se tutta l'interfaccia utente dell'app è ancora residente in memoria, l'app può evitare di ripetere l'inizializzazione di oggetti, l'inizializzazione dell'interfaccia utente 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 di tracciamento del sistema sul dispositivo.

   

2. Fai clic sulla sezione associata e premi m per selezionarla. Le parentesi vengono visualizzate intorno alla sezione e indicano il tempo impiegato. 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 spostarti 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.

Quando analizzi un'applicazione Jetpack Compose, puoi utilizzare la tracciatura della composizione per visualizzare dettagli granulari sul rendimento della tua UI. Presta particolare attenzione alle sezioni di traccia all'interno del thread principale che iniziano con Choreographer#doFrame. Cerca sezioni come Compose:recompose, Compose:layout e Compose:draw. Questi valori mostrano il tempo che la tua app impiega per comporre, misurare, posizionare e disegnare componenti specifici.

Utilizza 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 che si sta verificando un problema e gli strumenti di diagnostica possono aiutarti a diagnosticarlo.

Vantaggi dell'utilizzo delle metriche delle 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 un avvio 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.

Il 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à host.
• Inizializzazione dell'interfaccia utente.
• 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, quindi trova l'ora Displayed, come mostrato nella figura 4. 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 nella composizione iniziale (come dati o immagini caricati in modo asincrono) o le risorse create dall'app come parte dell'inizializzazione dell'oggetto. Esclude queste risorse perché il loro caricamento è un processo inline e non blocca la visualizzazione iniziale dell'app. Per ulteriori informazioni sulle risorse, consulta Risorse in Compose.

A volte la riga Displayed nell'output di Logcat contiene un campo aggiuntivo per il tempo totale, come nel seguente esempio:

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

In questo caso, la misurazione del primo tempo riguarda solo l'attività disegnata per prima, in genere l'attività host. La misurazione del tempo total inizia all'avvio del processo dell'app e può includere un'altra attività avviata per prima, ma che non mostra nulla sullo schermo. La misurazione del tempo total viene mostrata solo quando c'è 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 che vengono 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, TTFD include TTID e il tempo necessario all'app per essere utilizzabile. Mantenere basso il TTFD della tua app contribuisce a migliorare l'esperienza utente consentendo agli utenti di interagire rapidamente con la tua app.

Sebbene il sistema possa determinare il TTID quando la finestra host esegue il rendering del frame iniziale, non può determinare automaticamente il TTFD. Poiché le app spesso caricano i propri contenuti principali in modo asincrono, il sistema non sa quando l'app è effettivamente completamente utilizzabile dall'utente. Per determinare il TTFD, l'app deve segnalare al sistema quando raggiunge lo stato completamente disegnato.

Recupera 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 dal momento in cui il sistema riceve l'intent di avvio dell'app al momento in cui 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 per la prima volta, 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 sia TTID che 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 di prelievo completo nei casi di base in cui sai che è stato raggiunto. Tuttavia, nei casi in cui i thread in background devono completare il lavoro in background prima di raggiungere lo stato completamente disegnato, 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 voler 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 LazyColumn o LazyRow, questo potrebbe essere compilato da un'attività in background che viene completata dopo il primo disegno dell'elenco e, pertanto, dopo che la UI è 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 fullyDrawnReporter 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é non vengono rilasciati tutti i reporter aggiunti. Se aggiungi un reporter ma non lo rilasci finché il processo in background non viene completato, ti assicuri che i dati di temporizzazione dell'avvio includano il tempo di compilazione dell'elenco, senza modificare il comportamento dell'app per l'utente. reportFullyDrawn viene chiamato solo dopo il completamento di tutte le attività, indipendentemente dall'ordine.

Se la tua app utilizza Jetpack Compose, puoi utilizzare le seguenti API per indicare lo stato di disegno completo:

• 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.

Il seguente esempio mostra come puoi 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()
                }
            }
        }
    }
}

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 scoprire di più 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 degli 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 logiche complesse 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 dei metodi

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

Tracciamento in linea

Utilizza la traccia incorporata per esaminare i probabili responsabili, tra cui:

• La funzione iniziale onCreate della tua app.
• Qualsiasi oggetto singleton globale inizializzato dalla tua app.
• Qualsiasi I/O del disco, deserializzazione o cicli stretti che potrebbero 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.

Valuta anche 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, ti consigliamo di utilizzare la libreria di avvio dell'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:

• Inizializzazione di un'interfaccia utente grande o complessa.
• Inizializzazione pesante nei composable.
• 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à host dell'app.

Diagnosticare il problema

Anche in questo caso, sia la tracciabilità dei metodi sia la tracciabilità in linea possono essere utili.

Tracciamento dei metodi

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 questi metodi richiedono molto tempo per essere eseguiti, 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 cicli stretti che potrebbero 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 della UI, più tempo impiega l'app per inizializzarla. Quando risolvi questo problema, tieni presente i seguenti passaggi:
  • Appiattisci la gerarchia della UI riducendo i composable ridondanti o nidificati.
  • Evita la composizione e la ricomposizione non necessarie durante l'avvio.
  • Rimanda la composizione dell'interfaccia utente non critica.
• 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.
  • Carica e visualizza la tua UI con dati segnaposto e poi aggiorna le proprietà visive che dipendono da bitmap e altre risorse.

Per ulteriori informazioni sulla ricomposizione, consulta Ricomposizione e Recuperare i conteggi di ricomposizione.

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 la durata di visualizzazione della schermata iniziale con windowSplashScreenAnimationDuration.
• Personalizza l'animazione della schermata iniziale e gestisci correttamente 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 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.