Hot Start in mobilen Apps: Was es ist, Faktoren und wie man ihn beschleunigt

Was ist Hot Start in mobilen Apps

Hot Start ist ein Startszenario, bei dem der Prozess der App bereits im RAM des Geräts vorhanden ist. Der Benutzer minimiert die App, kehrt dann zurück — und das System erstellt keinen neuen Prozess, sondern setzt den vorhandenen fort. In diesem Szenario ist kein OS-Laden, keine Initialisierung der Application-Klasse und keine Prozesserstellung erforderlich, was die Zeit bis zum Erscheinen der UI auf dem Bildschirm drastisch verkürzt. Laut Android-Dokumentation (2025) dauert Hot Start nur 200–500 ms, während Cold Start 5 Sekunden oder mehr erreichen kann. Der Geschwindigkeitsunterschied ist besonders auf Geräten mit begrenztem Speicher spürbar, wo das System häufiger Hintergrund-Apps entlädt.

Das Hauptmerkmal von Hot Start ist der minimale Satz aufgerufener Lifecycle-Methoden. In Android sind dies Activity.onCreate und Activity.onStart; in iOS ist es applicationDidBecomeActive. Im Gegensatz zu Cold Start, bei dem Application.onCreate, ContentProvider.onCreate, Activity.onCreate und viele Bibliotheksinitialisierungen nacheinander aufgerufen werden, überspringt Hot Start alle diese Phasen. Der Entwickler muss verstehen, welcher Code speziell bei einem heißen Start ausgeführt wird — oft werden schwere SDK-Initialisierungen, Analysen und DI-Container sowohl bei Cold als auch bei Hot Start wiederholt, obwohl sie bei einem heißen Start nicht mehr benötigt werden.

Cold Start, Warm Start und Hot Start: Vergleich

Die drei App-Startszenarien unterscheiden sich in der Initialisierungstiefe. Cold Start tritt auf, wenn die App zum ersten Mal nach der Installation, einem Geräteneustart oder dem Entfernen aus dem Speicher gestartet wird. Das System erstellt einen neuen Linux-Prozess, lädt Application-Klassen, erstellt ContentProvider-Instanzen, führt Bibliotheksinitialisierungen durch und rendert erst dann die Activity. Der gesamte Prozess dauert je nach App-Komplexität und Geräteeigenschaften 2–10 Sekunden.

Warm Start ist ein intermediäres Szenario. Der App-Prozess ist im Speicher lebendig, aber die Activity wurde zerstört und muss neu erstellt werden. Dies geschieht zum Beispiel bei Bildschirmdrehung oder bei der Rückkehr aus einer anderen App, bei der die Activity aufgrund von Speichermangel entfernt wurde, der Prozess aber erhalten blieb. Warm Start umfasst den Aufruf von Activity.onCreate und Activity.onStart, aber nicht Application.onCreate oder die ContentProvider-Initialisierung. Die Warm-Start-Zeit beträgt 500 ms bis 2 Sekunden. Hot Start ist der schnellste der drei: Die Activity existiert bereits im Back Stack, der Prozess lebt, und das System ruft einfach Activity.onRestart, onStart und onResume auf. Die Hot-Start-Zeit beträgt 200–500 ms. Der Unterschied zu Warm Start besteht darin, dass die Activity nicht neu erstellt wird — sie wird aus der vorhandenen Instanz wiederhergestellt.

Android-Lifecycle während Hot Start

In Android wird Hot Start ausgelöst, wenn der Benutzer über den Recent-Bildschirm oder durch Antippen des App-Symbols im minimierten Zustand zur App zurückkehrt. Das System prüft, ob der Prozess lebt, und ruft in diesem Fall nacheinander Activity.onRestart, onStart und onResume auf. Die onCreate-Methode wird während Hot Start nicht aufgerufen, da die Activity-Instanz bereits im Speicher existiert. Dies ist ein wichtiger Unterschied zu Warm Start, wo onCreate aufgrund der Zerstörung der Activity noch aufgerufen wird. Laut Google I/O 2019 beträgt die typische Hot-Start-Zeit in Android 200–400 ms, und jede Verlangsamung in dieser Phase erhöht direkt die gefühlte Startzeit.

