Tempi di avvio dell'app

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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 negativa può indurre un utente a valutare male la tua app sul Play Store o addirittura abbandonarla del tutto.

Questa pagina fornisce informazioni utili per ottimizzare il tempo di avvio dell'app, tra cui una panoramica degli aspetti interni della procedura di lancio, come eseguire il profiling del rendimento all'avvio e alcuni problemi comuni relativi al tempo di avvio con suggerimenti su come risolverli.

Informazioni sui diversi stati di avvio dell'app

L'avvio dell'app può avvenire in uno dei tre stati: avvio a freddo, avvio a caldo o avvio a caldo. Ogni stato influisce sul tempo necessario affinché la tua 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 dall'background in primo piano.

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

Per ottimizzare l'app per l'avvio rapido, è utile capire cosa accade 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 completamento del rendering (TTFD). TTID indica il tempo necessario per visualizzare il primo frame e TTFD il tempo necessario per rendere l'app completamente interattiva. Entrambi sono ugualmente importanti, perché TTID consente all'utente di sapere che l'app è in fase di caricamento e TTFD indica quando l'app è effettivamente utilizzabile. Se uno di questi elementi è troppo lungo, l'utente potrebbe uscire dall'app prima 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 inizio, il processo del sistema crea il processo dell'app. Gli avvii completi si verificano, ad esempio, quando l'app viene avviata per la prima volta dall'avvio del dispositivo o dal momento in cui il sistema ha interrotto l'app.

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

All'inizio di un avvio a freddo, il sistema ha le tre seguenti attività:

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

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

1. Crea l'oggetto app.
2. Avvia il thread principale.
3. Crea l'attività principale.
4. Aumentare le visualizzazioni.
5. Crea il layout della schermata.
6. Esegui il sorteggio 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 il sistema e l'app gestiscono il trasferimento del lavoro tra loro.

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

Creazione di app

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

Se sostituisci Application.onCreate() nella tua app, il sistema invoca 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 in poi, i processi a livello di sistema e di app procedono in conformità con le fasi del ciclo di vita dell'app.

Creazione di attività

Dopo che il processo dell'app ha creato 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, poiché esegue il lavoro con il maggiore overhead: caricamento e espansione delle visualizzazioni e inizializzazione degli oggetti necessari per l'esecuzione dell'attività.

Avvio tiepido

Un avvio a caldo comprende un sottoinsieme delle operazioni che si verificano durante un avvio a freddo. Al tempo stesso, comporta un overhead maggiore rispetto a un riavvio caldo. Esistono molti potenziali stati che possono essere considerati avvii a caldo, ad esempio:

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

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

Avvio a caldo

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

Tuttavia, se una parte di memoria viene eliminata in risposta a eventi di eliminazione della memoria, ad esempio onTrimMemory(), questi oggetti devono essere ricreati in risposta all'evento di avvio 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à.

Come identificare l'avvio dell'app in Perfetto

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

1. In Perfetto, trova la riga con la metrica derivata Avvi app Android. Se non la vedi, prova a acquisire una traccia utilizzando l'app di monitoraggio del sistema sul dispositivo.

   

2. Fai clic sul segmento associato e premi m per selezionarlo. Le parentesi vengono visualizzate intorno al segmento e indicano il tempo impiegato. La durata viene visualizzata anche nella scheda Selezione corrente.

3. Blocca la riga Avvio app Android facendo clic sull'icona a forma di blocco, visibile quando tieni premuto il cursore 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 del thread principale, in genere in alto, premendo w (premi s, a, d per diminuire lo zoom, spostarti a sinistra e a destra, rispettivamente).

   

6. Il segmento delle metriche derivate consente di vedere più facilmente cosa è incluso esattamente nell'avvio dell'app, in modo da poter continuare a eseguire il debug in modo più dettagliato.

Utilizza le metriche per ispezionare e migliorare le startup

Per diagnosticare correttamente il rendimento del tempo di avvio, puoi monitorare le metriche che mostrano il tempo necessario per l'avvio dell'app. Android offre diversi modi per indicarti che la tua app ha un problema e ti aiuta a diagnosticarlo. Android Vitals può informarti che si sta verificando un problema e gli strumenti di diagnostica possono aiutarti a diagnosticarlo.

Vantaggi dell'utilizzo delle metriche relative alle startup

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

Avvii più rapidi comportano un'interazione più prolungata dell'utente con la tua app, il che riduce le istanze di chiusura anticipata, di riavvio dell'istanza o di passaggio a un'altra app.

Android vitals

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

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

