Cold Start — esensya, malamig na paglunsad at optimisasyon sa Android

Ano ang Cold Start

Cold Start (malamig na paglunsad) ay isang scenario kung saan ang Android app ay inilulunsad mula sa pinakasimulang estado: ang operating system ay gumagawa ng bagong proseso (fork mula sa Zygote), naglalaan ng memorya, naglo-load ng DEX code sa ART, nag-i-initialize ng mga klase at gumagawa ng instance ng Application, at pagkatapos ay ang unang Activity. Bago magsimula ang app, walang data tungkol dito sa memorya ng device, maliban sa mga naka-cache na imahe ng mga klase kung ginagamit ang Background Dexopt.

Kailan nangyayari ang Cold Start

Ang malamig na paglunsad ay nangyayari sa tatlong kaso: sa unang paglunsad pagkatapos i-install ang app, sa paglunsad pagkatapos i-restart ang device, at sa paglunsad pagkatapos alisin ng system ang proseso dahil sa kakulangan ng memorya. Sa mga device na may 2–4 GB RAM, agresibong inaalis ng system ang mga background na proseso, kaya ang Cold Start ay maaaring mangyari sa bawat pagbabalik sa app pagkatapos ng ilang oras na hindi ginagamit. Sa Android 12+, maaaring panatilihin ng system ang isang frozen na proseso (freeze / cached), ngunit sa aktibong pamamahala ng memorya (OOM-killer), ang proseso ay sisirain.

Bakit kritikal na metrik ang Cold Start

Ayon sa Google (Find My Device report, 2023), 65% ng mga user ay nagsasara ng app kung hindi ito bumukas sa loob ng 3 segundo. Para sa mga social network at messenger, kung saan ang user ay bumabalik nang dose-dosenang beses sa isang araw, ang Cold Start ay direktang nakakaapekto sa retention. Sa Google Play Console, ang Cold Start metric ay kasama sa seksyong Android Vitals at ipinapakita bilang isa sa mga indicator ng ANR at performance. Ang app na lumalampas sa threshold ng "masamang" Cold Start (higit sa 5 segundo sa 25% ng mga device) ay makakakuha ng babala sa console at maaaring ibaba sa paghahanap.

Cold Start vs Warm Start vs Hot Start

Ang Android ay nag-iiba ng tatlong uri ng paglunsad ng app, bawat isa ay may iba't ibang tagal, epekto sa UX, at approach sa optimisasyon. Ang pag-unawa sa pagkakaiba ay kinakailangan upang pumili ng tamang profiling strategy.

Ang Warm Start ay nangyayari kapag ang proseso ng app ay nasa background na, ngunit ang Activity ay nawasak na (hal., bumalik ang user pagkatapos ng mahabang pause at pinalaya ng system ang memorya ng Activity). Hot Start — kapag na-minimize ng user ang app at agad itong binuksan muli: ang Activity ay naka-pause at ang pagbawi ay tumatagal ng minimal na oras. Para sa user, ang Cold Start ang pinaka-noticeable na uri ng paglunsad, at ang optimisasyon nito ay nagbibigay ng pinakamalaking pagpapabuti sa UX.

Paglipat sa pagitan ng mga uri

Ang Cold Start ay maaaring maging Warm Start pagkatapos na ang app ay nailunsad nang kahit isang beses — ni-ca-cache ng ART ang mga naka-compile na imahe ng klase (Image in Boot Profile) at ang muling pag-load ng DEX ay mas mabilis. Samakatuwid, ang pangalawang paglunsad pagkatapos ng unang Cold Start ay karaniwang 20–40% mas mabilis. Kung ang app ay gumagamit ng Baseline Profiles, ang mga profile ay nilo-load sa unang paglunsad at ang pangalawang start ay maaaring mas mabilis pa: ang Google Play, na nag-publish ng Baseline Profiles, ay pinabilis ang Cold Start ng 30% sa mga device na may Android 12+.

Mga yugto ng cold start

Ang Cold Start ay binubuo ng mahigpit na tinukoy na mga yugto, na ang bawat isa ay maaaring sukatin at i-optimize nang nakapag-iisa. Ang pag-alam sa mga yugto ay tumutulong na matukoy kung saang yugto ang app ay nawawalan ng oras. Ang Google ay nag-iiba ng apat na pangunahing yugto: paggawa ng proseso, initialisasyon ng Application, paggawa ng Activity, at unang frame.

Yugto 1: Paggawa ng proseso (fork)

