Warm Start: Wesen, warmer Start und Optimierung in Android

Was ist Warm Start

Warm Start ist ein Zustand zwischen Cold Start und Hot Start: Der App-Prozess existiert im Speicher (manchmal im Linux-Hintergrund-Cache), aber die Activity ist nicht aktiv und wird neu erstellt. Wenn Android der RAM ausgeht, kann es die Activity aus dem Stack entfernen und den Prozess am Leben lassen. Wenn der Benutzer zur App zurückkehrt, tritt ein Warm Start auf: Eine neue Activity-Instanz wird erstellt, die Lebenszyklus-Methoden onCreate → onStart → onResume werden ausgeführt, aber Application.onCreate und Klassenladen werden übersprungen.

Ursachen von Warm Start

Android entscheidet über das Entfernen der Activity basierend auf der Prozesspriorität (Bedeutungsrang). Eine Activity im Hintergrund (Ebene PROCESS_STATE_IMPORTANT_FOREGROUND oder PROCESS_STATE_TOP_SLEEPING) kann 5–30 Minuten nach dem Minimieren der App zerstört werden, abhängig vom verfügbaren RAM. Auf Geräten mit 3 GB RAM kann die Activity innerhalb von 10 Minuten entfernt werden, auf Geräten mit 8 GB RAM nach mehreren Stunden. Wichtig: Während des Warm Starts wird onSaveInstanceState aufgerufen, bevor die Activity zerstört wird, und der Entwickler kann den UI-Zustand speichern.

Benutzerwahrnehmung

Der Benutzer sieht keinen Unterschied zwischen Warm und Cold Start — er tippt einfach auf das App-Symbol und wartet. Während des Warm Starts kann jedoch ein weißer Bildschirm erscheinen, wenn die App kein benutzerdefiniertes Startfenster-Theme festgelegt hat. Google empfiehlt, ein benutzerdefiniertes Theme im Manifest (Theme.AppCompat.Light oder Theme.Material3.DayNight) für die Start-Activity festzulegen, um weiß/schwarzes Bildschirmflimmern während des Warm Starts zu vermeiden. Auf Android 12+ verbirgt die SplashScreen-API diesen Effekt ebenfalls.

Warm Start vs Cold Start vs Hot Start

Das Verständnis des Unterschieds zwischen den drei Starttypen ist entscheidend für die Wahl der richtigen Profiling- und Optimierungsstrategie. Jeder Typ hat seine eigene Dauer, eigene Engpässe und eigene Messwerkzeuge.

In der Praxis macht Warm Start 30 % bis 60 % aller App-Starts aus, abhängig von den Benutzergewohnheiten und dem Geräte-RAM. Benutzer, die viele Apps offen halten (Multitasker), erleben Warm Start häufiger. Für soziale Netzwerke und Messenger ist Warm Start das häufigste Szenario, da die App immer im Hintergrund läuft. Für Banking-Apps hingegen überwiegt Cold Start (erzwungene Prozessbereinigung aus Sicherheitsgründen).

Phasen des warmen Starts

Warm Start besteht aus drei Phasen, die jeweils gemessen und optimiert werden können. Im Gegensatz zu Cold Start gibt es keine Fork-Phase oder Klassenladen, aber es gibt eine Zustandswiederherstellungsphase, die teuer sein kann.

Phase 1: Startfenster (Hintergrundfenster)

Das System überprüft, ob die App ein Theme für das Startfenster hat. Wenn kein Theme festgelegt ist, wird ein weißer (oder schwarzer, je nach System) Bildschirm angezeigt. Wenn ein Theme festgelegt ist, wird der Theme-Hintergrund angezeigt. Diese Phase dauert 10–30 ms, ist aber visuell spürbar, wenn das Theme nicht mit der tatsächlichen UI der App übereinstimmt. Verwenden Sie Theme.Material3.DayNight mit einem benutzerdefinierten windowBackground, dessen Farbe mit dem Hintergrund des ersten Bildschirms übereinstimmt — dies erzeugt einen sofortigen Ladeeffekt.

