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 addirittura ad abbandonarla del tutto.

Questa pagina fornisce informazioni per ottimizzare il tempo di lancio dell'app, tra cui una panoramica degli aspetti interni del processo di lancio, come profilare le prestazioni di avvio e alcuni problemi comuni relativi al tempo di avvio con suggerimenti su come risolverli.

Nota: per informazioni su come Android Play Vitals monitora e segnala questo problema, consulta Tempo di avvio dell'app in Android vitals.

Informazioni sui diversi stati di avvio dell'app

L'avvio dell'app può avvenire in uno dei tre stati: avvio a freddo, avvio tiepido o avvio a caldo. 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 ottimizzare sempre in base all'ipotesi di un avvio completo. In questo modo, puoi migliorare anche le prestazioni degli avvii intermedi e rapidi.

Per ottimizzare l'app per un 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 affinché l'app diventi completamente interattiva. Entrambe sono ugualmente importanti, perché il TTID consente all'utente di sapere che l'app è in fase di caricamento, mentre il TTFD indica quando l'app è effettivamente utilizzabile. Se uno di questi tempi è troppo lungo, l'utente potrebbe uscire dall'app prima ancora che venga caricata completamente.

Avvio a freddo

Un avvio completo 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 a freddo si verificano in casi come il lancio dell'app per la prima volta dall'avvio del dispositivo o dall'interruzione dell'app da parte del sistema.

Questo tipo di avvio rappresenta la sfida più grande per ridurre al minimo il tempo di avvio, perché il sistema e l'app hanno più lavoro da fare rispetto agli altri stati di lancio.

All'inizio di un cold start, il sistema deve eseguire le tre seguenti attività:

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 la UI.
5. Disegna la UI sullo schermo.

Quando il processo dell'app completa il primo disegno, il processo di sistema scambia la finestra di sfondo visualizzata, sostituendola 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.

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

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 con la tua 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 dell'app. In seguito, 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.

A 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 ha creato l'attività, quest'ultima 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 l'impatto maggiore sul tempo di caricamento. In un'app Jetpack Compose, l'overhead del metodo onCreate spesso deriva dalla composizione iniziale. Questo accade quando l'app chiama setContent e richiama i composable di primo livello. Una gerarchia UI profonda o complessa o composable che eseguono calcoli complessi sul thread principale possono aumentare questo tempo di composizione.

Avvio tiepido

Un avvio a caldo comprende un sottoinsieme delle operazioni che si verificano durante un avvio a freddo. Allo stesso tempo, rappresenta un overhead maggiore rispetto a un avvio rapido. Esistono molti stati potenziali che possono essere considerati cold start, ad esempio:

• 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 un certo vantaggio 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 dell'app. Se tutta la UI dell'app è ancora residente in memoria, l'app può evitare di ripetere l'inizializzazione degli oggetti, l'inizializzazione della UI e il rendering.

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

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

Figura 1. Un diagramma con i vari stati di avvio e i rispettivi processi, con ogni stato che inizia dal primo frame disegnato.

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, individua la riga con la metrica derivata Avvii di app per Android. Se non lo vedi, prova ad acquisire una traccia utilizzando l'app di tracciamento del sistema on-device.

   

   Figura 2. La sezione della metrica derivata Avvii di app per Android in Perfetto.

2. Fai clic sulla sezione associata e premi m per selezionarla. Attorno alla sezione vengono visualizzate delle parentesi che indicano il tempo impiegato. La durata viene visualizzata anche nella scheda Selezione corrente.

3. Fissa la riga Android App Startups facendo clic sull'icona della puntina, che è visibile quando passi il puntatore del mouse sulla riga.

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

5. Ingrandisci il thread principale, di solito in alto, premendo W (premi S, A, D per diminuire lo zoom, spostarti a sinistra e spostarti a destra, rispettivamente).

   

   Figura 3. La sezione della metrica derivata Avvii di app per Android accanto al thread principale dell'app.

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

Quando analizzi un'applicazione Jetpack Compose, puoi utilizzare il tracciamento della composizione per visualizzare dettagli granulari sul rendimento della 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 mostrano quanto tempo la tua app impiega per comporre, misurare, posizionare e disegnare componenti specifici.

Utilizza le metriche per ispezionare e migliorare le startup