Entwickler übersehen oft, dass UI-Initialisierungscode, LiveData-Abonnements oder RecyclerView-Setups nicht nur in onCreate, sondern auch in onStart oder onResume ausgeführt werden. Während Hot Start werden diese Codeblöcke erneut ausgeführt, obwohl die UI bereits konfiguriert war. Es wird empfohlen, die einmalige Initialisierung (in onCreate mit savedInstanceState-Prüfung) und die wiederaufnehmbare Logik (onStart/onResume) zu trennen. Schwere Operationen — Adapter-Setup, Laden von Listen — sollten in einen Block verschoben werden, der während onRestart nicht ausgeführt wird, oder savedInstanceState prüfen.

Beispiel zur Verfolgung des Starttyps

Der folgende Kotlin-Code zeigt eine einfache Möglichkeit, das Startszenario zu erkennen und die Zeit zu messen. Die Variable launchTimeStamp erfasst den Startzeitpunkt, und isColdStart ermöglicht die Trennung der Logik für Kalt- und Heißstart.

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()
            // einmalige Initialisierung
        } else {
            isColdStart = false
            // Hot Start — Activity wird wiederhergestellt
        }
    }

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

iOS-Lifecycle beim heißen Start

In iOS entspricht Hot Start der Rückkehr der App aus dem Hintergrund über sceneDidBecomeActive (UIKit) oder onAppear (SwiftUI). Das Betriebssystem erstellt den Prozess nicht neu, wenn die App im Zustand "Suspendiert" oder "Hintergrund" war. Während eines heißen Starts wird applicationDidBecomeActive im AppDelegate aufgerufen, aber applicationDidFinishLaunching wird nicht aufgerufen — dies ist analog zu Android, wo Application.onCreate übersprungen wird. iOS entlädt Apps aggressiver aus dem Speicher: Wenn dem Gerät RAM fehlt, kann das System eine Hintergrund-App entladen, und der nächste Start wird ein Cold Start sein. Laut Apple Developer Documentation beträgt die durchschnittliche Hot-Start-Zeit in iOS 300–600 ms.

Ein wichtiger Unterschied in iOS ist das Fehlen eines direkten Analogons zu Warm Start im Android-Sinne. In iOS wird beim Minimieren einer App sceneDidEnterBackground aufgerufen, und bei der Rückkehr werden sceneWillEnterForeground und sceneDidBecomeActive aufgerufen. Wenn das System die Szene entlädt, aber den Prozess am Leben erhält, wird der nächste Start aus Sicht der Szene kalt, aber aus Sicht des Prozesses heiß sein. Der Entwickler muss dies bei der Platzierung von Initialisierungscode berücksichtigen: Abonnements von NotificationCenter, UI-Updates und Statuszurücksetzungen sollten in sceneDidBecomeActive erfolgen, nicht nur in viewDidLoad.

Beispiel zur Behandlung von Hot Start in iOS

Dieser Swift-Code zeigt, wie man die Anzahl der heißen Starts verfolgt und die Logik trennt. Der Zähler foregroundCount erhöht sich bei jeder Rückkehr aus dem Hintergrund.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — vollständige Initialisierung
            setupSDKs()
        } else {
            // Hot Start — nur UI-Aktualisierung
            refreshUI()
        }
    }

    private func refreshUI() {
        // Datenaktualisierung auf dem Bildschirm
    }
}

Faktoren, die die Hot-Start-Geschwindigkeit beeinflussen

Mehrere Kategorien von Faktoren beeinflussen die Geschwindigkeit von Hot Start. Die erste ist der Arbeitsaufwand in den Lifecycle-Methoden onStart und onResume. Wenn der Entwickler Netzwerkdatenladen, JSON-Parsing, Adapter-Initialisierung oder schwere Berechnungen in diese Methoden gelegt hat, fügt jeder solche Block Dutzende oder Hunderte von Millisekunden zur Startzeit hinzu. Laut Android Vitals verlieren Apps mit einer Hot-Start-Dauer von über 800 ms bis zu 20% der Benutzer bei der Rückkehr.