• L'avvio a freddo richiede almeno 5 secondi.
• L'avvio a caldo richiede almeno 2 secondi.
• L'avvio a caldo 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 a caldo e la visualizzazione del primo frame. Mantenere basso il TTID della tua app contribuisce a migliorare l'esperienza utente consentendo agli utenti di vedere rapidamente il lancio della tua app. L'ID utente viene registrato automaticamente per ogni app dal framework Android. Quando esegui l'ottimizzazione per l'avvio dell'app, ti consigliamo di implementare reportFullyDrawn per ricevere informazioni fino al TTFD.

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

• Avvio della procedura.
• Inizializzazione degli oggetti.
• Creazione e inizializzazione dell'attività.
• Caricamento del layout.
• 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 è l'ID transazione e ha un aspetto simile all'esempio seguente, in cui l'ID transazione è 3s534ms:

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

Per trovare il TTID in Android Studio, disattiva i filtri nella visualizzazione Logcat dal menu a discesa dei filtri e poi individua l'ora Displayed, come mostrato nella figura 5. La disattivazione dei filtri è necessaria perché è il server di sistema, non l'app stessa, a pubblicare questo log.

La metrica Displayed nell'output di Logcat non acquisisce necessariamente il periodo di tempo necessario per caricare e visualizzare tutte le risorse. Omette le risorse a cui non viene fatto riferimento nel file di layout o che l'app crea nell'ambito dell'inizializzazione dell'oggetto. Le esclude perché il loro caricamento è un processo in linea 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 mostra nulla sullo schermo. La misurazione del tempo total viene visualizzata 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 adbcomando activity manager della shell. 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 ti consentono di specificare <category> e <action>.

Tempo di attesa per la visualizzazione completa

Il tempo di visualizzazione completa (TTFD) è il tempo necessario affinché un'app diventi interattiva per l'utente. Viene indicato 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 di contenuti principali caricati dalla rete o dal disco, come indicato dall'app. In altre parole, il TTFD include il TTID e il tempo necessario per l'utilizzo dell'app. Mantenere basso il valore 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 TT quando Choreographer chiama il metodo onDraw() dell'attività e quando sa che lo chiama 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.

Recupera TTFD

Per trovare il TTFD, indica 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 che intercorre tra il momento in cui il sistema riceve l'intent di lancio dell'app e il momento in cui viene chiamato reportFullyDrawn(). Se non chiami reportFullyDrawn(), non viene riportato alcun valore TTFD.

Per misurare il TTFD, chiama reportFullyDrawn() dopo aver disegnato completamente l'interfaccia utente 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é il sistema registra il tempo misurato dal sistema. In altre parole, se chiami reportFullyDrawn() prima che il sistema rilevi TTID, il sistema registra sia TTID sia TTFD come lo stesso valore, che è il valore TTID.

Quando utilizzi reportFullyDrawn(), Logcat mostra 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 necessario per la visualizzazione iniziale.

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

Puoi utilizzare reportFullyDrawn() per segnalare lo stato di disegno 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 che venga raggiunto lo stato di disegno completo, devi ritardare reportFullyDrawn() per una misurazione più accurata del TTFD. Per scoprire come ritardare reportFullyDrawn(), consulta la sezione seguente.

Migliorare la precisione 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 la popolazione dell'elenco nei tempi del benchmark.

Ad esempio, se l'interfaccia utente contiene un elenco dinamico, ad esempio un elenco RecyclerView o lazy, questo potrebbe essere compilato da un'attività in background che viene completata dopo la prima elaborazione dell'elenco e, di conseguenza, dopo che l'interfaccia utente è contrassegnata come completamente disegnata. In questi casi, la popolazione dell'elenco non è inclusa nel benchmarking.

Per includere la compilazione dell'elenco nel calcolo del tempo del benchmark, ottieni il valore FullyDrawnReporter utilizzando getFullyDrawnReporter() e aggiungi un visualizzatore nel codice dell'app. Rilascia il report dopo che la task in background ha completato il completamento dell'elenco.

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

L'esempio seguente mostra come puoi eseguire più attività in background contemporaneamente, ognuna delle quali 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 di disegno completo:

• ReportDrawn: indica che il composable è subito 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, al termine, indica che il composable è pronto per l'interazione.

Identificare i colli di bottiglia

Per cercare i colli di bottiglia, puoi utilizzare lo strumento di profilazione della CPU di Android Studio. Per ulteriori informazioni, vedi Esaminare l'attività della CPU con CPU Profiler.

Puoi anche ottenere informazioni sui potenziali colli di bottiglia tramite il monitoraggio in linea all'interno dei metodi onCreate() delle tue app e delle tue attività. Per saperne di più sul monitoraggio in linea, consulta la documentazione delle funzioni Trace e la panoramica del monitoraggio di sistema.

Risolvere i problemi più comuni

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

Inizializzazione dell'app complessa

Il rendimento del lancio può risentire quando il codice sostituisce l'oggetto Application e esegue operazioni complesse o logiche complesse durante l'inizializzazione dell'oggetto. L'app potrebbe perdere tempo durante l'avvio se le sottoclassi Application eseguono inizializzazioni che non devono ancora essere eseguite.

