Cold Start — lényeg, hidegindítás és optimalizálás Androidon

Mi az a Cold Start

Cold Start (hidegindítás) az a forgatókönyv, amikor az Android-alkalmazás a legkezdetibb állapotból indul: az operációs rendszer új folyamatot hoz létre (fork a Zygote-ból), memóriát allokál, DEX-kódot tölt be az ART-ba, inicializálja az osztályokat, és létrehozza az Application példányát, majd az első Activity-t. Az alkalmazás elindulása előtt semmilyen adat nincs róla az eszköz memóriájában, kivéve az osztályok gyorsítótárazott képeit, ha Background Dexopt-ot használnak.

Mikor történik Cold Start

Hidegindítás három esetben fordul elő: az alkalmazás telepítése utáni első indításkor, az eszköz újraindítása utáni indításkor, és amikor a rendszer a memória hiánya miatt eltávolította a folyamatot. A 2–4 GB RAM-mal rendelkező eszközökön a rendszer agresszíven távolítja el a háttérfolyamatokat, ezért a Cold Start minden egyes, több órás tétlenkedés utáni visszatéréskor előfordulhat. Android 12+ esetén a rendszer megtarthat egy lefagyasztott folyamatot (freeze / cached), de aktív memóriatakarékosság mellett (OOM-killer) a folyamat megsemmisül.

Miért kritikus metrika a Cold Start

A Google adatai szerint (Find My Device report, 2023) a felhasználók 65%-a bezárja az alkalmazást, ha az nem nyílik meg 3 másodpercen belül. A közösségi hálózatok és üzenetküldők esetében, ahol a felhasználó naponta többször tér vissza, a Cold Start közvetlenül befolyásolja a retenciót. A Google Play Console-ban a Cold Start metrika az Android Vitals részben található, és az ANR és teljesítmény egyik mutatójaként jelenik meg. Az alkalmazás, amely meghaladja a "rossz" Cold Start küszöbértékét (több mint 5 másodperc az eszközök 25%-án), figyelmeztetést kap a konzolban, és alacsonyabb helyre kerülhet a keresésben.

Cold Start vs Warm Start vs Hot Start

Az Android háromféle alkalmazásindítást különböztet meg, amelyek mindegyike eltérő időtartammal, UX-hatással és optimalizálási megközelítéssel rendelkezik. A különbség megértése szükséges a megfelelő profilozási stratégia kiválasztásához.

Warm Start akkor történik, amikor az alkalmazás folyamata már létezik a háttérben, de az Activity megsemmisült (pl. a felhasználó hosszú szünet után tért vissza, és a rendszer felszabadította az Activity memóriáját). Hot Start — amikor a felhasználó minimalizálja az alkalmazást és azonnal újra megnyitja: az Activity szüneteltetve van, és a helyreállítás minimális időt vesz igénybe. A felhasználó számára a Cold Start a leginkább észrevehető indítási típus, és ennek optimalizálása adja a legnagyobb javulást a UX-ban.

Átmenet a típusok között

A Cold Start Warm Start-tá válhat, miután az alkalmazást legalább egyszer elindították — az ART gyorsítótárazza a lefordított osztályképeket (Image in Boot Profile), és a DEX újratöltése gyorsabb. Ezért a második indítás az első Cold Start után általában 20–40%-kal gyorsabb. Ha az alkalmazás Baseline Profiles-t használ, a profilok az első indításkor betöltődnek, és a második indítás még gyorsabb lehet: a Google Play, amely közzétette a Baseline Profiles-t, 30%-kal gyorsította fel a Cold Start-ot az Android 12+ eszközökön.

A hidegindítás fázisai

A Cold Start szigorúan meghatározott fázisokból áll, amelyek mindegyike függetlenül mérhető és optimalizálható. A fázisok ismerete segít meghatározni, hogy az alkalmazás melyik szakaszban veszít időt. A Google négy fő fázist különböztet meg: folyamat létrehozása, Application inicializálása, Activity létrehozása és első képkocka.

1. fázis: Folyamat létrehozása (fork)