Phase 2: Activity-Erstellung (Wiederherstellung)

Das System ruft onCreate auf und übergibt das Bundle savedInstanceState, das in onSaveInstanceState vor der Zerstörung der Activity gespeichert wurde. Wenn die App den Zustand korrekt gespeichert hat (Feldtext, Bildlaufposition, ViewModel-Daten), erfolgt die Wiederherstellung schnell. Andernfalls beginnt die Activity von Grund auf und der Benutzer sieht einen Ladeindikator, während Daten geladen werden. Wichtiger Punkt: ViewModel-Objekte überleben Warm Start nur, wenn der Prozess nicht zerstört wurde — während Warm Start bleibt das ViewModel im Speicher.

Phase 3: Erster Frame (TTFD)

Nach onCreate werden onStart → onResume ausgeführt, und das System löst die erste Zeichnung aus. TTFD (Time To First Draw) für Warm Start sollte auf einem Mittelklassegerät unter 300 ms liegen. Wenn der erste Bildschirm eine komplexe RecyclerView mit schweren Views enthält oder Bilder aus dem Netzwerk lädt, kann TTFD den Schwellenwert überschreiten. Verwenden Sie Placeholder und Shimmer für reibungsloses Inhaltsladen nach dem ersten Frame.

Wie man Warm Start misst

Warm Start zu messen ist komplexer als Cold Start, da man den Zustand simulieren muss, in dem der Prozess lebt, aber die Activity zerstört ist. Der Standard-ADB-Befehl mit dem Flag -S funktioniert nicht — er tötet den Prozess. Verwenden Sie andere Ansätze für Warm Start.

ADB shell am start ohne -S

Starten Sie die App zunächst über adb shell monkey oder tippen Sie auf das Symbol, minimieren Sie sie dann (adb shell input keyevent 3 keyevent HOME). Warten Sie 5–10 Sekunden, damit das System die Activity entfernen kann, und führen Sie dann adb shell am start -W (ohne -S) aus. Der Befehl gibt eine kürzere Startzeit als Cold Start zurück. Für Reproduzierbarkeit verwenden Sie ein Skript: Start → Warten → Home → Warten → Start.

# Simulation von Warm Start über ADB
$ adb shell am start -W \
    com.example.app/.MainActivity

# Ausgabe (Warm Start):
# ThisTime: 412 ms
# TotalTime: 412 ms
# WaitTime: 423 ms

Macrobenchmark für Warm Start

Die Bibliothek androidx.benchmark.macro unterstützt die Messung von Warm Start. Setzen Sie im Test startupMode = StartupMode.WARM — die Bibliothek startet die App, minimiert sie, wartet (konfigurierbare Verzögerung) und misst dann den Neustart. Macrobenchmark führt 10–20 Iterationen durch und berechnet Perzentile. In CI/CD können Sie einen Schwellenwert festlegen: Wenn P50 Warm Start 600 ms überschreitet, schlägt der Test fehl. Dies ermöglicht die Verfolgung von Regressionen bei jedem Commit.

Firebase Performance Monitoring

Firebase unterscheidet automatisch zwischen Cold und Warm Start basierend auf der Zeit seit dem letzten App-Schließen. Wenn die App innerhalb der letzten 30 Minuten geöffnet wurde, klassifiziert Firebase den Start als Warm. In der Firebase-Konsole sehen Sie separate Diagramme für jeden Starttyp, sodass Sie die Wirksamkeit von Optimierungen bewerten können. Nach der Implementierung der Zustandsspeicherung in ViewModel können Sie beispielsweise eine 30%ige Reduzierung der Warm-Start-Zeit feststellen.

Wie man Warm Start optimiert

