Cold Start — Kaltstart und Optimierung in Android

Was ist Cold Start

Cold Start (Kaltstart) ist ein Szenario, bei dem eine Android-Anwendung vom allerersten Zustand gestartet wird: Das Betriebssystem erstellt einen neuen Prozess (Fork von Zygote), weist Speicher zu, lädt DEX-Code in ART, initialisiert die Klassen und erstellt eine Application-Instanz, dann die erste Activity. Vor dem App-Start befinden sich keine Daten darüber im Gerätespeicher, außer zwischengespeicherten Klassenbildern, wenn Background Dexopt verwendet wird.

Wann Cold Start auftritt

Der Kaltstart tritt in drei Fällen auf: beim ersten Start nach der App-Installation, beim Start nach einem Geräteneustart und beim Start, nachdem das System den Prozess aufgrund von Speichermangel entfernt hat. Auf Geräten mit 2–4 GB RAM entfernt das System Hintergrundprozesse recht aggressiv, daher kann Cold Start jedes Mal auftreten, wenn der Benutzer nach mehreren Stunden Inaktivität zur App zurückkehrt. Unter Android 12+ kann das System einen eingefrorenen Prozess (Freeze / Cached) beibehalten, aber bei aktiver Speichersparung (OOM-Killer) wird der Prozess beendet.

Warum Cold Start eine kritische Metrik ist

Laut Google (Find My Device-Bericht, 2023) schließen 65% der Benutzer eine App, wenn sie sich nicht innerhalb von 3 Sekunden öffnet. Für soziale Netzwerke und Messenger, bei denen Benutzer dutzende Male am Tag zurückkehren, wirkt sich Cold Start direkt auf die Bindung aus. In der Google Play Console ist die Cold-Start-Metrik Teil des Android Vitals-Abschnitts und wird als einer der ANR- und Leistungsindikatoren angezeigt. Eine App, die den „schlechten“ Cold-Start-Schwellenwert (mehr als 5 Sekunden auf 25% der Geräte) überschreitet, erhält eine Warnung in der Konsole und kann in den Suchergebnissen herabgestuft werden.

Cold Start vs Warm Start vs Hot Start

Android unterscheidet drei Arten von App-Starts, jede mit unterschiedlicher Dauer, UX-Auswirkung und Optimierungsansätzen. Das Verständnis des Unterschieds ist für die Wahl der richtigen Profiling-Strategie unerlässlich.

Warm Start tritt auf, wenn der App-Prozess bereits im Hintergrund existiert, aber die Activity zerstört wurde (z. B. wenn der Benutzer nach einer langen Pause zurückgekehrt ist und das System den Activity-Speicher freigegeben hat). Hot Start — wenn der Benutzer die App minimiert und sofort wieder öffnet: Die Activity ist pausiert und die Wiederherstellung dauert minimal. Für den Benutzer ist Cold Start die auffälligste Startart, und seine Optimierung bringt die größte Verbesserung der UX.

Übergang zwischen den Typen

Cold Start kann zu Warm Start werden, nachdem die App mindestens einmal gestartet wurde — ART speichert kompilierte Klassenbilder (Image im Boot Profile) zwischen und das nachfolgende Laden von DEX ist schneller. Daher ist der zweite Start nach dem ersten Cold Start in der Regel 20–40% schneller. Wenn die App Baseline Profiles verwendet, werden die Profile beim ersten Start geladen und der zweite Start kann noch schneller sein: Google Play, das Baseline Profiles veröffentlicht hat, hat Cold Start auf Geräten mit Android 12+ um 30% beschleunigt.

Phasen des Kaltstarts

Cold Start besteht aus streng definierten Phasen, die jeweils unabhängig gemessen und optimiert werden können. Die Kenntnis der Phasen hilft zu bestimmen, in welcher Phase die App Zeit verliert. Google identifiziert vier Hauptphasen: Prozesserstellung, Application-Initialisierung, Activity-Erstellung und der erste Frame.

Phase 1: Prozesserstellung (Fork)

