Warm Start: esensi, start hangat dan optimasi di Android

Apa itu Warm Start

Warm Start (start hangat) adalah kondisi antara Cold Start dan Hot Start: proses aplikasi ada di memori (terkadang di cache latar belakang Linux), tetapi Activity tidak aktif dan akan dibuat ulang. Sistem Android saat kekurangan RAM dapat membongkar Activity dari tumpukan, membiarkan proses tetap hidup. Saat pengguna kembali ke aplikasi, Warm Start dimulai: instance Activity baru dibuat, metode siklus hidup onCreate → onStart → onResume dijalankan, tetapi Application.onCreate dan pemuatan kelas dilewati.

Penyebab Warm Start

Sistem Android membuat keputusan tentang pembongkaran Activity berdasarkan prioritas proses (importance rank). Activity di latar belakang (tingkat PROCESS_STATE_IMPORTANT_FOREGROUND atau PROCESS_STATE_TOP_SLEEPING) dapat dihancurkan 5–30 menit setelah aplikasi diminimalkan, tergantung pada RAM yang tersedia. Pada perangkat dengan RAM 3 GB, Activity dapat dibongkar setelah 10 menit, pada perangkat dengan 8 GB — setelah beberapa jam. Penting: saat Warm Start onSaveInstanceState dipanggil sebelum penghancuran Activity dan pengembang dapat menyimpan status UI.

Persepsi pengguna

Pengguna tidak melihat perbedaan antara Warm dan Cold Start — dia hanya menekan ikon aplikasi dan menunggu. Namun pada Warm Start, layar putih (blank window) dapat muncul jika aplikasi belum mengatur tema sendiri untuk jendela start. Google merekomendasikan untuk mengatur tema kustom di manifest (Theme.AppCompat.Light atau Theme.Material3.DayNight) untuk Activity start guna menghindari kedipan layar putih/hitam saat Warm Start. Di Android 12+, SplashScreen API juga menyembunyikan efek ini.

Warm Start vs Cold Start vs Hot Start

Memahami perbedaan antara ketiga jenis start diperlukan untuk memilih strategi profiling dan optimasi yang tepat. Setiap jenis memiliki durasi, hambatan, dan alat pengukuran sendiri.

Dalam praktiknya, Warm Start mencakup 30% hingga 60% dari semua start aplikasi, tergantung pada kebiasaan pengguna dan jumlah RAM perangkat. Pengguna yang membuka banyak aplikasi (multitasker) lebih sering mengalami Warm Start. Untuk jejaring sosial dan messenger, Warm Start adalah skenario paling umum karena aplikasi selalu di latar belakang. Untuk aplikasi bank, sebaliknya, Cold Start dominan (pembersihan proses paksa karena alasan keamanan).

Fase start hangat

Warm Start terdiri dari tiga fase, masing-masing dapat diukur dan dioptimalkan. Tidak seperti Cold Start, di sini tidak ada fase fork dan pemuatan kelas, tetapi ada fase pemulihan status (restore) yang bisa mahal.

Fase 1: Jendela start (window background)

Sistem memeriksa apakah aplikasi memiliki tema untuk jendela start. Jika tema tidak diatur, layar putih (atau hitam, tergantung sistem) ditampilkan. Jika tema diatur, background dari tema ditampilkan. Fase ini memakan waktu 10–30 ms, tetapi terasa secara visual jika tema tidak sesuai dengan UI asli aplikasi. Gunakan Theme.Material3.DayNight dengan windowBackground kustom yang warnanya cocok dengan latar belakang layar pertama — ini menciptakan efek pemuatan instan.

Fase 2: Pembuatan Activity (pemulihan)

Sistem memanggil onCreate dengan mengirimkan Bundle savedInstanceState yang disimpan di onSaveInstanceState sebelum penghancuran Activity. Jika aplikasi menyimpan status dengan benar (teks bidang, posisi scroll, data ViewModel), pemulihan terjadi dengan cepat. Jika tidak — Activity dimulai dari halaman kosong dan pengguna melihat loader sampai data dimuat. Poin kunci: objek ViewModel bertahan dari Warm Start hanya jika proses tidak dihancurkan — saat Warm Start ViewModel tetap di memori.

Fase 3: Bingkai pertama (TTFD)

Setelah onCreate, onStart → onResume dijalankan dan sistem memanggil render pertama. TTFD (Time To First Draw) untuk Warm Start harus kurang dari 300 ms pada perangkat menengah. Jika layar pertama berisi RecyclerView kompleks dengan View berat atau memuat gambar melalui jaringan, TTFD dapat melebihi ambang batas. Gunakan Placeholder dan Shimmer untuk pemuatan konten yang mulus setelah bingkai pertama.