Die Warm-Start-Optimierung konzentriert sich auf zwei Bereiche: Beschleunigung von Activity.onCreate und ordnungsgemäße Zustandswiederherstellung. Da Application.onCreate und Klassenladen bereits abgeschlossen sind, ist der Hauptengpass der UI-Code des ersten Bildschirms.

Asynchrone Zustandswiederherstellung

Wenn der gespeicherte Zustand (savedInstanceState) Daten enthält, die deserialisiert werden müssen (Bitmap, String, JSON), tun Sie dies in einem Hintergrundthread. Anstatt direkt aus dem Bundle in onCreate zu lesen, starten Sie eine Coroutine und zeigen Sie einen Shimmer-Bildschirm an. In der Praxis dauert die Bundle-Deserialisierung auf einem Mittelklassegerät 20–100 ms — es scheint wenig, aber für Warm Start sind das 10–50 % der Gesamtzeit. Verwenden Sie das Jetpack Saved State Module, das den ViewModel-Zustand automatisch im Bundle oder in der Datenbank speichert und wiederherstellt.

Optimierung von setContentView

XML-Layout-Inflation ist eine der teuersten Phasen von Warm Start. Wenn der erste Bildschirm ein komplexes CoordinatorLayout mit AppBar, CollapsingToolbar, NestedScrollView plus drei RecyclerViews verwendet, kann die Inflationszeit 300 ms erreichen. Lösungen: Verwenden Sie ConstraintLayout für eine flache Hierarchie, wenden Sie ViewStub für beim Start unsichtbare Abschnitte an (Bottom Sheet, Dialog), aktivieren Sie asynchrone Inflation für schwere Fragmente über AsyncLayoutInflater. In Jetpack Compose ist keine Inflation erforderlich, aber die Compose-Baum-Kompilierung während Warm Start kann eine ähnliche Zeit in Anspruch nehmen.

Daten-Caching

Während Warm Start können Daten, die die App in der vorherigen Sitzung geladen hat, bereits im Cache sein: Room-Datenbank, SharedPreferences, In-Memory-Cache im ViewModel. Wenn Ihr erster Bildschirm eine Liste vom Server anzeigt, überprüfen Sie den Cache beim Start und aktualisieren Sie die Daten im Hintergrund. Verwenden Sie die Cache-then-Network-Strategie: Zeigen Sie zuerst zwischengespeicherte Daten an (sofort), dann aktualisieren Sie vom Server (asynchron). Dies reduziert die wahrgenommene Warm-Start-Zeit auf 100–200 ms.

// ViewModel mit Caching für Warm Start
class FeedViewModel : ViewModel() {
    private val cache = MutableStateFlow<List<Item>>(emptyList())

    init {
        // Cache zuerst, dann Netzwerk
        viewModelScope.launch {
            cache.emit(db.getItems()) // Warm Start: Daten bereits in DB
            cache.emit(api.fetchItems()) // Hintergrundaktualisierung
        }
    }
}

Zustandserhaltung bei Warm Start

Die ordnungsgemäße Zustandserhaltung ist der Schlüsselfaktor, der einen guten Warm Start von einem schlechten unterscheidet. Der Benutzer erwartet, zur App zurückzukehren und genau das zu sehen, was er verlassen hat — einschließlich Bildlaufposition, Text in Feldern und ausgewählten Registerkarten.

onSaveInstanceState

Das System ruft onSaveInstanceState auf, wenn die Activity zerstört wird, aber BEVOR der Prozess getötet werden kann. Nur einfache Datentypen (String, Int, Parcelable, Serializable) werden im Bundle gespeichert. Für komplexe Daten verwenden Sie SavedStateHandle im ViewModel — es speichert und stellt Felder während Warm Start automatisch wieder her. Im Gegensatz zu onSaveInstanceState funktioniert SavedStateHandle auch, wenn der Prozess Warm Start überlebt (ViewModel wird nicht zerstört). Beispiel: Für Text in EditText verwenden Sie SavedStateHandle.getLiveData(„text“) — der Text wird automatisch gespeichert und wiederhergestellt.

