Hot Start nelle app mobili: cos'è, fattori e come accelerarlo

Cos'è l'Hot Start nelle app mobili

Hot Start è uno scenario di avvio in cui il processo dell'app esiste già nella RAM del dispositivo. L'utente minimizza l'app, poi torna — e il sistema non crea un nuovo processo ma riprende quello esistente. In questo scenario, non è necessario il caricamento del SO, l'inizializzazione della classe Application o la creazione del processo, il che riduce drasticamente il tempo fino alla comparsa dell'UI sullo schermo. Secondo la documentazione Android (2025), Hot Start richiede solo 200–500 ms, mentre Cold Start può raggiungere 5 secondi o più. La differenza di velocità è particolarmente evidente sui dispositivi con memoria limitata, dove il sistema scarica più frequentemente le app in background.

La caratteristica principale di Hot Start è il set minimo di metodi del ciclo di vita chiamati. In Android, sono Activity.onCreate e Activity.onStart; in iOS, è applicationDidBecomeActive. A differenza di Cold Start, dove Application.onCreate, ContentProvider.onCreate, Activity.onCreate e molte inizializzazioni di librerie vengono chiamate in sequenza, Hot Start salta tutte queste fasi. Lo sviluppatore deve capire quale codice viene eseguito specificamente durante un avvio a caldo — spesso inizializzazioni pesanti di SDK, analytics e contenitori DI vengono ripetute sia in Cold che in Hot Start, anche se non sono più necessarie durante un avvio a caldo.

Cold Start, Warm Start e Hot Start: confronto

I tre scenari di avvio dell'app differiscono per profondità di inizializzazione. Cold Start si verifica quando l'app viene avviata per la prima volta dopo l'installazione, il riavvio del dispositivo o la rimozione dalla memoria. Il sistema crea un nuovo processo Linux, carica le classi Application, crea istanze ContentProvider, esegue l'inizializzazione delle librerie e solo successivamente renderizza l'Activity. L'intero processo richiede 2–10 secondi a seconda della complessità dell'app e delle caratteristiche del dispositivo.

Warm Start è uno scenario intermedio. Il processo dell'app è vivo in memoria, ma l'Activity è stata distrutta e deve essere ricreata. Ciò accade, ad esempio, durante la rotazione dello schermo o quando si torna da un'altra app in cui l'Activity è stata rimossa per mancanza di memoria ma il processo è rimasto. Warm Start include la chiamata di Activity.onCreate e Activity.onStart, ma non include Application.onCreate o l'inizializzazione di ContentProvider. Il tempo di Warm Start è di 500 ms a 2 secondi. Hot Start è il più veloce dei tre: l'Activity esiste già nello stack di ritorno, il processo è vivo e il sistema chiama semplicemente Activity.onRestart, onStart e onResume. Il tempo di Hot Start è di 200–500 ms. La differenza da Warm Start è che l'Activity non viene creata di nuovo — viene ripristinata dall'istanza esistente.

Ciclo di vita Android durante Hot Start

In Android, Hot Start viene attivato quando l'utente torna all'app tramite la schermata Recenti o toccando l'icona dell'app in stato minimizzato. Il sistema verifica se il processo è vivo e, in tal caso, chiama sequenzialmente Activity.onRestart, onStart e onResume. Il metodo onCreate non viene chiamato durante Hot Start perché l'istanza dell'Activity esiste già in memoria. Questa è una differenza importante rispetto a Warm Start, dove onCreate viene ancora chiamato a causa della distruzione dell'Activity. Secondo Google I/O 2019, il tempo tipico di Hot Start in Android è di 200–400 ms, e qualsiasi rallentamento in questa fase aumenta direttamente il tempo di avvio percepito.

Gli sviluppatori spesso trascurano che il codice di inizializzazione dell'UI, le sottoscrizioni a LiveData o la configurazione di RecyclerView vengono eseguiti non solo in onCreate ma anche in onStart o onResume. Durante Hot Start, questi blocchi di codice vengono eseguiti di nuovo, anche se l'UI era già configurata. Si raccomanda di separare l'inizializzazione una tantum (in onCreate con controllo di savedInstanceState) e la logica riprendibile (onStart/onResume). Ad esempio, le operazioni pesanti — configurazione degli adapter, caricamento delle liste — dovrebbero essere spostate in un blocco che non viene eseguito durante onRestart, o controllare savedInstanceState.

Esempio di tracciamento del tipo di avvio

Il seguente codice Kotlin mostra un modo semplice per rilevare lo scenario di avvio e misurare il tempo. La variabile launchTimeStamp cattura il momento dell'inizio dell'avvio e isColdStart consente di separare la logica per l'avvio a freddo e a caldo.

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // inizializzazione una tantum
        } else {
            isColdStart = false
            // Hot Start — Activity viene ripristinata
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start: $launchTime ms")
        }
    }
}

Ciclo di vita iOS durante l'avvio a caldo

In iOS, Hot Start corrisponde al ritorno dell'app dallo sfondo tramite sceneDidBecomeActive (UIKit) o onAppear (SwiftUI). Il sistema operativo non ricrea il processo se l'app era in stato Sospeso o in Background. Durante un avvio a caldo, applicationDidBecomeActive viene chiamato in AppDelegate, ma applicationDidFinishLaunching non viene chiamato — questo è analogo ad Android dove Application.onCreate viene saltato. iOS scarica le app dalla memoria in modo più aggressivo: se il dispositivo non ha RAM sufficiente, il sistema può scaricare un'app in background e il prossimo avvio sarà un Cold Start. Secondo la documentazione Apple Developer, il tempo medio di Hot Start in iOS è di 300–600 ms.

