Hot Start in mobiele apps: wat is het, factoren en hoe versnel je het

Wat is Hot Start in mobiele apps

Hot Start — is een opstartscenario waarbij het proces van de app al in het RAM-geheugen van het apparaat bestaat. De gebruiker minimaliseert de app, keert dan terug — en het systeem creëert geen nieuw proces, maar hervat een bestaand proces. In dit scenario is het laden van het besturingssysteem, initialisatie van de Application-klasse en het aanmaken van een proces niet nodig, wat de tijd tot het verschijnen van de UI op het scherm drastisch verkort. Volgens Android Documentation (2025) duurt Hot Start slechts 200–500 ms, terwijl Cold Start 5 seconden of meer kan duren. Het snelheidsverschil is vooral merkbaar op apparaten met beperkt geheugen, waar het systeem vaker achtergrondapps uit het geheugen verwijdert.

Het belangrijkste kenmerk van Hot Start — een minimale set aangeroepen lifecycle-methoden. In Android zijn dit Activity.onCreate en Activity.onStart, in iOS — applicationDidBecomeActive. In tegenstelling tot Cold Start, waar achtereenvolgens Application.onCreate, ContentProvider.onCreate, Activity.onCreate en talrijke bibliotheekinitialisaties worden aangeroepen, slaat Hot Start al deze fasen over. De ontwikkelaar moet begrijpen welke code precies bij een warme start wordt uitgevoerd — vaak worden zware initialisaties van SDK's, analytics en DI-containers zowel bij Cold als bij Hot Start herhaald, hoewel ze bij een warme start niet meer nodig zijn.

Cold Start, Warm Start en Hot Start: vergelijking

De drie opstartscenario's verschillen in de diepte van initialisatie. Cold Start (koude start) vindt plaats wanneer de app voor het eerst wordt gestart na installatie, herstart van het apparaat of verwijdering uit het geheugen. Het systeem creëert een nieuw Linux-proces, laadt Application-klassen, maakt ContentProvider-instanties aan, voert bibliotheekinitialisatie uit en pas daarna wordt Activity weergegeven. Het hele proces duurt 2–10 seconden, afhankelijk van de complexiteit van de app en de kenmerken van het apparaat.

Warm Start (lauwe start) — een tussenliggend scenario. Het proces van de app leeft in het geheugen, maar Activity is vernietigd en moet opnieuw worden aangemaakt. Dit gebeurt bijvoorbeeld bij het draaien van het scherm of bij terugkeer uit een andere app, wanneer Activity uit het geheugen is verwijderd vanwege geheugengebrek, maar het proces is gebleven. Warm Start omvat het aanroepen van Activity.onCreate en Activity.onStart, maar niet Application.onCreate en initialisatie van ContentProvider. De tijd van Warm Start — van 500 ms tot 2 seconden. Hot Start — de snelste van de drie: Activity bestaat al in de back stack, het proces leeft en het systeem roept eenvoudigweg Activity.onRestart, onStart en onResume aan. De tijd van Hot Start — 200–500 ms. Het verschil met Warm Start is dat Activity niet opnieuw wordt aangemaakt — het wordt hersteld vanuit een bestaande instantie.

Android Lifecycle bij Hot Start

In Android wordt Hot Start geïnitieerd wanneer de gebruiker terugkeert naar de app via het Recents-scherm of door op het pictogram te klikken in geminimaliseerde toestand. Het systeem controleert of het proces leeft, en zo ja — roept het achtereenvolgens Activity.onRestart, onStart en onResume aan. De methode onCreate wordt bij Hot Start niet aangeroepen, omdat de Activity-instantie al in het geheugen bestaat. Dit is een belangrijk verschil met Warm Start, waar onCreate wel wordt aangeroepen vanwege de vernietiging van Activity. Volgens Google I/O 2019 is de typische Hot Start-tijd in Android 200–400 ms, en elke vertraging in deze fase verhoogt direct de perceived launch time.

Ontwikkelaars merken vaak niet dat de code voor UI-initialisatie, abonnement op LiveData of configuratie van RecyclerView niet alleen in onCreate wordt uitgevoerd, maar ook in onStart of onResume. Bij Hot Start worden deze codeblokken opnieuw uitgevoerd, hoewel de UI al is geconfigureerd. Het wordt aanbevolen om eenmalige initialisatie (in onCreate met controle van savedInstanceState) en hervatbare logica (onStart/onResume) te scheiden. Zware operaties — configuratie van adapters, laden van lijsten — kunnen beter worden verplaatst naar een blok dat niet wordt uitgevoerd bij onRestart, of savedInstanceState controleren.

Voorbeeld van het volgen van het starttype

De volgende code in Kotlin demonstreert een eenvoudige manier om het startscenario te bepalen en de tijd te meten. De variabele launchTimeStamp legt het moment van starten vast, en isColdStart maakt het mogelijk de logica voor koude en warme start te scheiden.

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()
            // eenmalige initialisatie
        } else {
            isColdStart = false
            // Hot Start — Activity wordt hersteld
        }
    }

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

iOS Lifecycle bij warm opstarten

In iOS komt Hot Start overeen met het terugkeren van de app vanuit de achtergrond via sceneDidBecomeActive (UIKit) of onAppear (SwiftUI). Het besturingssysteem hercreëert het proces niet als de app in de status Suspended of Background was. Bij een warme start wordt applicationDidBecomeActive in AppDelegate aangeroepen, maar applicationDidFinishLaunching wordt niet aangeroepen — dit is analoog aan Android, waar Application.onCreate wordt overgeslagen. iOS verwijdert apps agressiever uit het geheugen: als het apparaat onvoldoende RAM heeft, kan het systeem de achtergrondapp verwijderen, en dan zal de volgende start Cold Start zijn. Volgens Apple Developer Documentation is de gemiddelde Hot Start-tijd in iOS 300–600 ms.