Ang Android system (ActivityManagerService) ay gumagawa ng bagong proseso sa pamamagitan ng fork mula sa proseso ng Zygote. Ang Zygote ay isang pre-loaded na proseso na may mga common na klase ng Android. Ang fork ay isinasagawa sa loob ng 30–80 ms — ito ang oras na hindi makokontrol ng app. Pagkatapos ng fork, magsisimula ang ActivityThread — ang instance ng main loop ng app. Sa yugtong ito, nangyayari rin ang pag-load ng mga klase sa pamamagitan ng ClassLoader, at sinisimulan ng ART na i-interpret ang unang bytecode. Kung ang app ay gumagamit ng maraming static initializer, ang yugtong ito ay maaaring humaba.

Yugto 2: Application.onCreate

Kaagad pagkatapos magsimula ang ActivityThread, ang Application.onCreate ay tinatawag. Dito madalas nagkakamali ang developer, na ini-initialize ang lahat nang sabay-sabay: Crashlytics, Firebase, network clients, database, Dagger components, DI containers. Ang bawat ganitong initialisasyon ay oras na naka-block sa main thread. Kung ang Application.onCreate ay tumatagal ng 500 ms, sa kalahating segundong iyon ang user ay nakakakita ng puti (o itim) na screen. Ang optimal na tagal ng yugtong ito ay mas mababa sa 200 ms sa karaniwang device.

Yugto 3: Activity.onCreate

Pagkatapos ng initialisasyon ng Application, ang instance ng Activity (MainActivity o Launcher Activity) ay ginagawa. Ang Activity.onCreate ay tinatawag, kung saan nangyayari ang setContentView, initialisasyon ng mga fragment, configuration ng ViewModel, pag-subscribe sa LiveData/Flow. Kung ang onCreate ay naglo-load ng data (SharedPreferences, SQLite, API) nang sabay-sabay sa main thread, ang yugto ay humahaba. Ang layunin ay panatilihin ang onCreate sa loob ng 200–400 ms sa karaniwang device.

Yugto 4: Unang frame (TTFD)

Pagkatapos ng onCreate, magsisimula ang unang rendering: measure, layout, draw. Ang moment na ito ay tinatawag na TTFD (Time To First Draw). Kung ang app ay gumagamit ng splash screen (sa pamamagitan ng SplashScreen API sa Android 12+ o sa pamamagitan ng theme), ang rendering ay maaaring mangyari nang mas mabilis, ngunit ang user ay maghihintay pa rin hanggang mawala ang splash. Ang ideal na TTFD para sa Cold Start ay mas mababa sa 1.5 segundo.

Paano sukatin ang Cold Start

Ang pagsukat ng Cold Start ay nangangailangan ng mga espesyal na tool, dahil ang ordinaryong logging (Log.d) ay nagsisimula lamang pagkatapos ng paggawa ng Application, at ang timing ng fork at pag-load ng klase ay nananatiling hindi ma-access. Ang Google ay nagrerekomenda ng tatlong paraan: ADB commands, Android Vitals, at custom perf macros.

Pagsukat sa pamamagitan ng ADB

Ang pinakasimple at reproducible na paraan ay ang command na adb shell am start -S -W. Ang flag na -S ay pinipilit na ihinto ang app bago ang paglunsad (ginagarantiya ang Cold Start). Ang command ay naglalabas ng tatlong metric: ThisTime (oras ng paglunsad ng Activity), TotalTime (kabuuang oras kasama ang pagsisimula ng proseso) at WaitTime (oras kasama ang lahat ng pagkaantala ng Activity Manager). Para sa malinis na pagsukat, gumawa ng 5–7 na pagsukat at kunin ang median — ang mga solong pagsukat ay madaling kapitan ng noise (CPU throttling, background load).

# Pilit na Cold Start na may pagsukat
$ adb shell am start -S -W \
    com.example.app/.MainActivity

# Output ng command:
# ThisTime: 1842 ms
# TotalTime: 1842 ms
# WaitTime: 1855 ms

Android Vitals (Google Play Console)

Ang Google Play Console ay nangongolekta ng mga anonymous na metric mula sa lahat ng device kung saan naka-install ang app. Sa seksyong Android Vitals → Launch time, ang median distribution ng Cold Start ay ipinapakita ayon sa modelo ng device at bersyon ng Android. Ito ang tanging paraan upang makita ang tunay na mga indicator sa mga device ng user, hindi sa mga test device. Kung sa Redmi 9A (2 GB RAM) ang Cold Start ay lumampas sa 5 segundo, at sa Pixel 8 — 1.2 segundo, ang problema ay nasa kapasidad ng memorya at bilang ng mga klase. Ipinapakita rin ng Google ang pagkaantala na nararamdaman ng user (user-perceptible delay) batay sa 25th percentile.