Das Android-System (ActivityManagerService) erstellt einen neuen Prozess durch Fork vom Zygote-Prozess. Zygote ist ein vorgeladener Prozess mit gemeinsamen Android-Klassen. Der Fork dauert 30–80 ms — diese Zeit liegt außerhalb der Kontrolle der App. Nach dem Fork wird ActivityThread gestartet — die Main-Loop-Instanz der Anwendung. In dieser Phase findet auch das Klassenladen über ClassLoader statt, und ART beginnt mit der Interpretation des ersten Bytecode. Wenn die App viele statische Initialisierer verwendet, kann sich diese Phase verlängern.

Phase 2: Application.onCreate

Unmittelbar nach dem Start von ActivityThread wird Application.onCreate aufgerufen. Hier machen Entwickler am häufigsten den Fehler, alles auf einmal zu initialisieren: Crashlytics, Firebase, Netzwerkclients, Datenbanken, Dagger-Komponenten, DI-Container. Jede dieser Initialisierungen blockiert den Hauptthread. Wenn Application.onCreate 500 ms dauert, sieht der Benutzer eine halbe Sekunde lang einen weißen (oder schwarzen) Bildschirm. Die optimale Dauer dieser Phase beträgt weniger als 200 ms auf einem Mittelklassegerät.

Phase 3: Activity.onCreate

Nach der Application-Initialisierung wird eine Activity-Instanz erstellt (MainActivity oder Launcher Activity). Activity.onCreate wird aufgerufen, wo setContentView, Fragment-Initialisierung, ViewModel-Einrichtung und LiveData/Flow-Abonnement stattfinden. Wenn onCreate Daten (SharedPreferences, SQLite, API) synchron auf dem Hauptthread lädt, verlängert sich die Phase. Ziel ist es, onCreate auf einem Mittelklassegerät innerhalb von 200–400 ms zu halten.

Phase 4: Erster Frame (TTFD)

Nach Abschluss von onCreate beginnt die erste Darstellung: Messen, Layout, Zeichnen. Dieser Moment wird TTFD (Time To First Draw) genannt. Wenn die App einen Splashscreen (via SplashScreen API unter Android 12+ oder via Theme) verwendet, kann die Darstellung schneller erfolgen, aber der Benutzer wartet trotzdem, bis der Splash verschwindet. Die ideale TTFD für Cold Start beträgt weniger als 1,5 Sekunden.

So messen Sie Cold Start

Die Messung von Cold Start erfordert spezielle Werkzeuge, da die normale Protokollierung (Log.d) erst nach der Application-Erstellung funktioniert und das Fork-Timing sowie das Klassenladen nicht zugänglich sind. Google empfiehlt drei Methoden: ADB-Befehle, Android Vitals und benutzerdefinierte Leistungsmakros.

Messung über ADB

Die einfachste und reproduzierbarste Methode ist der Befehl adb shell am start -S -W. Das Flag -S stoppt die App vor dem Start zwangsweise (stellt Cold Start sicher). Der Befehl gibt drei Metriken aus: ThisTime (Activity-Startzeit), TotalTime (Gesamtzeit inklusive Prozessstart) und WaitTime (Zeit inklusive aller Verzögerungen des Activity Managers). Für saubere Messungen führen Sie 5–7 Messungen durch und verwenden Sie den Median — Einzelmessungen unterliegen Rauschen (CPU-Drosselung, Hintergrundlast).

# Erzwungener Cold Start mit Messung
$ adb shell am start -S -W \
    com.example.app/.MainActivity

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

Android Vitals (Google Play Console)

Die Google Play Console sammelt anonyme Metriken von allen Geräten, auf denen die App installiert ist. Im Abschnitt Android Vitals → Launch time wird die Medianverteilung von Cold Start nach Gerätemodell und Android-Version angezeigt. Dies ist die einzige Möglichkeit, echte Metriken auf Benutzergeräten zu sehen, nicht nur auf Testgeräten. Wenn Cold Start auf dem Redmi 9A (2 GB RAM) 5 Sekunden und auf dem Pixel 8 1,2 Sekunden überschreitet, liegt das Problem in der Speichergröße und der Klassenanzahl. Google zeigt auch die benutzerwahrnehmbare Verzögerung basierend auf dem 25. Perzentil an.

