Cold Start — essentie, koude start en optimalisatie in Android

Wat is Cold Start

Cold Start (koude start) is een scenario waarbij een Android-app wordt gestart vanuit de meest beginstaat: het besturingssysteem creëert een nieuw proces (fork van Zygote), wijst geheugen toe, laadt DEX-code in ART, initialiseert klassen en maakt een instantie van Application aan, en vervolgens de eerste Activity. Voordat de app start, zijn er geen gegevens over in het geheugen van het apparaat, behalve gecachte afbeeldingen van klassen als Background Dexopt wordt gebruikt.

Wanneer vindt Cold Start plaats

Een koude start vindt plaats in drie gevallen: bij de eerste start na installatie van de app, bij start na het herstarten van het apparaat, en bij start nadat het systeem het proces heeft verwijderd wegens gebrek aan geheugen. Op apparaten met 2–4 GB RAM verwijdert het systeem achtergrondprocessen agressief, dus Cold Start kan bij elke terugkeer naar de app na enkele uren inactiviteit plaatsvinden. In Android 12+ kan het systeem een bevroren proces behouden (freeze / cached), maar bij actief geheugenbeheer (OOM-killer) wordt het proces vernietigd.

Waarom Cold Start een kritieke metriek is

Volgens Google (Find My Device report, 2023) sluit 65% van de gebruikers de app als deze niet binnen 3 seconden opent. Voor sociale netwerken en messengers, waar de gebruiker tientallen keren per dag terugkeert, beïnvloedt Cold Start direct de retentie. In Google Play Console maakt de Cold Start-metriek deel uit van Android Vitals en wordt weergegeven als een van de ANR- en prestatiesindicatoren. Een app die de drempel van "slechte" Cold Start overschrijdt (meer dan 5 seconden op 25% van de apparaten) krijgt een waarschuwing in de console en kan lager worden gerangschikt in de zoekresultaten.

Cold Start vs Warm Start vs Hot Start

Android onderscheidt drie typen app-starts, elk met een andere duur, impact op UX en optimalisatiebenaderingen. Inzicht in het verschil is nodig om de juiste profileringstrategie te kiezen.

Warm Start vindt plaats wanneer het app-proces al op de achtergrond bestaat, maar de Activity is vernietigd (bijv. gebruiker keerde terug na een lange pauze en het systeem heeft Activity-geheugen vrijgemaakt). Hot Start — wanneer de gebruiker de app minimaliseert en direct weer opent: de Activity is gepauzeerd en het herstel duurt minimaal. Voor de gebruiker is Cold Start het meest merkbare starttype, en de optimalisatie ervan levert de grootste verbetering in UX.

Overgang tussen typen

Cold Start kan Warm Start worden nadat de app minstens één keer is gestart — ART cachet gecompileerde klassenafbeeldingen (Image in Boot Profile) en het opnieuw laden van DEX gaat sneller. Daarom is de tweede start na de eerste Cold Start meestal 20–40% sneller. Als de app Baseline Profiles gebruikt, worden profielen bij de eerste start geladen en kan de tweede start nog sneller zijn: Google Play, dat Baseline Profiles publiceerde, versnelde Cold Start met 30% op apparaten met Android 12+.

Fasen van koude start

Cold Start bestaat uit strikt gedefinieerde fasen, die elk onafhankelijk kunnen worden gemeten en geoptimaliseerd. Kennis van de fasen helpt bepalen in welke fase de app tijd verliest. Google onderscheidt vier hoofdfasen: procescreatie, Application-initialisatie, Activity-creatie en eerste frame.

Fase 1: Procescreatie (fork)

Het Android-systeem (ActivityManagerService) creëert een nieuw proces door fork van het Zygote-proces. Zygote is een vooraf geladen proces met common Android-klassen. Fork wordt uitgevoerd in 30–80 ms — dit is tijd die de app niet kan controleren. Na fork start ActivityThread — de instantie van de hoofdloop van de app. In deze fase vindt ook klassen laden plaats via ClassLoader, en ART begint de eerste bytecode te interpreteren. Als de app veel statische initializers gebruikt, kan deze fase langer duren.

