Cold Start — esensi, cold start, dan optimasi di Android

Apa itu Cold Start

Cold Start (start dingin) adalah skenario ketika aplikasi Android dimulai dari keadaan paling awal: sistem operasi membuat proses baru (fork dari Zygote), mengalokasikan memori, memuat kode DEX ke ART, menginisialisasi kelas, dan membuat instance Application, lalu Activity pertama. Sebelum aplikasi dimulai, tidak ada data tentangnya di memori perangkat, kecuali gambar kelas yang di-cache jika Background Dexopt digunakan.

Kapan Cold Start terjadi

Cold start terjadi dalam tiga kasus: saat pertama kali dijalankan setelah instalasi aplikasi, saat dijalankan setelah perangkat di-restart, dan saat dijalankan setelah sistem menghapus proses karena kekurangan memori. Pada perangkat dengan RAM 2–4 GB, sistem menghapus proses latar belakang secara agresif, sehingga Cold Start dapat terjadi setiap kali kembali ke aplikasi setelah beberapa jam tidak digunakan. Di Android 12+, sistem dapat mempertahankan proses yang dibekukan (freeze / cached), tetapi dengan manajemen memori aktif (OOM-killer), proses akan dimusnahkan.

Mengapa Cold Start adalah metrik kritis

Menurut Google (Find My Device report, 2023), 65% pengguna menutup aplikasi jika tidak terbuka dalam 3 detik. Untuk jejaring sosial dan messenger, di mana pengguna kembali puluhan kali sehari, Cold Start secara langsung memengaruhi retensi. Di Google Play Console, metrik Cold Start termasuk dalam bagian Android Vitals dan ditampilkan sebagai salah satu indikator ANR dan kinerja. Aplikasi yang melebihi ambang batas Cold Start "buruk" (lebih dari 5 detik pada 25% perangkat) mendapat peringatan di konsol dan dapat diturunkan peringkatnya dalam pencarian.

Cold Start vs Warm Start vs Hot Start

Android membedakan tiga jenis startup aplikasi, masing-masing dengan durasi, dampak pada UX, dan pendekatan optimasi yang berbeda. Memahami perbedaannya diperlukan untuk memilih strategi profiling yang tepat.

Warm Start terjadi ketika proses aplikasi sudah ada di latar belakang, tetapi Activity telah dihancurkan (misalnya, pengguna kembali setelah jeda panjang dan sistem membebaskan memori Activity). Hot Start — ketika pengguna meminimalkan aplikasi dan segera membukanya lagi: Activity dijeda dan pemulihan membutuhkan waktu minimal. Bagi pengguna, Cold Start adalah jenis startup yang paling terlihat, dan optimalisasinya memberikan peningkatan terbesar pada UX.

Transisi antar jenis

Cold Start dapat menjadi Warm Start setelah aplikasi dijalankan setidaknya sekali — ART menyimpan cache gambar kelas yang dikompilasi (Image in Boot Profile) dan pemuatan ulang DEX menjadi lebih cepat. Oleh karena itu, startup kedua setelah Cold Start pertama biasanya 20–40% lebih cepat. Jika aplikasi menggunakan Baseline Profiles, profil dimuat pada startup pertama dan startup kedua bisa lebih cepat lagi: Google Play, yang menerbitkan Baseline Profiles, mempercepat Cold Start sebesar 30% pada perangkat dengan Android 12+.

Fase cold start

Cold Start terdiri dari fase-fase yang ditentukan secara ketat, yang masing-masing dapat diukur dan dioptimalkan secara independen. Mengetahui fase-fase ini membantu menentukan pada tahap mana aplikasi kehilangan waktu. Google membedakan empat fase utama: pembuatan proses, inisialisasi Application, pembuatan Activity, dan frame pertama.

Fase 1: Pembuatan proses (fork)

