Hot Start v mobilních aplikacích: co to je, faktory a jak urychlit

Co je Hot Start v mobilních aplikacích

Hot Start — je scénář spuštění aplikace, při kterém její proces již existuje v paměti RAM zařízení. Uživatel aplikaci minimalizuje, poté se vrátí — a systém nevytváří nový proces, ale obnovuje stávající. V tomto scénáři není vyžadováno načítání OS, inicializace třídy Application a vytvoření procesu, což radikálně zkracuje dobu do zobrazení UI na obrazovce. Podle Android Documentation (2025) trvá Hot Start pouze 200–500 ms, zatímco Cold Start může dosáhnout 5 sekund a více. Rozdíl v rychlosti je zvláště patrný na zařízeních s omezenou pamětí, kde systém častěji uvolňuje aplikace na pozadí.

Hlavní charakteristika Hot Start — minimální sada volaných lifecycle metod. V Androidu jsou to Activity.onCreate a Activity.onStart, v iOS — applicationDidBecomeActive. Na rozdíl od Cold Start, kde jsou postupně volány Application.onCreate, ContentProvider.onCreate, Activity.onCreate a četné inicializace knihoven, Hot Start všechny tyto fáze přeskakuje. Vývojář musí rozumět, který kód se spouští právě při horkém startu — často se těžké inicializace SDK, analytiky a DI kontejnerů opakují jak při Cold, tak při Hot Start, i když při horkém startu již nejsou potřeba.

Cold Start, Warm Start a Hot Start: srovnání

Tři scénáře spuštění aplikace se liší hloubkou inicializace. Cold Start (studený start) nastává, když je aplikace spuštěna poprvé po instalaci, restartu zařízení nebo uvolnění z paměti. Systém vytváří nový Linuxový proces, načítá třídy Application, vytváří instance ContentProvider, provádí inicializaci knihoven a teprve poté zobrazuje Activity. Celý proces trvá 2–10 sekund v závislosti na složitosti aplikace a charakteristikách zařízení.

Warm Start (vlažný start) — přechodný scénář. Proces aplikace žije v paměti, ale Activity bylo zničeno a musí být znovu vytvořeno. K tomu dochází například při otáčení obrazovky nebo při návratu z jiné aplikace, kdy bylo Activity uvolněno kvůli nedostatku paměti, ale proces zůstal. Warm Start zahrnuje volání Activity.onCreate a Activity.onStart, ale nezahrnuje Application.onCreate a inicializaci ContentProvider. Doba Warm Start — od 500 ms do 2 sekund. Hot Start — nejrychlejší ze tří: Activity již existuje v zásobníku zpět, proces žije a systém jednoduše volá Activity.onRestart, onStart a onResume. Doba Hot Start — 200–500 ms. Rozdíl oproti Warm Start spočívá v tom, že Activity není vytvářeno znovu — je obnoveno z existující instance.

Android Lifecycle při Hot Start

V Androidu je Hot Start iniciován, když se uživatel vrací do aplikace přes obrazovku Recents nebo kliknutím na ikonu v minimalizovaném stavu. Systém zkontroluje, zda proces žije, a pokud ano — postupně volá Activity.onRestart, onStart a onResume. Metoda onCreate se při Hot Start nevolá, protože instance Activity již existuje v paměti. To je důležitý rozdíl oproti Warm Start, kde je onCreate stále volán kvůli zničení Activity. Podle Google I/O 2019 je typická doba Hot Start v Androidu 200–400 ms a jakékoli zpomalení v této fázi přímo zvyšuje vnímaný čas spuštění.

Vývojáři často nezaznamenají, že kód inicializace UI, přihlášení k LiveData nebo nastavení RecyclerView se spouští nejen v onCreate, ale také v onStart nebo onResume. Při Hot Start se tyto bloky kódu spouštějí znovu, i když UI již bylo nastaveno. Doporučuje se oddělovat jednorázovou inicializaci (v onCreate s kontrolou savedInstanceState) a obnovitelnou logiku (onStart/onResume). Například těžké operace — nastavení adaptérů, načítání seznamů — je lepší přesunout do bloku, který se nespouští při onRestart, nebo kontrolovat savedInstanceState.

Příklad sledování typu spuštění

Následující kód v Kotlin demonstruje jednoduchý způsob určení scénáře startu a měření času. Proměnná launchTimeStamp zaznamenává okamžik zahájení spuštění a isColdStart umožňuje oddělit logiku pro studený a horký 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()
            // jednorázová inicializace
        } else {
            isColdStart = false
            // Hot Start — Activity je obnoveno
        }
    }

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

iOS Lifecycle při horkém spuštění

V iOS Hot Start odpovídá návratu aplikace z pozadí prostřednictvím sceneDidBecomeActive (UIKit) nebo onAppear (SwiftUI). Operační systém znovu nevytváří proces, pokud byla aplikace ve stavu Suspended nebo Background. Při horkém spuštění je voláno applicationDidBecomeActive v AppDelegate, ale není voláno applicationDidFinishLaunching — to je analogie Androidu, kde je Application.onCreate přeskočeno. iOS uvolňuje aplikace z paměti agresivněji: pokud zařízení nemá dostatek RAM, systém může uvolnit aplikaci na pozadí a další spuštění bude Cold Start. Podle Apple Developer Documentation je průměrná doba Hot Start v iOS 300–600 ms.