Cara mengukur Warm Start

Mengukur Warm Start lebih rumit daripada Cold Start karena Anda perlu mensimulasikan status «proses hidup, Activity dihancurkan». Perintah ADB standar dengan bendera -S tidak cocok — ia mematikan proses. Untuk Warm Start gunakan pendekatan lain.

ADB shell am start tanpa -S

Pertama jalankan aplikasi melalui adb shell monkey atau ketuk ikon, lalu minimalkan (adb shell input keyevent 3 keyevent HOME). Tunggu 5–10 detik agar sistem dapat membongkar Activity dan jalankan adb shell am start -W (tanpa -S). Perintah akan mengembalikan waktu start yang akan lebih pendek dari Cold Start. Untuk reprodusibilitas gunakan skrip: jalankan → tunggu → home → tunggu → jalankan.

# Simulasi Warm Start melalui ADB
$ adb shell am start -W \
    com.example.app/.MainActivity

# Keluaran (Warm Start):
# ThisTime: 412 ms
# TotalTime: 412 ms
# WaitTime: 423 ms

Macrobenchmark untuk Warm Start

Pustaka androidx.benchmark.macro mendukung pengukuran Warm Start. Untuk ini dalam tes atur startupMode = StartupMode.WARM — pustaka akan menjalankan aplikasi, meminimalkannya, menunggu (penundaan yang dapat dikonfigurasi), lalu mengukur start ulang. Macrobenchmark melakukan 10–20 kali jalan dan menghitung persentil. Di CI/CD Anda dapat mengatur ambang batas: jika P50 Warm Start melebihi 600 ms — tes gagal. Ini memungkinkan pelacakan regresi di setiap commit.

Firebase Performance Monitoring

Firebase secara otomatis membedakan Cold dan Warm Start berdasarkan waktu sejak penutupan aplikasi sebelumnya. Jika aplikasi telah dibuka dalam 30 menit terakhir, Firebase mengklasifikasikan start sebagai Warm. Di konsol Firebase Anda akan melihat grafik terpisah untuk setiap jenis start, memungkinkan evaluasi efektivitas optimasi. Misalnya, setelah menerapkan penyimpanan status di ViewModel, Anda dapat melihat penurunan Warm Start hingga 30%.

Optimasi Warm Start

Optimasi Warm Start berfokus pada dua arah: mempercepat Activity.onCreate dan pemulihan status yang benar. Karena Application.onCreate dan pemuatan kelas sudah dilakukan, hambatan utama adalah kode UI layar pertama.

Pemulihan status asinkron

Jika status yang disimpan (savedInstanceState) berisi data yang perlu dideserialisasi (Bitmap, String, JSON), lakukan ini di utas latar belakang. Alih-alih membaca langsung dari Bundle di onCreate, jalankan coroutine dan tampilkan layar shimmer. Dalam praktiknya, deserialisasi Bundle pada perangkat menengah memakan waktu 20–100 ms — terlihat sedikit, tetapi untuk Warm Start ini 10–50% dari total waktu. Gunakan Saved State Module dari pustaka Jetpack yang secara otomatis menyimpan dan memulihkan status ViewModel di Bundle atau database.

Optimasi setContentView

Pengembangan tata letak XML (layout inflation) — salah satu tahap termahal Warm Start. Jika layar pertama menggunakan CoordinatorLayout kompleks dengan AppBar, CollapsingToolbar, NestedScrollView ditambah tiga RecyclerView, waktu inflation bisa mencapai 300 ms. Solusi: gunakan ConstraintLayout untuk hierarki datar, terapkan ViewStub untuk bagian yang tidak terlihat saat start (bottom sheet, dialog), aktifkan pengembangan asinkron untuk fragmen berat melalui AsyncLayoutInflater. Di Jetpack Compose inflation tidak diperlukan, tetapi kompilasi pohon Compose pada Warm Start dapat memakan waktu serupa.

Caching data

Saat Warm Start, data yang dimuat aplikasi di sesi sebelumnya mungkin sudah ada di cache: database Room, SharedPreferences, cache in-memory di ViewModel. Jika layar pertama Anda menampilkan daftar dari server, periksa cache saat start dan perbarui data di latar belakang. Gunakan strategi cache-then-network: pertama tampilkan data yang di-cache (instan), lalu perbarui dari server (asinkron). Ini mengurangi waktu yang dirasakan Warm Start menjadi 100–200 ms.

// ViewModel dengan caching untuk Warm Start
class FeedViewModel : ViewModel() {
    private val cache = MutableStateFlow<List<Item>>(emptyList())