Sistem Android (ActivityManagerService) membuat proses baru melalui fork dari proses Zygote. Zygote adalah proses yang telah dimuat sebelumnya dengan kelas-kelas umum Android. Fork dieksekusi dalam 30–80 ms — ini adalah waktu yang tidak dapat dikontrol oleh aplikasi. Setelah fork, ActivityThread dimulai — instance dari loop utama aplikasi. Pada tahap ini juga terjadi pemuatan kelas melalui ClassLoader, dan ART mulai menginterpretasi bytecode pertama. Jika aplikasi menggunakan banyak inisialisasi statis, fase ini dapat diperpanjang.

Fase 2: Application.onCreate

Segera setelah ActivityThread dimulai, Application.onCreate dipanggil. Di sini pengembang paling sering melakukan kesalahan dengan menginisialisasi semuanya sekaligus: Crashlytics, Firebase, klien jaringan, database, komponen Dagger, container DI. Setiap inisialisasi semacam itu adalah waktu yang diblokir di thread utama. Jika Application.onCreate membutuhkan 500 ms, selama setengah detik itu pengguna melihat layar putih (atau hitam). Durasi optimal fase ini adalah kurang dari 200 ms pada perangkat kelas menengah.

Fase 3: Activity.onCreate

Setelah inisialisasi Application, instance Activity (MainActivity atau Launcher Activity) dibuat. Activity.onCreate dipanggil, di mana setContentView, inisialisasi fragmen, konfigurasi ViewModel, langganan ke LiveData/Flow terjadi. Jika onCreate memuat data (SharedPreferences, SQLite, API) secara sinkron di thread utama, fase ini diperpanjang. Tujuannya adalah menjaga onCreate dalam 200–400 ms pada perangkat kelas menengah.

Fase 4: Frame pertama (TTFD)

Setelah onCreate selesai, rendering pertama dimulai: measure, layout, draw. Momen ini disebut TTFD (Time To First Draw). Jika aplikasi menggunakan layar splash (melalui SplashScreen API di Android 12+ atau melalui tema), rendering dapat terjadi lebih cepat, tetapi pengguna tetap akan menunggu sampai splash menghilang. TTFD ideal untuk Cold Start adalah kurang dari 1,5 detik.

Cara mengukur Cold Start

Mengukur Cold Start memerlukan alat khusus, karena logging biasa (Log.d) mulai bekerja hanya setelah pembuatan Application, dan waktu fork serta pemuatan kelas tetap di luar jangkauan. Google merekomendasikan tiga metode: perintah ADB, Android Vitals, dan makro perf kustom.

Pengukuran melalui ADB

Cara paling sederhana dan dapat direproduksi adalah perintah adb shell am start -S -W. Flag -S secara paksa menghentikan aplikasi sebelum startup (menjamin Cold Start). Perintah ini mengeluarkan tiga metrik: ThisTime (waktu startup Activity), TotalTime (total waktu termasuk startup proses) dan WaitTime (waktu termasuk semua penundaan Activity Manager). Untuk pengukuran yang bersih, lakukan 5–7 pengukuran dan ambil median — pengukuran tunggal rentan terhadap noise (CPU throttling, beban latar belakang).

# Cold Start paksa dengan pengukuran
$ adb shell am start -S -W \
    com.example.app/.MainActivity

# Keluaran perintah:
# ThisTime: 1842 ms
# TotalTime: 1842 ms
# WaitTime: 1855 ms

Android Vitals (Google Play Console)

Google Play Console mengumpulkan metrik anonim dari semua perangkat tempat aplikasi diinstal. Di bagian Android Vitals → Launch time, distribusi median Cold Start ditampilkan berdasarkan model perangkat dan versi Android. Ini adalah satu-satunya cara untuk melihat indikator nyata pada perangkat pengguna, bukan pada perangkat uji. Jika pada Redmi 9A (2 GB RAM) Cold Start melebihi 5 detik, dan pada Pixel 8 — 1,2 detik, masalahnya ada pada kapasitas memori dan jumlah kelas. Google juga menampilkan penundaan yang dirasakan pengguna (user-perceptible delay) berdasarkan persentil ke-25.