Az Android rendszer (ActivityManagerService) új folyamatot hoz létre a Zygote folyamatból történő fork segítségével. A Zygote egy előre betöltött folyamat a közös Android-osztályokkal. A fork 30–80 ms alatt végrehajtódik — ezt az időt az alkalmazás nem tudja befolyásolni. A fork után elindul az ActivityThread — az alkalmazás fő ciklusának példánya. Ebben a szakaszban történik az osztályok betöltése a ClassLoader-en keresztül, és az ART elkezdi értelmezni az első bájtkódot. Ha az alkalmazás sok statikus inicializálót használ, ez a fázis elhúzódhat.

2. fázis: Application.onCreate

Közvetlenül az ActivityThread elindulása után meghívódik az Application.onCreate. Itt a fejlesztő leggyakrabban azt a hibát követi el, hogy mindent egyszerre inicializál: Crashlytics, Firebase, hálózati kliensek, adatbázisok, Dagger-komponensek, DI-tárolók. Minden ilyen inicializálás a főszálon blokkolt időt jelent. Ha az Application.onCreate 500 ms-ig tart, a felhasználó fél másodpercig fehér (vagy fekete) képernyőt lát. Ennek a fázisnak az optimális időtartama kevesebb mint 200 ms egy átlagos eszközön.

3. fázis: Activity.onCreate

Az Application inicializálása után létrejön az Activity (MainActivity vagy Launcher Activity) példánya. Meghívódik az Activity.onCreate, ahol a setContentView, a fragmentek inicializálása, a ViewModel beállítása, a LiveData/Flow feliratkozások történnek. Ha az onCreate szinkron módon tölt be adatokat (SharedPreferences, SQLite, API) a főszálon, a fázis meghosszabbodik. A cél az onCreate 200–400 ms-on belül tartása egy átlagos eszközön.

4. fázis: Első képkocka (TTFD)

Az onCreate befejezése után elkezdődik az első megjelenítés: measure, layout, draw. Ezt a pillanatot TTFD-nek (Time To First Draw) hívják. Ha az alkalmazás splash képernyőt használ (SplashScreen API-n keresztül Android 12+ esetén vagy témán keresztül), a megjelenítés gyorsabban megtörténhet, de a felhasználó akkor is vár, amíg a splash eltűnik. Az ideális TTFD Cold Start esetén kevesebb mint 1,5 másodperc.

Hogyan mérjük a Cold Start-ot

A Cold Start mérése speciális eszközöket igényel, mivel a szokásos naplózás (Log.d) csak az Application létrehozása után kezd működni, és a fork valamint az osztálybetöltés időzítése elérhetetlen marad. A Google három módszert ajánl: ADB-parancsok, Android Vitals és egyéni perf makrók.

Mérés ADB-n keresztül

A legegyszerűbb és reprodukálható módszer az adb shell am start -S -W parancs. Az -S jelző erőszakosan leállítja az alkalmazást az indítás előtt (garantálja a Cold Start-ot). A parancs három metrikát ad ki: ThisTime (Activity indítási ideje), TotalTime (teljes idő a folyamat indításával együtt) és WaitTime (idő az Activity Manager összes késleltetésével együtt). A tiszta mérés érdekében végezzen 5–7 mérést, és vegye a mediánt — az egyedi mérések zajnak vannak kitéve (CPU throttling, háttérterhelés).

# Kényszerített Cold Start méréssel
$ adb shell am start -S -W \
    com.example.app/.MainActivity

# Parancs kimenete:
# ThisTime: 1842 ms
# TotalTime: 1842 ms
# WaitTime: 1855 ms

Android Vitals (Google Play Console)

A Google Play Console anonim metrikákat gyűjt az összes olyan eszközről, amelyre az alkalmazás telepítve van. Az Android Vitals → Launch time szakaszban a Cold Start medián eloszlása látható eszközmodell és Android-verzió szerint. Ez az egyetlen módja annak, hogy valós mutatókat lássunk a felhasználók eszközein, nem pedig teszteszközökön. Ha a Redmi 9A-n (2 GB RAM) a Cold Start meghaladja az 5 másodpercet, a Pixel 8-on pedig 1,2 másodperc, a probléma a memóriakapacitásban és az osztályok számában van. A Google a felhasználó által érzékelt késleltetést (user-perceptible delay) is megjeleníti a 25. percentilis alapján.

Macrobenchmark