    init {
        // Cache dulu, lalu jaringan
        viewModelScope.launch {
            cache.emit(db.getItems()) // Warm Start: data sudah di database
            cache.emit(api.fetchItems()) // Pembaruan latar belakang
        }
    }
}

Mempertahankan status saat Warm Start

Penyimpanan status yang benar adalah faktor kunci yang membedakan Warm Start yang baik dari yang buruk. Pengguna berharap kembali ke aplikasi dan melihat hal yang sama seperti yang ditinggalkan — termasuk posisi scroll, teks di bidang, tab yang dipilih.

onSaveInstanceState

Sistem memanggil onSaveInstanceState saat penghancuran Activity, tetapi SEBELUM proses dapat dimatikan. Di Bundle hanya data sederhana yang disimpan (String, Int, Parcelable, Serializable). Untuk data kompleks gunakan SavedStateHandle di ViewModel — secara otomatis menyimpan dan memulihkan bidang saat Warm Start. Tidak seperti onSaveInstanceState, SavedStateHandle bekerja bahkan jika proses selamat dari Warm Start (ViewModel tidak dihancurkan). Contoh: untuk teks di EditText gunakan SavedStateHandle.getLiveData(“text”) — teks akan disimpan dan dipulihkan secara otomatis.

ViewModel dan Warm Start

Jika saat Warm Start proses tidak dimatikan, ViewModel tetap di memori dan onCleared tidak dipanggil. Ini berarti semua data yang dimuat di sesi sebelumnya tersedia secara instan. Namun jika proses dimatikan (perangkat dalam deep sleep lebih dari 30 menit), ViewModel dihancurkan dan dibuat ulang dengan SavedStateHandle. Untuk kerja ViewModel yang benar saat Warm Start gunakan SavedStateHandle dengan bidang yang perlu dipulihkan dalam skenario apa pun. Perbedaan: ViewModel dengan @HiltViewModel mendukung SavedStateHandle secara otomatis.

Mempertahankan scroll RecyclerView

Salah satu masalah paling umum Warm Start — kehilangan posisi scroll. Pengguna menggulir feed ke elemen ke-50, meminimalkan aplikasi, kembali — dan melihat awal daftar. Solusi: simpan layoutManager.onSaveInstanceState (menyimpan posisi dan offset elemen pertama yang terlihat) dan pulihkan di onRestoreInstanceState. Juga dapat menyimpan posisi terakhir yang terlihat di SharedPreferences dengan kunci tanggal/waktu untuk memulihkan posisi dengan cepat saat Warm Start.

// Mempertahankan posisi scroll RecyclerView
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putParcelable(
        "rv_state", binding.recyclerView
            .layoutManager?.onSaveInstanceState()
    )
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    savedInstanceState?.getParcelable<Parcelable>("rv_state")
        ?.let { binding.recyclerView.layoutManager?.onRestoreInstanceState(it) }
}

Contoh kode untuk Warm Start

Dua contoh praktis optimasi Warm Start: penggunaan SavedStateHandle di ViewModel dan pemulihan asinkron data kompleks setelah start.

ViewModel dengan SavedStateHandle

SavedStateHandle secara otomatis menyimpan bidang di Bundle dan memulihkannya saat Warm Start. Bidang profil pengguna (String, JSON) akan dipulihkan tanpa permintaan tambahan ke server. Jika proses dimatikan, SavedStateHandle akan memuat status terakhir yang disimpan dari Bundle.

class ProfileViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    val profile: StateFlow<Profile?>
        get() = savedStateHandle
            .getStateFlow("profile", null)

    fun loadProfile(id: String) {
        viewModelScope.launch {
            savedStateHandle["profile"] =
                api.getProfile(id)
        }
    }
}

// Warm Start: profile tidak null, UI tanpa loader
// Setelah dimuat: profile diperbarui di SavedStateHandle

AsyncLayoutInflater untuk layar berat

Jika layar pertama berisi tata letak kompleks (peta, gradien, beberapa daftar), gunakan AsyncLayoutInflater untuk mengembangkan elemen berat di latar belakang. Sementara tata letak dikembangkan, tampilkan placeholder dengan efek shimmer. Ini sangat penting untuk Warm Start, di mana setiap milidetik berharga. AsyncLayoutInflater bekerja di utas latar belakang dan mengirimkan View yang sudah jadi melalui callback ke utas utama.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Tata letak placeholder untuk rendering instan
        setContentView(R.layout.placeholder_shimmer)

        // Pemuatan asinkron tata letak berat
        AsyncLayoutInflater(this).inflate(
            R.layout.activity_main_complex,
            findViewById(R.id.container)
        ) { view, resId, parent ->
            parent?.removeAllViews()
            parent?.addView(view)
        }
    }
}