Hot Start mobilalkalmazásokban: mi ez, tényezők és hogyan gyorsítsuk fel

Mi az a Hot Start a mobilalkalmazásokban

Hot Start — olyan indítási forgatókönyv, amelyben az alkalmazás folyamata már létezik a készülék RAM memóriájában. A felhasználó minimalizálja az alkalmazást, majd visszatér — és a rendszer nem hoz létre új folyamatot, hanem folytatja a meglévőt. Ebben a forgatókönyvben nincs szükség az operációs rendszer betöltésére, az Application osztály inicializálására és a folyamat létrehozására, ami drámaian csökkenti a UI megjelenéséig eltelt időt. Az Android Documentation (2025) szerint a Hot Start mindössze 200–500 ms-ig tart, míg a Cold Start elérheti az 5 másodpercet vagy többet. A sebességbeli különbség különösen észrevehető a korlátozott memóriájú eszközökön, ahol a rendszer gyakrabban távolítja el a háttéralkalmazásokat.

A Hot Start fő jellemzője — a meghívott lifecycle metódusok minimális készlete. Android esetén ezek az Activity.onCreate és Activity.onStart, iOS esetén — applicationDidBecomeActive. Ellentétben a Cold Start-tal, ahol egymás után meghívódik az Application.onCreate, ContentProvider.onCreate, Activity.onCreate és számos könyvtárinicializálás, a Hot Start kihagyja ezeket a szakaszokat. A fejlesztőnek meg kell értenie, mely kód hajtódik végre pontosan a meleg indításkor — gyakran az SDK-k, analitika és DI konténerek nehéz inicializálásai mind a Cold, mind a Hot Start esetén megismétlődnek, annak ellenére, hogy meleg indításkor már nincs rájuk szükség.

Cold Start, Warm Start és Hot Start: összehasonlítás

Az alkalmazásindítás három forgatókönyve az inicializálás mélységében különbözik. Cold Start (hideg indítás) akkor történik, amikor az alkalmazást első alkalommal indítják telepítés után, eszköz újraindításkor vagy memóriából való eltávolításkor. A rendszer létrehoz egy új Linux folyamatot, betölti az Application osztályokat, létrehozza a ContentProvider példányokat, végrehajtja a könyvtárak inicializálását, és csak ezután jeleníti meg az Activity-t. Az egész folyamat 2–10 másodpercig tart az alkalmazás összetettségétől és az eszköz jellemzőitől függően.

Warm Start (langyos indítás) — köztes forgatókönyv. Az alkalmazás folyamata él a memóriában, de az Activity megsemmisült és újra kell hozni. Ez történik például képernyőforgatáskor vagy másik alkalmazásból való visszatéréskor, amikor az Activity a memóriahiány miatt eltávolításra került, de a folyamat megmaradt. A Warm Start magában foglalja az Activity.onCreate és Activity.onStart meghívását, de nem tartalmazza az Application.onCreate és a ContentProvider inicializálását. A Warm Start ideje — 500 ms-tól 2 másodpercig. Hot Start — a leggyorsabb a három közül: az Activity már létezik a back stack-ben, a folyamat él, és a rendszer egyszerűen meghívja az Activity.onRestart, onStart és onResume metódusokat. A Hot Start ideje — 200–500 ms. A különbség a Warm Start-hoz képest, hogy az Activity nem jön létre újra — egy meglévő példányból áll helyre.

Android Lifecycle Hot Start esetén

Androidban a Hot Start akkor indul, amikor a felhasználó a Recents képernyőn keresztül vagy az ikonra kattintva minimalizált állapotból visszatér az alkalmazásba. A rendszer ellenőrzi, hogy a folyamat él-e, és ha igen — egymás után meghívja az Activity.onRestart, onStart és onResume metódusokat. Az onCreate metódus nem hívódik meg Hot Start esetén, mivel az Activity példánya már létezik a memóriában. Ez fontos különbség a Warm Start-hoz képest, ahol az onCreate az Activity megsemmisülése miatt mégis meghívódik. A Google I/O 2019 szerint a tipikus Hot Start idő Androidban 200–400 ms, és minden lassulás ebben a fázisban közvetlenül növeli az észlelt indítási időt.