Klíčový rozdíl iOS — absence přímé analogie Warm Start v chápání Androidu. V iOS při minimalizaci aplikace je voláno sceneDidEnterBackground a při návratu — sceneWillEnterForeground a sceneDidBecomeActive. Pokud systém uvolní scénu, ale ponechá proces naživu, další spuštění bude Cold z hlediska scény, ale Hot z hlediska procesu. Vývojář to musí zohlednit při umísťování inicializačního kódu: přihlášení k NotificationCenter, aktualizace UI a resetování stavů by měly být právě v sceneDidBecomeActive, nejen v viewDidLoad.

Příklad zpracování Hot Start v iOS

Tento kód v Swift ukazuje, jak sledovat počet horkých spuštění a oddělit logiku. Počítadlo foregroundCount se zvyšuje při každém návratu z pozadí.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — plná inicializace
            setupSDKs()
        } else {
            // Hot Start — pouze aktualizace UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // aktualizace dat na obrazovce
    }
}

Faktory ovlivňující rychlost Hot Start

Rychlost Hot Start ovlivňuje několik kategorií faktorů. První — množství práce v lifecycle metodách onStart a onResume. Pokud vývojář do těchto metod umístil načítání dat ze sítě, parsování JSON, inicializaci adaptérů nebo těžké výpočty, každý takový blok přidává desítky a stovky milisekund k době spuštění. Podle údajů nástroje Android Vitals ztrácejí aplikace s dobou Hot Start delší než 800 ms až 20 % uživatelů při opakovaném návratu.

Druhá kategorie — fragmenty a View obnovované z savedInstanceState. Pokud fragmenty obsahují těžké ViewPager2, WebView nebo složité hierarchie s hlubokým vnořením, jejich obnova spotřebovává CPU prostředky. Podle Google I/O 2023 přidává každý vnořený ViewGroup v průměru 2–5 ms k době vykreslování při Hot Start. Třetí kategorie — SDK třetích stran: knihovny analytiky, crash-reporting, A/B-testování a DEX zavaděče mohou provádět inicializaci při každém návratu z pozadí. Doporučuje se zkontrolovat, která SDK spouštějí kód právě v onStart/onResume, a odkládat nekritické úkoly na vlákno na pozadí.

Metody optimalizace horkého spuštění

Optimalizace Hot Start spočívá v minimalizaci práce v lifecycle metodách obnovení. První metoda — líná inicializace: veškerý kód, který není potřeba pro první snímek UI, by měl být spuštěn po volání onResume se zpožděním prostřednictvím Handler.postDelayed nebo Coroutine.launch(Dispatchers.IO). Druhá metoda — ukládání stavu View do mezipaměti: při minimalizaci aplikace ukládejte data do paměťové cache, aby při Hot Start nebylo nutné je znovu načítat z databáze nebo sítě. Třetí metoda — použití SavedStateHandle v Androidu a StateRestorationPolicy v iOS pro minimalizaci objemu obnovovaných dat.

Líné načítání po Hot Start

V tomto příkladu Handler.postDelayed odkládá inicializaci analytiky o 500 ms po vykreslení prvního snímku. To neovlivňuje vnímaný čas spuštění, protože uživatel již vidí rozhraní.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // inicializace po prvním snímku
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Použití knihovny App Startup

AndroidX App Startup umožňuje řídit pořadí inicializace komponent při spuštění. Všechny ContentProvider jsou automaticky inicializovány při Cold Start, ale můžete vypnout automatickou inicializaci pro komponenty, které nejsou potřeba při 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<*>>()
}

Nástroje pro monitorování doby spuštění

Pro měření doby Hot Start existují jak vestavěné nástroje platforem, tak řešení třetích stran. V Androidu je klíčovým nástrojem Android Vitals v konzoli Google Play — automaticky sbírá metriky doby spuštění pro všechny scénáře (Cold, Warm, Hot) s rozdělením podle modelů zařízení a verzí OS. Dále lze použít Macrobenchmark z AndroidX — knihovnu pro automatizované testování výkonu spouštění. V iOS je ekvivalentem MetricKit, který sbírá data o době spuštění, snímkové frekvenci a využití paměti.

Pro detailní profilování horkého spuštění jsou vhodné Firebase Performance Monitoring (sleduje custom traces) a New Relic s dashboardy doby spuštění. Na straně vývojáře se pro ruční měření používá reportFullyDrawn v Androidu — API, které hlásí systému přesný okamžik, kdy je UI vykresleno a připraveno k interakci. V iOS je ekvivalentem endActivity v MetricKit. Kombinací těchto nástrojů lze zjistit, které SDK nebo blok kódu zpomaluje Hot Start právě na konkrétních zařízeních.

Příklad Macrobenchmark pro Hot Start

Kód v Kotlin s použitím knihovny Macrobenchmark pro měření Cold a Hot Start. Test spouští Activity a měří čas do stavu complete.

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