Per diagnosticare correttamente le prestazioni del tempo di avvio, puoi monitorare le metriche che mostrano il tempo necessario per l'avvio dell'app. Android offre diversi modi per mostrare che la tua app ha un problema e ti aiuta 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 degli avvii futuri.

Avvii più rapidi portano a un'interazione più prolungata degli utenti con la tua app, il che riduce i casi di uscita anticipata, riavvio dell'istanza o abbandono dell'app per un'altra.

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'UI 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 a caldo e la visualizzazione del primo frame. Se mantieni basso il TTID della tua app, puoi migliorare l'esperienza utente consentendo agli utenti di vedere l'avvio rapido dell'app. Il TTID viene registrato 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 un valore temporale che rappresenta il tempo totale trascorso che include la seguente sequenza di eventi:

• Avvio del processo.
• Inizializzazione degli oggetti.
• Creazione e inizializzazione dell'attività host.
• Inizializzazione della UI.
• Disegno dell'app per la prima volta.

Recupera TTID

Per trovare il TTID, 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 il TTID in Android Studio, disattiva i filtri nella visualizzazione Logcat dal menu dei filtri a discesa, quindi trova il tempo Displayed, come mostrato nella Figura 4. La disattivazione dei filtri è necessaria perché questo log viene fornito dal server di sistema, non dall'app stessa.

Figura 4. Filtri disattivati e valore Displayed in Logcat.

La metrica Displayed nell'output di Logcat non acquisisce necessariamente il tempo necessario per caricare e visualizzare tutte le risorse. Esclude le risorse non referenziate nella composizione iniziale (come dati o immagini caricati in modo asincrono) o le risorse create dall'app durante l'inizializzazione degli oggetti. Queste risorse vengono escluse perché il loro caricamento è un processo in linea e non blocca la visualizzazione iniziale dell'app. Per saperne di più sulle risorse, consulta Risorse in Compose.

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

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

In questo caso, la prima misurazione del tempo riguarda solo l'attività che viene 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à che viene avviata per prima, ma non mostra 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 anche misurare il TTID eseguendo l'app con il comando di gestione delle attività della shell adb. 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 prima. Nella finestra del terminale viene visualizzato 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 visualizzazione completa

Il tempo di visualizzazione completa (TTFD) è il tempo necessario affinché un'app diventi interattiva per l'utente. Viene registrato come il tempo necessario per visualizzare il primo frame della UI 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, il TTFD include il TTID e il tempo necessario per rendere l'app utilizzabile. Se mantieni basso il TTFD della tua app, puoi 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 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 di disegno completo.

Recupera TTFD

Per trovare il TTFD, segnala lo stato di disegno completo 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 registrato 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 segnala il tempo misurato dal sistema. In altre parole, se chiami reportFullyDrawn prima che il sistema rilevi il TTID, il sistema segnala sia il TTID che il TTFD con lo stesso valore, che corrisponde al valore del TTID.

Quando utilizzi reportFullyDrawn, Logcat visualizza un output simile all'esempio seguente, in cui il TTFD è 1s54ms:

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

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

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

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

Migliora l'accuratezza dei tempi di avvio

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

Ad esempio, se la UI contiene un elenco dinamico, come un LazyColumn o un LazyRow, questo potrebbe essere compilato da un'attività in background che viene completata dopo che l'elenco è stato disegnato per la prima volta e, di conseguenza, dopo che la UI è stata contrassegnata come completamente disegnata. In questi casi, la popolazione dell'elenco non viene inclusa nel benchmarking.

Per includere la popolazione dell'elenco nel tempo di benchmark, recupera FullyDrawnReporter utilizzando fullyDrawnReporter e aggiungi un reporter nel codice dell'app. Rilascia il reporter dopo che l'attività in background ha completato la compilazione dell'elenco.

FullyDrawnReporter non chiama il metodo reportFullyDrawn finché non vengono rilasciati tutti i reporter aggiunti. Aggiungendo un reporter, ma non rilasciandolo fino al completamento del processo in background, ti assicuri che i dati relativi ai tempi di avvio includano il tempo di compilazione dell'elenco, senza modificare il comportamento dell'app per l'utente. reportFullyDrawn non viene chiamato finché tutte le attività non sono state completate, 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.

L'esempio seguente mostra come eseguire più attività in background contemporaneamente, ognuna con 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()
                }
            }
        }
    }
}

Identifica i colli di bottiglia

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