Macrobenchmark

Mit Google Jetpack Macrobenchmark (Bibliothek androidx.benchmark) können instrumentierte App-Starttests geschrieben werden. Der Test installiert die App, startet sie aus einem kalten Zustand und misst die Zeit bis zum ersten Frame. Macrobenchmark führt automatisch 20 Läufe durch, verwirft Ausreißer und zeigt stabile Perzentile. Für CI/CD können Sie Baseline und aktuellen Start vergleichen — wenn die Zeit zunimmt, kann die CI-Pipeline fehlschlagen.

So optimieren Sie Cold Start

Die Optimierung von Cold Start ist eine systematische Arbeit, die mehrere Ebenen der App betrifft: Code, Ressourcen, Build-Konfiguration und Initialisierungsarchitektur. Google empfiehlt, mit dem teuersten Teil — Application.onCreate — zu beginnen und sich zu den kleineren Details vorzuarbeiten.

Lazy Initialization

Verschieben Sie alle Initialisierungen, die beim Start nicht benötigt werden, aus Application.onCreate an den ersten Verwendungspunkt. Firebase, Crashlytics, Analytics-SDK, Push-Benachrichtigungen, DI-Komponenten — alles kann nach dem Rendern des ersten Bildschirms initialisiert werden. Verwenden Sie Lazy (by lazy) in Kotlin oder ContentProvider-Initialisierung mit einem expliziten initialize(context)-Aufruf. Laut Google (Android Performance, 2023) reduziert Lazy Initialization Cold Start um 40–60% für Apps, die 5+ SDKs verwenden.

Baseline Profiles

Baseline Profiles sind die AOT-Kompilierung kritischer Klassen und Methoden, die beim App-Start verwendet werden. Ohne Baseline Profiles interpretiert ART DEX-Code oder kompiliert ihn über JIT, was Zeit kostet. Mit Profilen kompiliert ART die angegebenen Methoden während der App-Installation in nativen Code (AOT). Google gibt an, dass Baseline Profiles Cold Start auf Android 9+ um 15–40% und mit ART-Optimierungen von Android 12+ um bis zu 60% beschleunigen. Verwenden Sie zum Erstellen von Profilen das Plugin androidx.benchmark:benchmark-baseline-profile-gradle-plugin.

App Startup Library

Die Bibliothek androidx.startup ermöglicht es, die Komponenteninitialisierung zu ordnen und in einem einzigen ContentProvider auszuführen. Anstatt mehrerer ContentProvider von verschiedenen Bibliotheken (jeder fügt 1–2 ms zum Kaltstart hinzu), fasst App Startup sie in einem Abhängigkeitsgraphen zusammen und initialisiert streng nach Bedarf. Beim Start werden nur Komponenten ausgeführt, die mit @Initializer markiert und für den ersten Bildschirm erforderlich sind. Für die übrigen wird das Flag needEarlyInit = false gesetzt — sie werden nach der ersten Darstellung gestartet.

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

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

Reduzierung der DEX-Größe

Die Größe der DEX-Datei wirkt sich direkt auf die ART-Ladezeit aus. Verwenden Sie R8/ProGuard für Verschleierung und Entfernung von totem Code (MinifyEnabled = true). Aktivieren Sie android:extractNativeLibs="false" im Manifest, damit das APK .so-Dateien bei der Installation nicht entpackt. Fügen Sie bei Projekten mit mehr als 10 Referenzverfolgungen startup-priority nur für den ersten Bildschirm hinzu. Jede zusätzliche Methode in DEX fügt 0,5–2 ms zum Laden hinzu, und bei Apps mit mehr als 50k Methoden (Multidex mit primary dex) — bis zu 300 ms.

Cold Start in Android Vitals

Android Vitals in der Google Play Console (Abschnitt Launch time) sammelt Daten von allen Geräten, auf denen die App installiert ist, vorausgesetzt der Benutzer hat der anonymen Diagnose zugestimmt. Die Metriken werden basierend auf der Cold-Start-Zeit in drei Kategorien eingeteilt: „gut“, „mäßig“, „schlecht“.

