Cold Start — esența, pornirea la rece și optimizarea în Android

Ce este Cold Start

Cold Start (pornire la rece) — este scenariul în care aplicația Android pornește din starea cea mai inițială: sistemul de operare creează un proces nou (fork din Zygote), alocă memorie, încarcă codul DEX în ART, inițializează clasele și creează o instanță Application, apoi prima Activity. Înainte de pornirea aplicației, nu există niciun date despre ea în memoria dispozitivului, cu excepția imaginilor cache ale claselor, dacă se utilizează Background Dexopt.

Când are loc Cold Start

Pornirea la rece are loc în trei cazuri: la prima pornire după instalarea aplicației, la pornirea după repornirea dispozitivului și la pornirea după ce sistemul a descărcat procesul din cauza lipsei de memorie. Pe dispozitivele cu 2–4 GB RAM, sistemul descarcă procesele de fundal destul de agresiv, prin urmare Cold Start poate avea loc la fiecare revenire în aplicație după câteva ore de inactivitate. În Android 12+, sistemul poate păstra procesul înghețat (freeze / cached), dar în cazul economisirii active a memoriei (OOM-killer), procesul va fi distrus.

De ce Cold Start este o metrică critică

Potrivit Google (Find My Device report, 2023), 65% dintre utilizatori închid aplicația dacă aceasta nu se deschide în 3 secunde. Pentru rețelele sociale și mesagerii, unde utilizatorul revine de zeci de ori pe zi, Cold Start afectează direct retenția. În Google Play Console, metrica Cold Start se află în secțiunea Android Vitals și este afișată ca unul dintre indicatorii ANR și de performanță. Aplicația care depășește pragul de Cold Start „rău” (mai mult de 5 secunde pe 25% dintre dispozitive) primește un avertisment în consolă și poate fi retrogradată în căutare.

Cold Start vs Warm Start vs Hot Start

Android distinge trei tipuri de pornire a aplicației, fiecare având o durată diferită, impact asupra UX și abordări de optimizare. Înțelegerea diferenței este necesară pentru alegerea strategiei corecte de profilare.

Warm Start are loc atunci când procesul aplicației există deja în fundal, dar Activity a fost distrusă (de exemplu, utilizatorul s-a întors după o pauză lungă, iar sistemul a eliberat memoria Activity). Hot Start — când utilizatorul minimizează aplicația și o deschide imediat din nou: Activity este suspendată, iar restaurarea necesită un timp minim. Pentru utilizator, Cold Start este cel mai vizibil tip de pornire, iar optimizarea acestuia oferă cea mai mare creștere a UX.

Tranziția între tipuri

Cold Start poate deveni Warm Start după ce aplicația a fost pornită cel puțin o dată — ART stochează în cache imaginile compilate ale claselor (Image in Boot Profile), iar reîncărcarea DEX are loc mai rapid. Prin urmare, a doua pornire după primul Cold Start este de obicei cu 20–40% mai rapidă. Dacă aplicația utilizează Baseline Profiles, profilurile se încarcă la prima pornire, iar al doilea start poate fi și mai rapid: Google Play, care a publicat Baseline Profiles, a accelerat Cold Start cu 30% pe dispozitivele cu Android 12+.

Fazele pornirii la rece

Cold Start constă în faze strict definite, fiecare putând fi măsurată și optimizată independent. Cunoașterea fazelor ajută la determinarea etapei în care aplicația pierde timp. Google identifică patru faze principale: crearea procesului, inițializarea Application, crearea Activity și primul cadru.

Faza 1: Crearea procesului (fork)

Sistemul Android (ActivityManagerService) creează un proces nou prin fork din procesul Zygote. Zygote este un proces preîncărcat cu clasele comune Android. Fork se execută în 30–80 ms — acesta este timpul pe care aplicația nu îl poate controla. După fork, este pornit ActivityThread — instanța buclei principale a aplicației. În această etapă are loc, de asemenea, încărcarea claselor prin ClassLoader, iar ART începe să interpreteze primul bytecod. Dacă aplicația utilizează mulți inițializatori statici, această fază se poate prelungi.

Faza 2: Application.onCreate

Imediat după pornirea ActivityThread, este apelat Application.onCreate. Aici dezvoltatorul face cea mai frecventă greșeală, inițializând totul deodată: Crashlytics, Firebase, clienți de rețea, baze de date, componente Dagger, containere DI. Fiecare astfel de inițializare este timp blocat pe firul principal. Dacă Application.onCreate durează 500 ms, în acea jumătate de secundă utilizatorul vede un ecran alb (sau negru). Durata optimă a acestei faze este mai mică de 200 ms pe un dispozitiv mediu.

Faza 3: Activity.onCreate

După inițializarea Application, se creează o instanță Activity (MainActivity sau Launcher Activity). Este apelat Activity.onCreate, unde are loc setContentView, inițializarea fragmentelor, configurarea ViewModel, abonarea la LiveData/Flow. Dacă onCreate execută încărcarea datelor (SharedPreferences, SQLite, API) sincron pe firul principal, faza se extinde. Scopul este de a încadra onCreate în 200–400 ms pe un dispozitiv mediu.