Die zweite Kategorie sind Fragmente und Ansichten, die aus savedInstanceState wiederhergestellt werden. Wenn Fragmente schweres ViewPager2, WebView oder komplexe tief verschachtelte Hierarchien enthalten, verbraucht ihre Wiederherstellung CPU-Ressourcen. Laut Google I/O 2023 fügt jede verschachtelte ViewGroup durchschnittlich 2–5 ms zur Renderzeit während Hot Start hinzu. Die dritte Kategorie sind Drittanbieter-SDKs: Analysebibliotheken, Crash-Reporting-Tools, A/B-Test-Frameworks und DEX-Loader können bei jeder Rückkehr aus dem Hintergrund Initialisierungen durchführen. Es wird empfohlen zu überprüfen, welche SDKs speziell in onStart/onResume Code ausführen, und nicht kritische Aufgaben auf einen Hintergrundthread zu verschieben.

Optimierungsmethoden für den heißen Start

Die Optimierung von Hot Start läuft darauf hinaus, die Arbeit in den Lifecycle-Methoden der Wiederaufnahme zu minimieren. Die erste Methode ist die verzögerte Initialisierung: Jeder Code, der nicht für den ersten UI-Frame benötigt wird, sollte nach onResume mit einer Verzögerung über Handler.postDelayed oder Coroutine.launch(Dispatchers.IO) ausgeführt werden. Die zweite Methode ist das Caching des Ansichtszustands: Wenn die App minimiert wird, speichern Sie Daten in einem In-Memory-Cache, damit Sie sie während Hot Start nicht aus der Datenbank oder dem Netzwerk neu laden müssen. Die dritte Methode ist die Verwendung von SavedStateHandle in Android und StateRestorationPolicy in iOS, um die Menge der wiederhergestellten Daten zu minimieren.

Verzögertes Laden nach Hot Start

In diesem Beispiel verschiebt Handler.postDelayed die Analyse-Initialisierung um 500 ms nach dem Rendern des ersten Frames. Dies beeinflusst die gefühlte Startzeit nicht, da der Benutzer die Oberfläche bereits sieht.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // Initialisierung nach dem ersten Frame
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Verwendung der App Startup-Bibliothek

AndroidX App Startup ermöglicht es Ihnen, die Initialisierungsreihenfolge von Komponenten beim Start zu steuern. Alle ContentProvider werden während Cold Start automatisch initialisiert, aber Sie können die automatische Initialisierung für Komponenten deaktivieren, die während Hot Start nicht benötigt werden.

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

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

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

Tools zur Überwachung der Startzeit

Zur Messung der Hot Start-Zeit gibt es sowohl integrierte Plattform-Tools als auch Drittanbieter-Lösungen. In Android ist das wichtigste Tool Android Vitals in der Google Play Console — es sammelt automatisch Startzeitmetriken für alle Szenarien (Cold, Warm, Hot), aufgeschlüsselt nach Gerätemodell und OS-Version. Zusätzlich können Sie Macrobenchmark von AndroidX verwenden — eine Bibliothek für automatisierte Startleistungstests. In iOS ist das Äquivalent MetricKit, das Daten über Startzeit, Bildrate und Speichernutzung sammelt.

Für detailliertes Profiling von heißen Starts eignen sich Firebase Performance Monitoring (verfolgt benutzerdefinierte Abläufe) und New Relic mit Startzeit-Dashboards. Auf Entwicklerseite wird für manuelle Messungen reportFullyDrawn in Android verwendet — eine API, die dem System den genauen Zeitpunkt mitteilt, an dem die UI gerendert und für Interaktionen bereit ist. In iOS ist das Äquivalent endActivity in MetricKit. Durch die Kombination dieser Tools können Sie identifizieren, welches SDK oder welcher Codeblock Hot Start auf bestimmten Geräten verlangsamt.

Macrobenchmark-Beispiel für Hot Start

Kotlin-Code mit der Macrobenchmark-Bibliothek zur Messung von Cold und Hot Start. Der Test startet die Activity und misst die Zeit bis zum vollständigen Zustand.

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