Macrobenchmark

Ang Google Jetpack Macrobenchmark (library na androidx.benchmark) ay nagpapahintulot na magsulat ng mga instrumented test para sa paglunsad ng app. Ang test ay nag-i-install ng app, inilulunsad ito sa malamig na estado, at sinusukat ang oras hanggang sa unang frame. Ang Macrobenchmark ay awtomatikong gumagawa ng 20 runs, nagtatapon ng mga outlier, at nagpapakita ng mga stable percentile. Para sa CI/CD, ang baseline ay maaaring ihambing sa kasalukuyang paglunsad — kung ang oras ay tumaas, ang CI pipeline ay maaaring mabigo.

Paano i-optimize ang Cold Start

Ang optimisasyon ng Cold Start ay isang sistemikong gawain na nakakaapekto sa maraming antas ng app: code, resources, build configuration, at architecture ng initialisasyon. Ang Google ay nagrerekomenda na magsimula sa pinakamahal — Application.onCreate — at lumipat sa mas maliliit na bagay.

Lazy initialization (Lazy Init)

Ilipat ang lahat ng initialisasyon na hindi kinakailangan sa startup mula sa Application.onCreate patungo sa unang punto ng paggamit. Firebase, Crashlytics, analytics SDK, push-notifications, DI components — lahat ay maaaring i-initialize pagkatapos ng rendering ng unang screen. Gamitin ang Lazy (by lazy) sa Kotlin o ContentProvider initialization na may explicit na tawag na initialize(context). Ayon sa Google (Android Performance, 2023), ang lazy initialization ay nagbabawas ng Cold Start ng 40–60% para sa mga app na gumagamit ng 5+ SDK.

Baseline Profiles

Baseline Profiles ay AOT compilation ng mga kritikal na klase at method na ginagamit sa paglunsad ng app. Kung walang Baseline Profiles, ang ART ay nag-i-interpret ng DEX code o nag-co-compile nito gamit ang JIT, na tumatagal ng oras. Sa mga profile, ang ART ay nag-co-compile ng mga tinukoy na method sa native code (AOT) kapag nag-i-install ng app. Sinasabi ng Google na ang Baseline Profiles ay nagpapabilis ng Cold Start ng 15–40% sa Android 9+ at hanggang 60% sa ART optimizations ng Android 12+. Para gumawa ng mga profile, gamitin ang plugin na androidx.benchmark:benchmark-baseline-profile-gradle-plugin.

App Startup Library

Ang library na androidx.startup ay nagpapahintulot na ayusin ang initialisasyon ng mga component at isagawa ito sa isang ContentProvider. Sa halip na maraming ContentProvider mula sa iba't ibang library (bawat isa ay nagdaragdag ng 1–2 ms sa cold start), pinagsasama ng App Startup ang mga ito sa isang dependency graph at nag-i-initialize lamang kapag kinakailangan. Sa startup, ang mga component lamang na may markang @Initializer at kinakailangan para sa unang screen ang isinasagawa. Para sa iba, ang flag na needEarlyInit = false ay itinatakda — sila ay magsisimula pagkatapos ng unang rendering.

// App Startup Initializer — initialisasyon pagkatapos ng start
class AnalyticsInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Analytics.init(context)
    }
    override fun dependencies() = listOf<Class<out Initializer<*>>>()
}

// Sa AndroidManifest.xml markahan bilang opsyonal
// <meta-data android:name="AnalyticsInitializer"
//     android:value="false" />

Pagbawas ng laki ng DEX

Ang laki ng DEX file ay direktang nakakaapekto sa oras ng pag-load nito ng ART. Gamitin ang R8/ProGuard para sa obfuscation at pag-alis ng patay na code (MinifyEnabled = true). I-enable ang android:extractNativeLibs="false" sa manifest upang hindi i-extract ng APK ang .so files sa pag-install. Para sa mga proyekto na may higit sa 10 klase ng Reference Tracking, idagdag ang startup-priority para lamang sa unang screen. Ang bawat sobrang method sa DEX ay nagdaragdag ng 0.5–2 ms sa pag-load, at para sa mga app na may 50k+ method (multidex na may primary dex) — hanggang 300 ms.