Fase 2: Application.onCreate

Direct na het starten van ActivityThread wordt Application.onCreate aangeroepen. Hier maakt de ontwikkelaar meestal de fout om alles tegelijk te initialiseren: Crashlytics, Firebase, netwerkclients, databases, Dagger-componenten, DI-containers. Elke dergelijke initialisatie is tijd die op de hoofdthread wordt geblokkeerd. Als Application.onCreate 500 ms duurt, ziet de gebruiker gedurende die halve seconde een wit (of zwart) scherm. De optimale duur van deze fase is minder dan 200 ms op een gemiddeld apparaat.

Fase 3: Activity.onCreate

Na initialisatie van Application wordt een instantie van Activity (MainActivity of Launcher Activity) aangemaakt. Activity.onCreate wordt aangeroepen, waarbij setContentView, initialisatie van fragmenten, ViewModel-configuratie, abonneren op LiveData/Flow plaatsvinden. Als onCreate gegevens (SharedPreferences, SQLite, API) synchroon op de hoofdthread laadt, wordt de fase verlengd. Het doel is om onCreate binnen 200–400 ms op een gemiddeld apparaat te houden.

Fase 4: Eerste frame (TTFD)

Na voltooiing van onCreate begint de eerste weergave: measure, layout, draw. Dit moment wordt TTFD (Time To First Draw) genoemd. Als de app een splash-scherm gebruikt (via SplashScreen API op Android 12+ of via thema), kan de weergave sneller plaatsvinden, maar de gebruiker wacht nog steeds tot de splash verdwijnt. Ideale TTFD voor Cold Start is minder dan 1,5 seconde.

Hoe Cold Start meten

Het meten van Cold Start vereist speciale tools, omdat gewone logging (Log.d) pas na het aanmaken van Application begint te werken en de timing van fork en klassen laden buiten bereik blijft. Google beveelt drie methoden aan: ADB-commando's, Android Vitals en aangepaste perf-macro's.

Meten via ADB

De eenvoudigste en reproduceerbare manier is het commando adb shell am start -S -W. De vlag -S stopt de app geforceerd voor de start (garandeert Cold Start). Het commando geeft drie metrieken: ThisTime (starttijd van Activity), TotalTime (totale tijd inclusief processtart) en WaitTime (tijd inclusief alle vertragingen van Activity Manager). Doe voor zuivere meting 5–7 metingen en neem de mediaan — enkele metingen zijn onderhevig aan ruis (CPU throttling, achtergrondbelasting).

# Geforceerde Cold Start met meting
$ adb shell am start -S -W \
    com.example.app/.MainActivity

# Opdrachtuitvoer:
# ThisTime: 1842 ms
# TotalTime: 1842 ms
# WaitTime: 1855 ms

Android Vitals (Google Play Console)

Google Play Console verzamelt anonieme metrieken van alle apparaten waar de app is geïnstalleerd. In de sectie Android Vitals → Launch time wordt de mediaanverdeling van Cold Start per apparaatmodel en Android-versie weergegeven. Dit is de enige manier om echte cijfers op gebruikersapparaten te zien, niet op testapparaten. Als op Redmi 9A (2 GB RAM) Cold Start meer dan 5 seconden bedraagt en op Pixel 8 1,2 seconde, ligt het probleem in de geheugencapaciteit en het aantal klassen. Google toont ook de door de gebruiker waargenomen vertraging (user-perceptible delay) op basis van het 25e percentiel.

Macrobenchmark