Una differenza chiave in iOS è l'assenza di un analogo diretto di Warm Start nel senso Android. In iOS, quando un'app viene minimizzata, viene chiamato sceneDidEnterBackground e al ritorno vengono chiamati sceneWillEnterForeground e sceneDidBecomeActive. Se il sistema scarica la scena ma mantiene vivo il processo, il prossimo avvio sarà Cold dal punto di vista della scena ma Hot dal punto di vista del processo. Lo sviluppatore deve considerare questo nel posizionare il codice di inizializzazione: le sottoscrizioni a NotificationCenter, gli aggiornamenti dell'UI e i ripristini di stato dovrebbero essere in sceneDidBecomeActive, non solo in viewDidLoad.

Esempio di gestione di Hot Start in iOS

Questo codice Swift mostra come tracciare il numero di avvii a caldo e separare la logica. Il contatore foregroundCount si incrementa ad ogni ritorno dallo sfondo.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — inizializzazione completa
            setupSDKs()
        } else {
            // Hot Start — solo aggiornamento UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // aggiornamento dei dati sullo schermo
    }
}

Fattori che influenzano la velocità di Hot Start

Diverse categorie di fattori influenzano la velocità di Hot Start. La prima è la quantità di lavoro nei metodi del ciclo di vita onStart e onResume. Se lo sviluppatore ha inserito il caricamento di dati di rete, l'analisi JSON, l'inizializzazione degli adapter o calcoli pesanti in questi metodi, ogni blocco aggiunge decine o centinaia di millisecondi al tempo di avvio. Secondo Android Vitals, le app con una durata di Hot Start superiore a 800 ms perdono fino al 20% degli utenti al ritorno.

La seconda categoria sono i frammenti e le viste ripristinate da savedInstanceState. Se i frammenti contengono ViewPager2 pesante, WebView o gerarchie complesse profondamente annidate, il loro ripristino consuma risorse della CPU. Secondo Google I/O 2023, ogni ViewGroup annidato aggiunge in media 2–5 ms al tempo di rendering durante Hot Start. La terza categoria sono gli SDK di terze parti: librerie di analisi, strumenti di crash-reporting, framework di test A/B e loader DEX possono eseguire inizializzazioni ad ogni ritorno dallo sfondo. Si raccomanda di verificare quali SDK eseguono codice specificamente in onStart/onResume e di posticipare le attività non critiche su un thread in background.

Metodi di ottimizzazione dell'avvio a caldo

L'ottimizzazione di Hot Start si riduce a minimizzare il lavoro nei metodi del ciclo di vita di ripresa. Il primo metodo è l'inizializzazione pigra: qualsiasi codice non necessario per il primo frame dell'UI dovrebbe essere eseguito dopo onResume con un ritardo tramite Handler.postDelayed o Coroutine.launch(Dispatchers.IO). Il secondo metodo è la memorizzazione nella cache dello stato della vista: quando l'app viene minimizzata, salvare i dati in una cache in memoria in modo che durante Hot Start non sia necessario ricaricarli dal database o dalla rete. Il terzo metodo è utilizzare SavedStateHandle in Android e StateRestorationPolicy in iOS per minimizzare la quantità di dati ripristinati.

Caricamento pigro dopo Hot Start

In questo esempio, Handler.postDelayed posticipa l'inizializzazione dell'analisi di 500 ms dopo il rendering del primo frame. Ciò non influisce sul tempo di avvio percepito perché l'utente vede già l'interfaccia.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // inizializzazione dopo il primo frame
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Utilizzo della libreria App Startup

AndroidX App Startup consente di controllare l'ordine di inizializzazione dei componenti all'avvio. Tutti i ContentProvider vengono inizializzati automaticamente durante Cold Start, ma è possibile disabilitare l'inizializzazione automatica per i componenti non necessari durante Hot Start.

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

Strumenti di monitoraggio del tempo di avvio

Per misurare il tempo di Hot Start, esistono sia strumenti integrati nelle piattaforme che soluzioni di terze parti. In Android, lo strumento chiave è Android Vitals nella Google Play Console — raccoglie automaticamente le metriche del tempo di avvio per tutti gli scenari (Cold, Warm, Hot) suddivise per modello di dispositivo e versione del SO. Inoltre, è possibile utilizzare Macrobenchmark da AndroidX — una libreria per test automatizzati delle prestazioni di avvio. In iOS, l'equivalente è MetricKit, che raccoglie dati sul tempo di avvio, frequenza dei fotogrammi e utilizzo della memoria.

Per la profilazione dettagliata dell'avvio a caldo, sono adatti Firebase Performance Monitoring (traccia trace personalizzate) e New Relic con dashboard del tempo di avvio. Sul lato sviluppatore per la misurazione manuale, viene utilizzato reportFullyDrawn in Android — un'API che comunica al sistema il momento esatto in cui l'UI è renderizzata e pronta per l'interazione. In iOS, l'equivalente è endActivity in MetricKit. Combinando questi strumenti, è possibile identificare quale SDK o blocco di codice rallenta Hot Start su dispositivi specifici.

Esempio di Macrobenchmark per Hot Start

Codice Kotlin che utilizza la libreria Macrobenchmark per misurare Cold e Hot Start. Il test avvia l'Activity e misura il tempo fino allo stato completo.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}