Cold Start sa Android Vitals

Ang Android Vitals sa Google Play Console (seksyong Launch time) ay nangongolekta ng data mula sa lahat ng device kung saan naka-install ang app, sa kondisyon na pumayag ang user sa anonymous diagnostics. Ang mga metric ay nahahati sa tatlong kategorya: "good" (mabuti), "moderate" (katamtaman), "bad" (masama), depende sa oras ng Cold Start.

Mga threshold value ng Google

Tinutukoy ng Google ang "bad" Cold Start bilang oras na lampas sa 5 segundo sa anumang device. Sa praktika, para sa mga flagship device (Snapdragon 8 Gen), ang mabuting oras ay mas mababa sa 1.5 segundo, para sa mid-range — mas mababa sa 2.5 segundo, para sa budget — mas mababa sa 4 na segundo. Ang Android Vitals ay nagpapakita ng median bawat device model, na tumutulong na maunawaan kung saang device ang app ay mabagal magsimula. Kung ang Cold Start ay masama sa Samsung A-series o Xiaomi Redmi device, ang dahilan ay kadalasang mahinang flash memory at maliit na RAM (ang pagpapabilis sa pamamagitan ng Baseline Profiles ay nagbibigay ng pinakamalaking epekto sa mga naturang device).

Paano ginagamit ng Google Play ang metric

Bukod sa pagpapakita sa console, ang Cold Start metric ay nakakaapekto sa pagtatasa ng kalidad ng app sa Google Play Search. Ang mga app na may mataas na porsyento ng "masamang" paglunsad ay nakakakuha ng label na "Performance warning" sa page ng pag-install, na nagpapababa ng conversion. Ayon sa Google (Android Performance Playbook, 2024), ang mga app na nag-aayos ng Cold Start problema ay nagpapataas ng conversion ng pag-install ng average na 5% at nagpapabuti ng retention (D1) ng 3–7%.

Integrasyon sa Firebase Performance

Para sa mas detalyadong monitoring, gamitin ang Firebase Performance Monitoring. Sinusubaybayan nito ang Cold Start sa antas ng session, hinahati ayon sa bersyon ng app at bersyon ng Android. Hindi tulad ng Android Vitals, ang Firebase ay nagpapakita ng trace diagram ng oras na ginugol bawat yugto. Halimbawa, makikita na sa bersyon 3.2.0, ang Application.onCreate ay tumagal ng 800 ms (dahil sa bagong push notification library), at sa bersyon 3.2.1 — 200 ms (pagkatapos ng pag-aayos).

Mga halimbawa ng code para sa optimisasyon

Nasa ibaba ang dalawang praktikal na halimbawa na direktang nagpapabilis ng Cold Start: paglipat ng SDK initialization pagkatapos ng start at paggamit ng SplashScreen API.

Paglipat ng initialization mula sa Application.onCreate

Ang tipikal na pagkakamali ay ang pag-initialize ng lahat ng SDK sa Application.onCreate. Sa ibaba ay ipinapakita kung paano ilipat ang hindi kritikal na initialization sa isang coroutine na magsisimula pagkatapos ng rendering ng unang frame. Mahalaga: Ang Firebase, Crashlytics at Crash Reporting SDK ay dapat na i-initialize sa startup — hindi sila maaaring ipagpaliban dahil nahuhuli nila ang mga crash sa initialisasyon ng iba pang component. Para sa iba, gamitin ang lifecycleScope sa unang Activity.

// ❌ Masama — lahat ng initialisasyon nasa Application.onCreate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // kritikal
        Analytics.init(this) // maaaring mamaya
        Database.init(this) // maaaring mamaya
        ImageLoader.init(this) // maaaring mamaya
    }
}

// ✅ Mabuti — Firebase sa start, ang iba after inflate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// Sa MainActivity pagkatapos ng unang frame:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Sa Android 12+, gamitin ang opisyal na SplashScreen API, na nagpapakita ng system splash (icon ng app sa madilim/maliwanag na background) kaagad kapag nagsimula ang proseso. Ito ay nagtatago ng oras ng initialisasyon mula sa user — nakakakita siya ng splash, hindi puting screen. Para sa mga lumang device, gamitin ang theme-based splash (Theme.SplashScreen sa styles). Mahalaga: ang splash ay hindi dapat tumagal nang higit sa 300 ms — kung ang app ay hindi handa sa oras na iyon, gumuhit ng "permanent" skeleton (shimmer) at ipakita ang progress ng pag-load.

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