A fejlesztők gyakran nem veszik észre, hogy a UI inicializálás, LiveData feliratkozás vagy RecyclerView beállítás kódja nem csak az onCreate-ben, hanem az onStart vagy onResume metódusokban is végrehajtódik. Hot Start esetén ezek a kódblokkok újra végrehajtódnak, annak ellenére, hogy a UI már be van állítva. Javasolt az egyszeri inicializálás (onCreate-ben savedInstanceState ellenőrzéssel) és a folytatható logika (onStart/onResume) szétválasztása. Például a nehéz műveleteket — adapterek beállítása, listák betöltése — jobb olyan blokkba áthelyezni, amely nem hajtódik végre onRestart esetén, vagy ellenőrizni a savedInstanceState-et.

Példa az indítás típusának követésére

A következő Kotlin kód egy egyszerű módot mutat az indítási forgatókönyv meghatározására és az idő mérésére. A launchTimeStamp változó rögzíti az indítás kezdetének pillanatát, az isColdStart pedig lehetővé teszi a logika szétválasztását hideg és meleg indítás esetén.

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()
            // egyszeri inicializálás
        } else {
            isColdStart = false
            // Hot Start — Activity helyreáll
        }
    }

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

iOS Lifecycle meleg indítás esetén

iOS-ben a Hot Start az alkalmazás háttérből való visszatérésének felel meg a sceneDidBecomeActive (UIKit) vagy onAppear (SwiftUI) függvényen keresztül. Az operációs rendszer nem hozza újra létre a folyamatot, ha az alkalmazás Suspended vagy Background állapotban volt. Meleg indításkor az applicationDidBecomeActive meghívódik az AppDelegate-ben, de az applicationDidFinishLaunching nem — ez analóg az Androiddal, ahol az Application.onCreate kimarad. Az iOS agresszívabban távolítja el az alkalmazásokat a memóriából: ha az eszköznek nincs elegendő RAM-ja, a rendszer eltávolíthatja a háttéralkalmazást, és a következő indítás Cold Start lesz. Az Apple Developer Documentation szerint az átlagos Hot Start idő iOS-ben 300–600 ms.

Az iOS legfontosabb különbsége — a Warm Start közvetlen analógiájának hiánya az Android értelmezésében. iOS-ben az alkalmazás minimalizálásakor a sceneDidEnterBackground hívódik meg, visszatéréskor pedig — sceneWillEnterForeground és sceneDidBecomeActive. Ha a rendszer eltávolítja a jelenetet, de a folyamatot életben hagyja, a következő indítás a jelenet szempontjából Cold, de a folyamat szempontjából Hot lesz. A fejlesztőnek ezt figyelembe kell vennie az inicializáló kód elhelyezésekor: a NotificationCenter feliratkozás, UI frissítés és állapotok visszaállítása pontosan a sceneDidBecomeActive függvényben kell legyen, nem csak a viewDidLoad-ban.

Példa Hot Start kezelésére iOS-ben

Ez a Swift kód megmutatja, hogyan lehet követni a meleg indítások számát és szétválasztani a logikát. A foregroundCount számláló minden háttérből való visszatéréskor növekszik.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — teljes inicializálás
            setupSDKs()
        } else {
            // Hot Start — csak UI frissítés
            refreshUI()
        }
    }

    private func refreshUI() {
        // adatfrissítés a képernyőn
    }
}

A Hot Start sebességét befolyásoló tényezők

A Hot Start sebességét több tényezőkategória befolyásolja. Az első — a munka mennyisége az onStart és onResume lifecycle metódusokban. Ha a fejlesztő ezekbe a metódusokba hálózati adatbetöltést, JSON feldolgozást, adapter inicializálást vagy nehéz számításokat helyezett el, minden ilyen blokk tíz- és százmilliszekundumokat ad hozzá az indítási időhöz. Az Android Vitals eszköz adatai szerint a 800 ms-nál hosszabb Hot Start időtartamú alkalmazások akár 20%-át is elveszítik a felhasználóknak ismételt visszatéréskor.