A Google Jetpack Macrobenchmark (androidx.benchmark könyvtár) lehetővé teszi instrumentált tesztek írását az alkalmazás indítására. A teszt telepíti az alkalmazást, hideg állapotban elindítja, és megméri az időt az első képkockáig. A Macrobenchmark automatikusan 20 futtatást végez, eltávolítja a kiugró értékeket, és stabil percentiliseket mutat. CI/CD esetén az összehasonlítható a baseline és a jelenlegi indítás — ha az idő nőtt, a CI pipeline meghiúsulhat.

Hogyan optimalizáljuk a Cold Start-ot

A Cold Start optimalizálása rendszerszintű munka, amely az alkalmazás több szintjét érinti: kód, erőforrások, build konfiguráció és inicializálási architektúra. A Google azt javasolja, hogy a legdrágábbal — az Application.onCreate-tel — kezdjük, és haladjunk a kisebb dolgok felé.

Lusta inicializálás (Lazy Init)

Az összes olyan inicializálást, amely nem szükséges az indításkor, helyezze át az Application.onCreate-ból az első használati pontba. Firebase, Crashlytics, analytics SDK, push-értesítések, DI-komponensek — mindez inicializálható az első képernyő megjelenítése után. Használjon Lazy (by lazy) inicializálást Kotlin-ban vagy ContentProvider-inicializálást explicit initialize(context) hívással. A Google adatai szerint (Android Performance, 2023) a lusta inicializálás 40–60%-kal csökkenti a Cold Start-ot az 5+ SDK-t használó alkalmazások esetében.

Baseline Profiles

A Baseline Profiles a kritikus osztályok és metódusok AOT-fordítása, amelyeket az alkalmazás indításakor használnak. Baseline Profiles nélkül az ART értelmezi a DEX-kódot, vagy JIT segítségével fordítja le, ami időt vesz igénybe. A profilokkal az ART a megadott metódusokat natív kódra (AOT) fordítja az alkalmazás telepítésekor. A Google állítása szerint a Baseline Profiles 15–40%-kal gyorsítja a Cold Start-ot Android 9+ esetén, és akár 60%-kal az Android 12+ ART-optimalizálásaival. A profilok létrehozásához használja az androidx.benchmark:benchmark-baseline-profile-gradle-plugin plugint.

App Startup Library

Az androidx.startup könyvtár lehetővé teszi a komponensek inicializálásának rendezését és egyetlen ContentProvider-ben történő végrehajtását. Több ContentProvider helyett (amelyek mindegyike 1–2 ms-t ad hozzá a hidegindításhoz) az App Startup függőségi gráfba egyesíti őket, és csak szükség esetén inicializál. Indításkor csak a @Initializer jelöléssel ellátott és az első képernyőhöz szükséges komponensek hajtódnak végre. A többiek számára a needEarlyInit = false jelző kerül beállításra — azok az első megjelenítés után indulnak el.

// App Startup Initializer — inicializálás indítás után
class AnalyticsInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Analytics.init(context)
    }
    override fun dependencies() = listOf<Class<out Initializer<*>>>()
}

// Az AndroidManifest.xml-ben opcionálisként jelöljük
// <meta-data android:name="AnalyticsInitializer"
//     android:value="false" />

A DEX méretének csökkentése

A DEX-fájl mérete közvetlenül befolyásolja az ART általi betöltési időt. Használjon R8/ProGuard-ot az obfuskációhoz és a halott kód eltávolításához (MinifyEnabled = true). Kapcsolja be az android:extractNativeLibs="false" beállítást a manifestben, hogy az APK ne csomagolja ki a .so fájlokat telepítéskor. A 10-nél több Reference Tracking osztállyal rendelkező projektek esetén csak az első képernyőhöz adjon hozzá startup-priority-t. Minden felesleges metódus a DEX-ben 0,5–2 ms-t ad hozzá a betöltéshez, és a 50k+ metódussal rendelkező alkalmazások esetében (multidex a primary dex-szel) — akár 300 ms-t.

Cold Start az Android Vitals-ban

Az Android Vitals a Google Play Console-ban (Launch time szakasz) adatokat gyűjt az összes olyan eszközről, amelyre az alkalmazás telepítve van, feltéve, hogy a felhasználó hozzájárult az anonim diagnosztikához. A metrikák három kategóriába vannak osztva: "good" (jó), "moderate" (közepes), "bad" (rossz), a Cold Start idejétől függően.