Faza 4: Primul cadru (TTFD)

După finalizarea onCreate, începe prima randare: măsurare, layout, draw. Acest moment se numește TTFD (Time To First Draw). Dacă aplicația utilizează un ecran splash (prin SplashScreen API pe Android 12+ sau prin theme), randarea poate avea loc mai rapid, dar utilizatorul va aștepta oricum până când splash dispare. TTFD ideal pentru Cold Start este mai puțin de 1.5 secunde.

Cum se măsoară Cold Start

Măsurarea Cold Start necesită instrumente speciale, deoarece înregistrarea obișnuită (Log.d) își începe activitatea doar după crearea Application, iar sincronizarea fork și încărcarea claselor rămân inaccesibile. Google recomandă trei metode: comenzi ADB, Android Vitals și macro-uri personalizate perf.

Măsurarea prin ADB

Cea mai simplă și reproductibilă metodă este comanda adb shell am start -S -W. Flag-ul -S oprește forțat aplicația înainte de pornire (garantează Cold Start). Comanda afișează trei metrici: ThisTime (timpul de pornire a Activity), TotalTime (timpul total cu includerea pornirii procesului) și WaitTime (timpul cu toate întârzierile Activity Manager). Pentru o măsurare curată, efectuați 5–7 măsurători și luați mediana — măsurătorile individuale sunt supuse zgomotului (CPU throttling, sarcină de fundal).

# Cold Start forțat cu măsurare
$ adb shell am start -S -W \
    com.example.app/.MainActivity

# Rezultatul comenzii:
# ThisTime: 1842 ms
# TotalTime: 1842 ms
# WaitTime: 1855 ms

Android Vitals (Google Play Console)

Google Play Console colectează metrici anonime de pe toate dispozitivele pe care este instalată aplicația. În secțiunea Android Vitals → Launch time este afișată distribuția mediană Cold Start în funcție de modelul dispozitivului și versiunea Android. Aceasta este singura modalitate de a vedea valorile reale pe dispozitivele utilizatorilor, nu pe dispozitivele de test. Dacă pe Redmi 9A (2 GB RAM) Cold Start depășește 5 secunde, iar pe Pixel 8 — 1.2 secunde, problema constă în cantitatea de memorie și numărul de clase. Google arată, de asemenea, întârzierea perceptibilă de utilizator (user-perceptible delay) pe baza percentilei 25.

Macrobenchmark

Google Jetpack Macrobenchmark (biblioteca androidx.benchmark) permite scrierea de teste instrumentate de pornire a aplicației. Testul instalează aplicația, o pornește în stare rece și măsoară timpul până la primul cadru. Macrobenchmark execută automat 20 de rulări, elimină valorile aberante și arată percentile stabile. Pentru CI/CD, se poate compara baseline-ul cu pornirea curentă — dacă timpul a crescut, pipeline-ul CI poate eșua.

Cum se optimizează Cold Start

Optimizarea Cold Start este o muncă sistemică ce afectează mai multe niveluri ale aplicației: cod, resurse, configurația de compilare și arhitectura de inițializare. Google recomandă să începeți cu cel mai costisitor — Application.onCreate — și să treceți la detalii.

Inițializarea lentă (Lazy Init)

Transferați toată inițializarea care nu este necesară la pornire din Application.onCreate în primul punct de utilizare. Firebase, Crashlytics, analytics SDK, push-notifications, componente DI — toate pot fi inițializate după randarea primului ecran. Utilizați Lazy (by lazy) în Kotlin sau inițializarea ContentProvider cu apelul explicit initialize(context). Potrivit Google (Android Performance, 2023), inițializarea lentă reduce Cold Start cu 40–60% pentru aplicațiile care utilizează 5+ SDK.

Baseline Profiles

Baseline Profiles — este compilarea AOT a claselor și metodelor critice utilizate la pornirea aplicației. Fără Baseline Profiles, ART interpretează codul DEX sau îl compilează cu JIT, ceea ce necesită timp. Cu profilurile, ART compilează metodele specificate în cod nativ (AOT) la instalarea aplicației. Google afirmă că Baseline Profiles accelerează Cold Start cu 15–40% pe Android 9+ și până la 60% cu optimizările ART din Android 12+. Pentru crearea profilurilor, utilizați pluginul androidx.benchmark:benchmark-baseline-profile-gradle-plugin.

App Startup Library

Biblioteca androidx.startup permite organizarea inițializării componentelor și executarea acesteia într-un singur ContentProvider. În locul mai multor ContentProvider de la diferite biblioteci (fiecare adaugă 1–2 ms la pornirea la rece), App Startup le combină într-un graf de dependențe și inițializează strict la nevoie. La pornire, se execută doar componentele cu @Initializer marcate ca necesare pentru primul ecran. Pentru restul, se setează flag-ul needEarlyInit = false — acestea se lansează după prima randare.