A második kategória — a savedInstanceState-ből helyreállított fragmensek és View-k. Ha a fragmensek nehéz ViewPager2, WebView vagy mély egymásba ágyazással rendelkező összetett hierarchiákat tartalmaznak, helyreállításuk CPU erőforrásokat igényel. A Google I/O 2023 szerint minden egymásba ágyazott ViewGroup átlagosan 2–5 ms-t ad hozzá a renderelési időhöz Hot Start esetén. A harmadik kategória — harmadik féltől származó SDK-k: analitikai könyvtárak, crash-reporting, A/B-tesztelés és DEX betöltők inicializálást végezhetnek minden háttérből való visszatéréskor. Javasolt ellenőrizni, mely SDK-k futtatnak kódot pontosan az onStart/onResume metódusokban, és a nem kritikus feladatokat háttérszálra halasztani.

A meleg indítás optimalizálásának módszerei

A Hot Start optimalizálása a folytatás lifecycle metódusaiban végzett munka minimalizálására vezethető vissza. Az első módszer — lusta inicializálás: minden kódot, amely nem szükséges az első UI képkockához, az onResume meghívása után kell végrehajtani késleltetéssel Handler.postDelayed vagy Coroutine.launch(Dispatchers.IO) segítségével. A második módszer — a View állapotának gyorsítótárazása: az alkalmazás minimalizálásakor mentse az adatokat in-memory gyorsítótárba, hogy Hot Start esetén ne kelljen újra betölteni azokat az adatbázisból vagy hálózatból. A harmadik módszer — a SavedStateHandle használata Androidban és a StateRestorationPolicy iOS-ben a helyreállított adatok mennyiségének minimalizálására.

Lusta betöltés Hot Start után

Ebben a példában a Handler.postDelayed 500 ms-mal késlelteti az analitika inicializálását az első képkocka renderelése után. Ez nem befolyásolja az észlelt indítási időt, mivel a felhasználó már látja a felületet.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // inicializálás az első képkocka után
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Az App Startup könyvtár használata

Az AndroidX App Startup lehetővé teszi a komponensek inicializálási sorrendjének kezelését indításkor. Az összes ContentProvider automatikusan inicializálódik Cold Start esetén, de kikapcsolhatja az automatikus inicializálást azon komponensek számára, amelyek nem szükségesek Hot Start esetén.

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

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

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

Indítási idő figyelésére szolgáló eszközök

A Hot Start idő mérésére mind a platformok beépített eszközei, mind harmadik féltől származó megoldások léteznek. Androidban a kulcsfontosságú eszköz az Android Vitals a Google Play Console-ban — automatikusan gyűjti az indítási idő metrikáit az összes forgatókönyvhöz (Cold, Warm, Hot) eszközmodellek és OS verziók szerinti bontásban. Ezenkívül használható az AndroidX-ből származó Macrobenchmark — egy könyvtár az indítási teljesítmény automatizált tesztelésére. iOS-ben az ekvivalens a MetricKit, amely adatokat gyűjt az indítási időről, képkocka gyakoriságról és memóriahasználatról.

A meleg indítás részletes profilozásához a Firebase Performance Monitoring (custom traces követése) és a New Relic indítási idő irányítópultokkal alkalmas. A fejlesztő oldalán kézi méréshez az Androidban a reportFullyDrawn használatos — egy API, amely jelzi a rendszernek a pontos pillanatot, amikor a UI renderelve van és készen áll a interakcióra. iOS-ben az ekvivalens a endActivity a MetricKit-ben. Ezeket az eszközöket kombinálva azonosítható, mely SDK vagy kódblokk lassítja a Hot Start-ot pontosan bizonyos eszközökön.

Példa Macrobenchmark-ra Hot Start esetén

Kód Kotlin-ban a Macrobenchmark könyvtár használatával a Cold és Hot Start méréséhez. A teszt elindítja az Activity-t és méri az időt a complete állapot eléréséig.

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