A Google küszöbértékei

A Google a "bad" Cold Start-ot olyan időként határozza meg, amely meghaladja az 5 másodpercet bármely eszközön. A gyakorlatban a zászlóshajó eszközökön (Snapdragon 8 Gen) a jó idő kevesebb mint 1,5 másodperc, a középkategóriában — kevesebb mint 2,5 másodperc, az olcsó készülékeknél — kevesebb mint 4 másodperc. Az Android Vitals az egyes device model-ek szerinti mediánt mutatja, ami segít megérteni, hogy mely eszközökön indul lassan az alkalmazás. Ha a Cold Start rossz a Samsung A-series vagy Xiaomi Redmi eszközökön, az ok általában a gyenge flash memória és a kis RAM (a Baseline Profiles segítségével történő gyorsítás pontosan az ilyen eszközökön adja a legnagyobb hatást).

Hogyan használja a Google Play a metrikát

A konzolban való megjelenítésen kívül a Cold Start metrika befolyásolja az alkalmazás minőségi értékelését a Google Play Search-ben. A "rossz" indítások magas százalékával rendelkező alkalmazások "Performance warning" címkét kapnak a telepítési oldalon, ami csökkenti a konverziót. A Google adatai szerint (Android Performance Playbook, 2024) a Cold Start-problémákat megoldó alkalmazások átlagosan 5%-kal növelik a telepítési konverziót és 3–7%-kal javítják a retenciót (D1).

Integráció a Firebase Performance-szel

Részletesebb monitorozáshoz használja a Firebase Performance Monitoring-ot. Ez nyomon követi a Cold Start-ot munkamenet szinten, alkalmazás-verzió és Android-verzió szerint bontva. Az Android Vitals-szal ellentétben a Firebase a fázisonkénti eltöltött idő trace diagramját mutatja. Például látható, hogy a 3.2.0 verzióban az Application.onCreate 800 ms-ig tartott (egy új push-értesítési könyvtár miatt), a 3.2.1 verzióban pedig 200 ms (a javítás után).

Kódpéldák az optimalizáláshoz

Az alábbiakban két gyakorlati példa található, amelyek közvetlenül gyorsítják a Cold Start-ot: az SDK-inicializálás áthelyezése indítás után és a SplashScreen API használata.

Inicializálás áthelyezése az Application.onCreate-ból

Tipikus hiba az összes SDK inicializálása az Application.onCreate-ban. Az alábbiakban bemutatjuk, hogyan lehet a nem kritikus inicializálást egy korutinba áthelyezni, amely az első képkocka megjelenítése után indul. Fontos: a Firebase, Crashlytics és Crash Reporting SDK-kat indításkor kell inicializálni — ezeket nem lehet elhalasztani, mivel a többi komponens inicializálása során fellépő összeomlásokat fogják el. A többiekhez használja a lifecycleScope-ot az első Activity-ben.

// ❌ Rossz — minden inicializálás az Application.onCreate-ban
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // kritikus
        Analytics.init(this) // később lehet
        Database.init(this) // később lehet
        ImageLoader.init(this) // később lehet
    }
}

// ✅ Jó — Firebase indításkor, a többi after inflate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// A MainActivity-ben az első képkocka után:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Android 12+ esetén használja a hivatalos SplashScreen API-t, amely a folyamat indulásakor azonnal megjeleníti a system-splash-t (alkalmazás ikon sötét/világos háttéren). Ez elrejti a felhasználó elől az inicializálási időt — ő a fehér képernyő helyett a splash-ot látja. Régebbi eszközökön használjon theme-based splash-t (Theme.SplashScreen a stílusokban). Fontos: a splash nem tarthat tovább 300 ms-nál — ha az alkalmazás ezalatt nem készül el, rajzoljon egy "állandó" vázat (shimmer), és mutassa a betöltés előrehaladását.

// 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-based splash (Android 5-11)
// A themes.xml-ben:
// <style name="Theme.App.Starting" parent="Theme.SplashScreen">
//   <item name="windowSplashScreenBackground">@color/white</item>
//   <item name="windowSplashScreenAnimatedIcon">@mipmap/ic_launcher</item>
// </style>