// App Startup Initializer — inițializare după pornire
class AnalyticsInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Analytics.init(context)
    }
    override fun dependencies() = listOf<Class<out Initializer<*>>>()
}

// În AndroidManifest.xml marcam ca opțional
// <meta-data android:name="AnalyticsInitializer"
//     android:value="false" />

Reducerea dimensiunii DEX

Dimensiunea fișierului DEX afectează direct timpul de încărcare a acestuia de către ART. Utilizați R8/ProGuard pentru ofuscarea și eliminarea codului mort (MinifyEnabled = true). Activați android:extractNativeLibs="false" în manifest pentru ca APK să nu despacheteze fișierele .so la instalare. Pentru proiecte cu 10 Reference Tracking, adăugați startup-priority doar pentru primul ecran. Fiecare metodă suplimentară în DEX adaugă 0.5–2 ms la încărcare, iar pentru aplicațiile cu 50k+ metode (multidex cu primary dex) — până la 300 ms.

Cold Start în Android Vitals

Android Vitals din Google Play Console (Launch time section) colectează date de pe toate dispozitivele pe care este instalată aplicația, cu condiția acordului utilizatorului pentru diagnosticare anonimă. Metricele se împart în trei categorii: „good” (bun), „moderate” (mediu), „bad” (rău), în funcție de timpul Cold Start.

Valorile de prag Google

Google definește Cold Start „rău” ca timp care depășește 5 secunde pe orice dispozitiv. Însă în practică, pentru dispozitivele flagship (Snapdragon 8 Gen) timpul bun este sub 1.5 secunde, pentru gama medie — sub 2.5 secunde, pentru gama buget — sub 4 secunde. Android Vitals arată mediana pentru fiecare device model, ceea ce permite înțelegerea pe care dispozitive aplicația pornește lent. Dacă Cold Start este rău pe dispozitivele Samsung A-series sau Xiaomi Redmi, cauza este cel mai frecvent memoria flash slabă și cantitatea mică de RAM (accelerarea prin Baseline Profiles oferă cel mai mare efect tocmai pe astfel de dispozitive).

Cum folosește Google Play metrica

Pe lângă afișarea în consolă, metrica Cold Start influențează evaluarea calității aplicației în Google Play Search. Aplicațiile cu un procent ridicat de porniri „rele” primesc eticheta „Performance warning” pe pagina de instalare, ceea ce reduce conversia. Potrivit Google (Android Performance Playbook, 2024), aplicațiile care au rezolvat problemele de Cold Start încrăsc în medie conversia instalării cu 5% și îmbunătățesc indicatorul de retenție (D1) cu 3–7%.

Integrarea cu Firebase Performance

Pentru o monitorizare mai detaliată, utilizați Firebase Performance Monitoring. Acesta urmărește Cold Start la nivel de sesiuni, împarte pe versiuni ale aplicației și versiuni Android. Spre deosebire de Android Vitals, Firebase arată diagrama trace a timpului petrecut pe faze. De exemplu, se poate vedea că în versiunea 3.2.0 Application.onCreate dura 800 ms (din cauza unei noi biblioteci de notificări push), iar în versiunea 3.2.1 — 200 ms (după remediere).

Exemple de cod pentru optimizare

Mai jos sunt două exemple practice care accelerează direct Cold Start: mutarea inițializării SDK după pornire și utilizarea SplashScreen API.

Mutarea inițializării din Application.onCreate

O greșeală tipică — inițializarea tuturor SDK-urilor în Application.onCreate. Mai jos este arătat cum să mutați inițializarea necritică într-o corutină care se lansează după randarea primului cadru. Important: Firebase, Crashlytics și Crash Reporting SDK trebuie inițializate la pornire — nu pot fi amânate, deoarece prind erorile la inițializarea altor componente. Pentru restul, utilizați lifecycleScope la prima Activity.

// ❌ Rău — toată inițializarea în Application.onCreate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // critic
        Analytics.init(this) // poate mai târziu
        Database.init(this) // poate mai târziu
        ImageLoader.init(this) // poate mai târziu
    }
}

// ✅ Bine — Firebase la pornire, restul după inflate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// În MainActivity după primul cadru:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Pe Android 12+, utilizați SplashScreen API oficial, care arată splash-ul de sistem (icoana aplicației pe fundal întunecat/luminos) imediat la pornirea procesului. Aceasta ascunde timpul de inițializare de utilizator — acesta vede splash-ul, nu un ecran alb. Pentru dispozitivele vechi, utilizați theme-based splash (Theme.SplashScreen în stiluri). Important: splash-ul nu trebuie să dureze mai mult de 300 ms — dacă în acest timp aplicația nu este gata, desenați un schelet „permanent” (shimmer) și afișați progresul încărcării.

// 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)
// În themes.xml:
// <style name="Theme.App.Starting" parent="Theme.SplashScreen">
//   <item name="windowSplashScreenBackground">@color/white</item>
//   <item name="windowSplashScreenAnimatedIcon">@mipmap/ic_launcher</item>
// </style>