Macrobenchmark

Google Jetpack Macrobenchmark (pustaka androidx.benchmark) memungkinkan penulisan tes terinstrumentasi untuk startup aplikasi. Tes menginstal aplikasi, menjalankannya dalam keadaan dingin, dan mengukur waktu hingga frame pertama. Macrobenchmark secara otomatis melakukan 20 kali putaran, membuang outlier, dan menunjukkan persentil yang stabil. Untuk CI/CD, baseline dapat dibandingkan dengan startup saat ini — jika waktu meningkat, pipeline CI dapat gagal.

Cara mengoptimalkan Cold Start

Optimasi Cold Start adalah pekerjaan sistemik yang memengaruhi beberapa tingkat aplikasi: kode, sumber daya, konfigurasi build, dan arsitektur inisialisasi. Google merekomendasikan memulai dari yang paling mahal — Application.onCreate — dan beralih ke hal-hal yang lebih kecil.

Inisialisasi lambat (Lazy Init)

Pindahkan semua inisialisasi yang tidak diperlukan saat startup dari Application.onCreate ke titik penggunaan pertama. Firebase, Crashlytics, analytics SDK, push-notifikasi, komponen DI — semuanya dapat diinisialisasi setelah rendering layar pertama. Gunakan Lazy (by lazy) di Kotlin atau inisialisasi ContentProvider dengan panggilan eksplisit initialize(context). Menurut Google (Android Performance, 2023), inisialisasi lambat mengurangi Cold Start sebesar 40–60% untuk aplikasi yang menggunakan 5+ SDK.

Baseline Profiles

Baseline Profiles adalah kompilasi AOT dari kelas dan metode kritis yang digunakan saat startup aplikasi. Tanpa Baseline Profiles, ART menginterpretasi kode DEX atau mengompilasinya dengan JIT, yang memakan waktu. Dengan profil, ART mengompilasi metode yang ditentukan ke kode native (AOT) saat instalasi aplikasi. Google menyatakan bahwa Baseline Profiles mempercepat Cold Start sebesar 15–40% pada Android 9+ dan hingga 60% dengan optimasi ART Android 12+. Untuk membuat profil, gunakan plugin androidx.benchmark:benchmark-baseline-profile-gradle-plugin.

App Startup Library

Pustaka androidx.startup memungkinkan pengaturan inisialisasi komponen dan eksekusinya dalam satu ContentProvider. Alih-alih beberapa ContentProvider dari berbagai pustaka (masing-masing menambahkan 1–2 ms ke cold start), App Startup menggabungkannya ke dalam grafik dependensi dan menginisialisasi hanya saat diperlukan. Pada startup, hanya komponen yang ditandai dengan @Initializer dan diperlukan untuk layar pertama yang dijalankan. Untuk sisanya, flag needEarlyInit = false diatur — mereka dimulai setelah rendering pertama.

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

// Di AndroidManifest.xml tandai sebagai opsional
// <meta-data android:name="AnalyticsInitializer"
//     android:value="false" />

Mengurangi ukuran DEX

Ukuran file DEX secara langsung memengaruhi waktu pemuatannya oleh ART. Gunakan R8/ProGuard untuk obfuskasi dan penghapusan kode mati (MinifyEnabled = true). Aktifkan android:extractNativeLibs="false" di manifes agar APK tidak mengekstrak file .so saat instalasi. Untuk proyek dengan lebih dari 10 kelas Reference Tracking, tambahkan startup-priority hanya untuk layar pertama. Setiap metode berlebih di DEX menambahkan 0,5–2 ms ke pemuatan, dan untuk aplikasi dengan 50k+ metode (multidex dengan primary dex) — hingga 300 ms.

Cold Start di Android Vitals