Alcune inizializzazioni potrebbero essere del tutto 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'intenzione, l'app utilizza solo un sottoinsieme degli stati inizializzati in precedenza.

Altri problemi durante l'inizializzazione dell'app includono eventi di raccolta dei rifiuti che hanno un impatto significativo o sono numerosi oppure I/O su disco che si verificano contemporaneamente all'inizializzazione, il che blocca ulteriormente il processo di inizializzazione. La raccolta immondizia è particolarmente importante con il runtime Dalvik; il runtime Android (ART) esegue la raccolta immondizia in modo simultaneo, riducendo al minimo l'impatto di questa operazione.

Diagnostica il problema

Puoi utilizzare il monitoraggio dei metodi o il monitoraggio in linea per provare a diagnosticare il problema.

Monitoraggio dei metodi

L'esecuzione del profilo della CPU rivela che il metodo callApplicationOnCreate() chiama infine il metodo com.example.customApplication.onCreate. Se lo strumento indica che questi metodi richiedono molto tempo per essere completati, esaminali ulteriormente per capire cosa sta succedendo.

Monitoraggio in linea

Utilizza il monitoraggio in linea per esaminare i possibili responsabili, tra cui:

• La funzione onCreate() iniziale dell'app.
• Eventuali oggetti singleton globali inizializzati dall'app.
• Eventuali I/O del disco, deserializzazione o loop stretti che potrebbero verificarsi durante il collo di bottiglia.

Soluzioni al problema

Indipendentemente dal fatto che il problema riguardi le inizializzazioni non necessarie o l'I/O del disco, la soluzione è l'inizializzazione lazy. In altre parole, inizializza solo gli oggetti che sono immediatamente necessari. 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, ti consigliamo di utilizzare un framework di Dependency Injection come Hilt che crea oggetti e dipendenze quando vengono iniettati per la prima volta.

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

Inizializzazione con attività intensa

La creazione di attività comporta spesso un lavoro molto oneroso. Spesso esistono opportunità per ottimizzare questo lavoro al fine di ottenere miglioramenti delle prestazioni. I problemi più comuni includono:

• Creazione di layout grandi o complessi.
• Blocco del disegno sullo schermo sul disco o sull'I/O di rete.
• Caricamento e decodifica di bitmap.
• Rastraizzazione degli oggetti VectorDrawable.
• Inizializzazione di altri sottosistemi dell'attività.

Diagnostica il problema

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

Monitoraggio dei metodi

Quando utilizzi lo strumento di profilazione della CPU, presta attenzione ai metodi com.example.customApplication.onCreate() e ai costruttori delle sottoclassi Application della tua app.

Se lo strumento indica che questi metodi richiedono molto tempo per essere completati, esaminali ulteriormente per capire cosa sta succedendo.

Monitoraggio in linea

Utilizza il monitoraggio in linea per esaminare i possibili responsabili, tra cui:

• La funzione onCreate() iniziale dell'app.
• Eventuali oggetti singleton globali inizializzati.
• Eventuali I/O del disco, deserializzazione o loop stretti che potrebbero verificarsi durante il collo di bottiglia.

Soluzioni al problema

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

• Maggiore è la gerarchia delle visualizzazioni, maggiore è il tempo necessario all'app per gonfiarla. Ecco due passaggi che puoi seguire per risolvere il problema:
  • Appiattisci la gerarchia delle viste riducendo i layout ridondanti o nidificati.
  • Non gonfiare le parti dell'interfaccia utente che non devono essere visibili durante il lancio. Utilizza invece un oggetto ViewStub come segnaposto per le gerarchie secondarie che l'app può gonfiare in un momento più appropriato.
• Anche l'inizializzazione di tutte le risorse nel thread principale può rallentare l'avvio. Per risolvere il problema:
  • Sposta tutta l'inizializzazione delle risorse in modo che l'app possa eseguirla in modo lazy su un altro thread.
  • Lascia che l'app carichi e mostri le tue visualizzazioni, quindi aggiorna in un secondo momento le proprietà visuali 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:

• Utilizza l'attributo tema windowDisablePreview per disattivare lo schermo vuoto iniziale visualizzato dal sistema durante l'avvio.
• Utilizzo di un Activity dedicato.

A partire da Android 12, è necessaria la migrazione all'API SplashScreen. Questa API consente un tempo di avvio più rapido e ti consente di modificare la schermata iniziale in modi diversi:

• 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 in modo elegante l'animazione per la chiusura della schermata iniziale.

Inoltre, la libreria compat esegue il backport dell'API SplashScreen per abilitare la compatibilità con le versioni precedenti e creare un'esperienza utente coerente per la visualizzazione della schermata iniziale su tutte le versioni di Android.

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