Puoi anche ottenere informazioni su potenziali colli di bottiglia tramite il tracciamento in linea all'interno dei metodi onCreate delle tue app e attività. Per scoprire di più sul tracciamento in linea, consulta la documentazione relativa alle funzioni Trace e la panoramica del tracciamento del sistema.

Risolvi 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 dell'app e dell'attività, nonché il caricamento delle schermate.

Inizializzazione dell'app pesante

Le prestazioni di avvio possono risentirne quando il codice esegue l'override dell'oggetto Application ed esegue un lavoro pesante o una logica complessa durante l'inizializzazione dell'oggetto. La tua app potrebbe perdere tempo durante l'avvio se le sottoclassi Application eseguono inizializzazioni che non devono ancora essere eseguite.

Alcune inizializzazioni potrebbero essere completamente non necessarie, ad esempio quando si inizializzano le informazioni sullo stato per l'attività principale quando l'app viene effettivamente 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 hanno un impatto o sono numerosi, oppure l'I/O del disco che avviene contemporaneamente all'inizializzazione, il che blocca ulteriormente il processo di inizializzazione. La garbage collection è un aspetto particolarmente importante con il runtime Dalvik; Android Runtime (ART) esegue la garbage collection contemporaneamente, riducendo al minimo l'impatto di questa operazione.

Diagnostica il problema

Puoi utilizzare il tracciamento dei metodi o il tracciamento in linea 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 l'esecuzione di questi metodi richiede molto tempo, approfondisci per vedere quale lavoro viene svolto.

Tracciamento inline

Utilizza il tracciamento in linea per indagare sui probabili colpevoli, tra cui:

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

Soluzioni al problema

Che il problema risieda in inizializzazioni non necessarie o nell'I/O del disco, la soluzione è l'inizializzazione lazy. In altre parole, inizializza solo gli oggetti necessari nell'immediato. 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 dependency injection come Hilt che crea oggetti e dipendenze quando vengono inseriti per la prima volta.

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

Inizializzazione di attività intensa

La creazione di attività spesso comporta un lavoro con un overhead elevato. Spesso esistono opportunità per ottimizzare questo lavoro e ottenere miglioramenti delle prestazioni. Questi problemi comuni includono:

• Inizializzazione di una UI di grandi dimensioni o complessa.
• Inizializzazione pesante nei componibili.
• Blocco del disegno dello schermo sul disco o sull'I/O di rete.
• Caricamento e decodifica delle bitmap.
• Rasterizzazione di VectorDrawable oggetti in corso.
• Inizializzazione di altri sottosistemi dell'attività host dell'app.

Diagnostica il problema

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

Tracciamento dei metodi

Quando utilizzi CPU Profiler, presta attenzione ai costruttori della sottoclasse Application e ai metodi com.example.customApplication.onCreate della tua app.

Se lo strumento mostra che questi metodi richiedono molto tempo per completare l'esecuzione, esegui ulteriori indagini per vedere quale lavoro viene svolto.

Tracciamento inline

Utilizza il tracciamento in linea per indagare sui probabili colpevoli, tra cui:

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

Soluzioni al problema

I potenziali colli di bottiglia sono molti, ma di seguito sono riportati due problemi comuni e i relativi rimedi:

• Più grande è la gerarchia della UI, più tempo impiega l'app per inizializzarla. Per risolvere questo problema, segui questi passaggi:
  • Semplifica la gerarchia della UI riducendo gli elementi componibili ridondanti o nidificati.
  • Evita composizioni e ricomposizioni non necessarie durante il lancio.
  • Rimanda la composizione della UI non critica.
• Anche l'inizializzazione di tutte le risorse sul thread principale può rallentare l'avvio. Per risolvere il problema:
  • Sposta l'inizializzazione di tutte le risorse in modo che l'app possa eseguirla in modo lazy su un thread diverso.
  • Carica e visualizza prima la UI con dati segnaposto, quindi aggiorna le proprietà visive che dipendono da bitmap e altre risorse.

Per saperne di più sulla ricomposizione, consulta Ricomposizione e Ottieni i conteggi di ricomposizione.

Schermate iniziali personalizzate

Potresti notare un tempo aggiuntivo 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:

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

A partire da Android 12, è necessario eseguire la migrazione all'API SplashScreen. Questa API consente un tempo di 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 consentire 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.