Android Vitals di Google Play Console (bagian Launch time) mengumpulkan data dari semua perangkat tempat aplikasi diinstal, dengan syarat pengguna menyetujui diagnostik anonim. Metrik dibagi menjadi tiga kategori: "good" (baik), "moderate" (sedang), "bad" (buruk), tergantung pada waktu Cold Start.

Nilai ambang Google

Google mendefinisikan Cold Start "bad" sebagai waktu melebihi 5 detik pada perangkat apa pun. Namun dalam praktiknya, untuk perangkat flagship (Snapdragon 8 Gen), waktu yang baik adalah kurang dari 1,5 detik, untuk kelas menengah — kurang dari 2,5 detik, untuk kelas budget — kurang dari 4 detik. Android Vitals menunjukkan median per device model, yang membantu memahami pada perangkat mana aplikasi start lambat. Jika Cold Start buruk pada perangkat Samsung A-series atau Xiaomi Redmi, penyebabnya biasanya memori flash yang lemah dan RAM kecil (percepatan melalui Baseline Profiles memberikan efek terbesar justru pada perangkat semacam itu).

Bagaimana Google Play menggunakan metrik

Selain ditampilkan di konsol, metrik Cold Start memengaruhi penilaian kualitas aplikasi di Google Play Search. Aplikasi dengan persentase tinggi startup "buruk" mendapatkan label "Performance warning" di halaman instalasi, yang menurunkan konversi. Menurut Google (Android Performance Playbook, 2024), aplikasi yang mengatasi masalah Cold Start rata-rata meningkatkan konversi instalasi sebesar 5% dan meningkatkan retensi (D1) sebesar 3–7%.

Integrasi dengan Firebase Performance

Untuk pemantauan yang lebih detail, gunakan Firebase Performance Monitoring. Ini melacak Cold Start di tingkat sesi, memisahkan berdasarkan versi aplikasi dan versi Android. Tidak seperti Android Vitals, Firebase menunjukkan diagram trace waktu yang dihabiskan per fase. Misalnya, dapat dilihat bahwa pada versi 3.2.0, Application.onCreate memakan waktu 800 ms (karena pustaka push-notifikasi baru), dan pada versi 3.2.1 — 200 ms (setelah perbaikan).

Contoh kode untuk optimasi

Di bawah ini adalah dua contoh praktis yang secara langsung mempercepat Cold Start: memindahkan inisialisasi SDK setelah start dan menggunakan SplashScreen API.

Memindahkan inisialisasi dari Application.onCreate

Kesalahan tipikal adalah menginisialisasi semua SDK di Application.onCreate. Di bawah ini ditunjukkan cara memindahkan inisialisasi non-kritis ke coroutine yang dimulai setelah rendering frame pertama. Penting: Firebase, Crashlytics, dan Crash Reporting SDK harus diinisialisasi saat startup — tidak dapat ditunda karena mereka menangkap crash saat inisialisasi komponen lain. Untuk sisanya, gunakan lifecycleScope di Activity pertama.

// ❌ Buruk — semua inisialisasi di Application.onCreate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // kritis
        Analytics.init(this) // bisa nanti
        Database.init(this) // bisa nanti
        ImageLoader.init(this) // bisa nanti
    }
}

// ✅ Baik — Firebase di start, sisanya after inflate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// Di MainActivity setelah frame pertama:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Di Android 12+, gunakan SplashScreen API resmi, yang menampilkan system-splash (ikon aplikasi di latar belakang gelap/terang) segera saat proses dimulai. Ini menyembunyikan waktu inisialisasi dari pengguna — ia melihat splash, bukan layar putih. Untuk perangkat lama, gunakan theme-based splash (Theme.SplashScreen dalam style). Penting: splash tidak boleh berlangsung lebih dari 300 ms — jika aplikasi belum siap dalam waktu itu, gambarkan kerangka "permanen" (shimmer) dan tunjukkan progres pemuatan.

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