Google Jetpack Macrobenchmark (bibliotheek androidx.benchmark) maakt het mogelijk geïnstrumenteerde tests voor het starten van de app te schrijven. De test installeert de app, start deze in koude toestand en meet de tijd tot het eerste frame. Macrobenchmark voert automatisch 20 runs uit, verwijdert uitschieters en toont stabiele percentielen. Voor CI/CD kan de baseline worden vergeleken met de huidige start — als de tijd is toegenomen, kan de CI-pipeline falen.

Hoe Cold Start optimaliseren

Optimalisatie van Cold Start is een systemische inspanning die meerdere niveaus van de app raakt: code, bronnen, buildconfiguratie en initialisatiearchitectuur. Google adviseert te beginnen met de duurste — Application.onCreate — en naar kleinere zaken toe te werken.

Lazy initialisatie (Lazy Init)

Verplaats alle initialisatie die niet bij de start nodig is van Application.onCreate naar het eerste gebruikspunt. Firebase, Crashlytics, analytics SDK, pushmeldingen, DI-componenten — alles kan worden geïnitialiseerd na de weergave van het eerste scherm. Gebruik Lazy (by lazy) in Kotlin of ContentProvider-initialisatie met expliciete aanroep van initialize(context). Volgens Google (Android Performance, 2023) verkort lazy initialisatie Cold Start met 40–60% voor apps die 5+ SDK's gebruiken.

Baseline Profiles

Baseline Profiles zijn AOT-compilatie van kritieke klassen en methoden die bij het starten van de app worden gebruikt. Zonder Baseline Profiles interpreteert ART DEX-code of compileert deze met JIT, wat tijd kost. Met profielen compileert ART de opgegeven methoden bij het installeren van de app naar native code (AOT). Google stelt dat Baseline Profiles Cold Start versnellen met 15–40% op Android 9+ en tot 60% met ART-optimalisaties van Android 12+. Gebruik voor het maken van profielen de plugin androidx.benchmark:benchmark-baseline-profile-gradle-plugin.

App Startup Library

De bibliotheek androidx.startup maakt het mogelijk de initialisatie van componenten te ordenen en in één ContentProvider uit te voeren. In plaats van meerdere ContentProviders van verschillende bibliotheken (die elk 1–2 ms aan koude start toevoegen) combineert App Startup ze in een afhankelijkheidsgrafiek en initialiseert alleen wanneer nodig. Bij de start worden alleen componenten uitgevoerd die zijn gemarkeerd met @Initializer en nodig zijn voor het eerste scherm. Voor de overige wordt de vlag needEarlyInit = false ingesteld — ze worden gestart na de eerste weergave.

// App Startup Initializer — initialisatie na start
class AnalyticsInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Analytics.init(context)
    }
    override fun dependencies() = listOf<Class<out Initializer<*>>>()
}

// In AndroidManifest.xml als optioneel markeren
// <meta-data android:name="AnalyticsInitializer"
//     android:value="false" />

Verkleinen van DEX-grootte

De grootte van het DEX-bestand beïnvloedt direct de laadtijd door ART. Gebruik R8/ProGuard voor obfuscatie en verwijdering van dode code (MinifyEnabled = true). Schakel android:extractNativeLibs="false" in het manifest in, zodat APK geen .so-bestanden uitpakt bij installatie. Voor projecten met meer dan 10 klassen met Reference Tracking, voeg startup-priority alleen toe voor het eerste scherm. Elke overbodige methode in DEX voegt 0,5–2 ms toe aan het laden, en voor apps met 50k+ methoden (multidex met primary dex) — tot 300 ms.

Cold Start in Android Vitals

Android Vitals in Google Play Console (sectie Launch time) verzamelt gegevens van alle apparaten waar de app is geïnstalleerd, op voorwaarde dat de gebruiker heeft ingestemd met anonieme diagnostiek. Metrieken worden verdeeld in drie categorieën: "good" (goed), "moderate" (gemiddeld), "bad" (slecht), afhankelijk van de Cold Start-tijd.