ViewModel und Warm Start

Wenn der Prozess während Warm Start nicht getötet wurde, bleibt das ViewModel im Speicher und onCleared wird nicht aufgerufen. Das bedeutet, dass alle in der vorherigen Sitzung geladenen Daten sofort verfügbar sind. Wenn der Prozess jedoch getötet wurde (Gerät im Tiefschlaf für mehr als 30 Minuten), wird das ViewModel zerstört und mit SavedStateHandle neu erstellt. Für korrektes ViewModel-Verhalten während Warm Start verwenden Sie SavedStateHandle mit Feldern, die in jedem Szenario wiederhergestellt werden müssen. Unterschied: ViewModel mit @HiltViewModel unterstützt SavedStateHandle automatisch.

Bildlaufposition von RecyclerView speichern

Eines der häufigsten Warm-Start-Probleme — Verlust der Bildlaufposition. Der Benutzer scrollte zum 50. Element, minimierte die App, kehrte zurück — und sieht den Anfang der Liste. Lösung: Speichern Sie layoutManager.onSaveInstanceState (speichert Position und Offset des ersten sichtbaren Elements) und stellen Sie es in onRestoreInstanceState wieder her. Sie können auch die letzte sichtbare Position mit einem Datums-/Zeitschlüssel in SharedPreferences speichern, um die Position während Warm Start schnell wiederherzustellen.

// Bildlaufposition von RecyclerView speichern
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putParcelable(
        "rv_state", binding.recyclerView
            .layoutManager?.onSaveInstanceState()
    )
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    savedInstanceState?.getParcelable<Parcelable>("rv_state")
        ?.let { binding.recyclerView.layoutManager?.onRestoreInstanceState(it) }
}

Codebeispiele für Warm Start

Zwei praktische Beispiele für Warm-Start-Optimierung: Verwendung von SavedStateHandle im ViewModel und asynchrone Wiederherstellung komplexer Daten nach dem Start.

ViewModel mit SavedStateHandle

SavedStateHandle speichert Felder automatisch im Bundle und stellt sie während Warm Start wieder her. Das Benutzerprofilfeld (String, JSON) wird ohne unnötige Serveranfragen wiederhergestellt. Wenn der Prozess getötet wurde, lädt SavedStateHandle den letzten gespeicherten Zustand aus dem Bundle.

class ProfileViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    val profile: StateFlow<Profile?>
        get() = savedStateHandle
            .getStateFlow("profile", null)

    fun loadProfile(id: String) {
        viewModelScope.launch {
            savedStateHandle["profile"] =
                api.getProfile(id)
        }
    }
}

// Warm Start: profile ist nicht null, UI ohne Lader
// Nach dem Laden: profile wird in SavedStateHandle aktualisiert

AsyncLayoutInflater für schwere Bildschirme

Wenn der erste Bildschirm ein komplexes Layout enthält (Karte, Verlauf, mehrere Listen), verwenden Sie AsyncLayoutInflater, um schwere Elemente im Hintergrund aufzublähen. Während das Layout aufgebläht wird, zeigen Sie einen Platzhalter mit Shimmer-Effekt an. Dies ist besonders wichtig für Warm Start, wo jede Millisekunde zählt. AsyncLayoutInflater läuft auf einem Hintergrundthread und übergibt das fertige View an einen Callback auf dem Hauptthread.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Platzhalter-Layout für sofortiges Rendering
        setContentView(R.layout.placeholder_shimmer)

        // Asynchrones Laden von schwerem Layout
        AsyncLayoutInflater(this).inflate(
            R.layout.activity_main_complex,
            findViewById(R.id.container)
        ) { view, resId, parent ->
            parent?.removeAllViews()
            parent?.addView(view)
        }
    }
}