Het belangrijkste verschil van iOS — het ontbreken van een directe analogie van Warm Start in de Android-betekenis. In iOS wordt bij het minimaliseren van de app sceneDidEnterBackground aangeroepen, en bij terugkeer — sceneWillEnterForeground en sceneDidBecomeActive. Als het systeem de scene verwijdert maar het proces levend houdt, zal de volgende start Cold zijn vanuit het oogpunt van de scene, maar Hot vanuit het oogpunt van het proces. De ontwikkelaar moet hiermee rekening houden bij het plaatsen van initialisatiecode: abonnement op NotificationCenter, UI-update en resetten van statussen moeten precies in sceneDidBecomeActive zijn, niet alleen in viewDidLoad.

Voorbeeld van Hot Start-verwerking in iOS

Deze code in Swift laat zien hoe je het aantal warme starts kunt volgen en de logica kunt scheiden. De teller foregroundCount neemt bij elke terugkeer uit de achtergrond toe.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — volledige initialisatie
            setupSDKs()
        } else {
            // Hot Start — alleen UI-update
            refreshUI()
        }
    }

    private func refreshUI() {
        // gegevensupdate op scherm
    }
}

Factoren die de snelheid van Hot Start beïnvloeden

De snelheid van Hot Start wordt beïnvloed door verschillende categorieën factoren. De eerste — de hoeveelheid werk in de lifecycle-methoden onStart en onResume. Als de ontwikkelaar in deze methoden het laden van gegevens uit het netwerk, JSON-parsing, initialisatie van adapters of zware berekeningen heeft geplaatst, voegt elk dergelijk blok tientallen en honderden milliseconden toe aan de opstarttijd. Volgens gegevens van het instrument Android Vitals verliezen apps met een Hot Start-duur van meer dan 800 ms tot 20% van de gebruikers bij herhaalde terugkeer.

De tweede categorie — fragmenten en Views die worden hersteld uit savedInstanceState. Als fragmenten zware ViewPager2, WebView of complexe hiërarchieën met diepe nesting bevatten, kost hun herstel CPU-bronnen. Volgens Google I/O 2023 voegt elke geneste ViewGroup gemiddeld 2–5 ms toe aan de renderingstijd bij Hot Start. De derde categorie — SDK's van derden: analytics-bibliotheken, crash-reporting, A/B-testen en DEX-loaders kunnen initialisatie uitvoeren bij elke terugkeer uit de achtergrond. Het wordt aanbevolen te controleren welke SDK's precies code in onStart/onResume uitvoeren, en niet-kritieke taken naar een achtergrondthread uit te stellen.

Optimalisatiemethoden voor warm opstarten

Optimalisatie van Hot Start komt neer op het minimaliseren van werk in de lifecycle-methoden voor hervatting. De eerste methode — luie initialisatie: alle code die niet nodig is voor het eerste UI-frame moet worden uitgevoerd na het aanroepen van onResume met vertraging via Handler.postDelayed of Coroutine.launch(Dispatchers.IO). De tweede methode — caching van de View-status: bij het minimaliseren van de app bewaar gegevens in een in-memory cache, zodat je ze bij Hot Start niet opnieuw uit de database of het netwerk hoeft te laden. De derde methode — gebruik van SavedStateHandle in Android en StateRestorationPolicy in iOS om de hoeveelheid herstelde gegevens te minimaliseren.

Lazy loading na Hot Start

In dit voorbeeld stelt Handler.postDelayed de initialisatie van analytics uit met 500 ms na het renderen van het eerste frame. Dit heeft geen invloed op de perceived launch time, omdat de gebruiker de interface al ziet.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // initialisatie na eerste frame
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Gebruik van de App Startup-bibliotheek

AndroidX App Startup maakt het mogelijk de volgorde van componentinitialisatie bij het opstarten te beheren. Alle ContentProvider worden automatisch geïnitialiseerd bij Cold Start, maar je kunt automatische initialisatie uitschakelen voor componenten die niet nodig zijn bij 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<*>>()
}

Tools voor het monitoren van opstarttijd

Voor het meten van de Hot Start-tijd bestaan zowel ingebouwde platformtools als oplossingen van derden. In Android is het belangrijkste instrument Android Vitals in de Google Play Console — het verzamelt automatisch metrics van de opstarttijd voor alle scenario's (Cold, Warm, Hot) met uitsplitsing naar apparaatmodellen en OS-versies. Daarnaast kan Macrobenchmark van AndroidX worden gebruikt — een bibliotheek voor geautomatiseerd testen van startprestaties. In iOS is het equivalent MetricKit, dat gegevens verzamelt over opstarttijd, framesnelheid en geheugengebruik.

Voor gedetailleerde profilering van warm opstarten zijn Firebase Performance Monitoring (volgt custom traces) en New Relic met dashboards voor opstarttijd geschikt. Aan de kant van de ontwikkelaar wordt voor handmatige meting reportFullyDrawn in Android gebruikt — een API die het systeem het exacte moment meldt waarop de UI is gerenderd en klaar is voor interactie. In iOS is het equivalent endActivity in MetricKit. Door deze tools te combineren, kun je identificeren welke SDK of welk codeblok Hot Start precies op specifieke apparaten vertraagt.

Voorbeeld van Macrobenchmark voor Hot Start

Code in Kotlin met behulp van de Macrobenchmark-bibliotheek voor het meten van Cold en Hot Start. De test start Activity en meet de tijd tot de complete-status.

@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()
        }
    }
}