Drempelwaarden van Google

Google definieert "bad" Cold Start als tijd langer dan 5 seconden op elk apparaat. In de praktijk wordt voor vlaggenschipapparaten (Snapdragon 8 Gen) een goede tijd van minder dan 1,5 seconde beschouwd, voor het middensegment — minder dan 2,5 seconde, voor budget — minder dan 4 seconden. Android Vitals toont de mediaan per device model, wat helpt te begrijpen op welke apparaten de app traag start. Als Cold Start slecht is op Samsung A-series of Xiaomi Redmi-apparaten, is de oorzaak meestal zwak flash-geheugen en weinig RAM (versnelling via Baseline Profiles geeft het grootste effect juist op dergelijke apparaten).

Hoe Google Play de metriek gebruikt

Naast weergave in de console beïnvloedt de Cold Start-metriek de kwaliteitsbeoordeling van de app in Google Play Search. Apps met een hoog percentage "slechte" starts krijgen een "Performance warning"-label op de installatiepagina, wat de conversie verlaagt. Volgens Google (Android Performance Playbook, 2024) verhogen apps die Cold Start-problemen oplossen de installatieconversie gemiddeld met 5% en verbeteren de retentie (D1) met 3–7%.

Integratie met Firebase Performance

Gebruik voor gedetailleerdere monitoring Firebase Performance Monitoring. Het volgt Cold Start op sessieniveau, splitst op app-versie en Android-versie. In tegenstelling tot Android Vitals toont Firebase een trace-diagram van de bestede tijd per fase. Zo kun je zien dat in versie 3.2.0 Application.onCreate 800 ms duurde (vanwege een nieuwe pushmeldingsbibliotheek), en in versie 3.2.1 — 200 ms (na correctie).

Codevoorbeelden voor optimalisatie

Hieronder staan twee praktische voorbeelden die Cold Start direct versnellen: het verplaatsen van SDK-initialisatie na de start en het gebruik van SplashScreen API.

Initialisatie verplaatsen van Application.onCreate

Een typische fout is het initialiseren van alle SDK's in Application.onCreate. Hieronder wordt getoond hoe niet-kritieke initialisatie naar een coroutine kan worden verplaatst die na de weergave van het eerste frame wordt gestart. Belangrijk: Firebase, Crashlytics en Crash Reporting SDK moeten bij de start worden geïnitialiseerd — ze kunnen niet worden uitgesteld omdat ze crashes bij initialisatie van andere componenten opvangen. Gebruik voor de overige lifecycleScope bij de eerste Activity.

// ❌ Slecht — alle initialisatie in Application.onCreate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // kritiek
        Analytics.init(this) // kan later
        Database.init(this) // kan later
        ImageLoader.init(this) // kan later
    }
}

// ✅ Goed — Firebase bij start, rest after inflate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// In MainActivity na eerste frame:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Gebruik op Android 12+ de officiële SplashScreen API, die direct bij het starten van het proces een system-splash (app-pictogram op donkere/lichte achtergrond) toont. Dit verbergt de initialisatietijd voor de gebruiker — hij ziet een splash in plaats van een wit scherm. Gebruik voor oudere apparaten theme-based splash (Theme.SplashScreen in stijlen). Belangrijk: de splash mag niet langer dan 300 ms duren — als de app binnen die tijd niet klaar is, teken dan een "permanent" skelet (shimmer) en toon de laadvoortgang.

// SplashScreen API — Android 12+
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val splashScreen = installSplashScreen()
        splashScreen.setKeepOnScreenCondition {
            isReady.value == false
        }
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

// Theme-based splash (Android 5-11)
// In themes.xml:
// <style name="Theme.App.Starting" parent="Theme.SplashScreen">
//   <item name="windowSplashScreenBackground">@color/white</item>
//   <item name="windowSplashScreenAnimatedIcon">@mipmap/ic_launcher</item>
// </style>