Google-Schwellenwerte

Google definiert „schlechten“ Cold Start als eine Zeit von mehr als 5 Sekunden auf jedem Gerät. In der Praxis gelten jedoch für Flaggschiffgeräte (Snapdragon 8 Gen) gute Zeiten von unter 1,5 Sekunden, für die Mittelklasse unter 2,5 Sekunden und für Budgetgeräte unter 4 Sekunden. Android Vitals zeigt den Median für jedes Gerätemodell an, sodass Sie erkennen können, auf welchen Geräten die App langsam startet. Wenn Cold Start auf Samsung A-Series- oder Xiaomi Redmi-Geräten schlecht ist, liegt die Ursache meistens an langsamem Flash-Speicher und wenig RAM (die Beschleunigung durch Baseline Profiles zeigt gerade auf solchen Geräten die größte Wirkung).

Wie Google Play die Metrik nutzt

Neben der Anzeige in der Konsole beeinflusst die Cold-Start-Metrik die Qualitätsbewertung der App in der Google Play-Suche. Apps mit einem hohen Anteil „schlechter“ Starts erhalten auf der Installationsseite das Label „Leistungswarnung“, was die Konversionsrate senkt. Laut Google (Android Performance Playbook, 2024) haben Apps, die Cold-Start-Probleme behoben haben, die Installationskonversion im Durchschnitt um 5% gesteigert und die Benutzerbindung (D1) um 3–7% verbessert.

Integration mit Firebase Performance

Für eine detailliertere Überwachung verwenden Sie Firebase Performance Monitoring. Es verfolgt Cold Start auf Sitzungsebene, aufgeschlüsselt nach App-Version und Android-Version. Im Gegensatz zu Android Vitals zeigt Firebase ein Trace-Diagramm der pro Phase aufgewendeten Zeit. Sie können beispielsweise sehen, dass in Version 3.2.0 der Application.onCreate 800 ms dauerte (aufgrund einer neuen Push-Benachrichtigungsbibliothek), während er in Version 3.2.1 — 200 ms dauerte (nach der Korrektur).

Codebeispiele zur Optimierung

Im Folgenden finden Sie zwei praktische Beispiele, die Cold Start direkt beschleunigen: Verschieben der SDK-Initialisierung nach dem Start und Verwendung der SplashScreen API.

Initialisierung aus Application.onCreate verschieben

Ein typischer Fehler ist die Initialisierung aller SDKs in Application.onCreate. Nachfolgend wird gezeigt, wie Sie die nicht kritische Initialisierung in eine Coroutine verschieben, die nach der Darstellung des ersten Frames gestartet wird. Wichtig: Firebase, Crashlytics und Crash Reporting SDK müssen beim Start initialisiert werden — sie können nicht aufgeschoben werden, da sie Abstürze während der Initialisierung anderer Komponenten abfangen. Für die übrigen verwenden Sie lifecycleScope in der ersten Activity.

// ❌ Schlecht — gesamte Initialisierung in Application.onCreate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // kritisch
        Analytics.init(this) // kann später
        Database.init(this) // kann später
        ImageLoader.init(this) // kann später
    }
}

// ✅ Gut — Firebase beim Start, Rest after inflate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// In MainActivity nach dem ersten Frame:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Verwenden Sie unter Android 12+ die offizielle SplashScreen API, die einen System-Splash (App-Symbol auf dunklem/hellem Hintergrund) sofort beim Start des Prozesses anzeigt. Dies verbirgt die Initialisierungszeit vor dem Benutzer — er sieht einen Splash anstelle eines weißen Bildschirms. Für ältere Geräte verwenden Sie theme-based splash (Theme.SplashScreen in Stilen). Wichtig: Der Splash sollte nicht länger als 300 ms dauern — wenn die App bis dahin nicht bereit ist, zeichnen Sie ein „beständiges“ Skelett (Shimmer) und zeigen Sie den Ladefortschritt an.

// 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-basierter 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>