Hot Start di Aplikasi Seluler: Apa Itu, Faktor dan Cara Mempercepat

Apa itu Hot Start di Aplikasi Seluler

Hot Start — adalah skenario peluncuran aplikasi di mana prosesnya sudah ada di memori RAM perangkat. Pengguna meminimalkan aplikasi, kemudian kembali — dan sistem tidak membuat proses baru, melainkan melanjutkan proses yang sudah ada. Dalam skenario ini, memuat OS, inisialisasi kelas Application dan pembuatan proses tidak diperlukan, yang secara drastis mengurangi waktu hingga UI muncul di layar. Menurut Android Documentation (2025), Hot Start hanya memakan waktu 200–500 ms, sedangkan Cold Start bisa mencapai 5 detik atau lebih. Perbedaan kecepatan terutama terlihat pada perangkat dengan memori terbatas, di mana sistem lebih sering membongkar aplikasi latar belakang.

Fitur utama Hot Start — set minimum metode lifecycle yang dipanggil. Di Android ini adalah Activity.onCreate dan Activity.onStart, di iOS — applicationDidBecomeActive. Berbeda dengan Cold Start, di mana Application.onCreate, ContentProvider.onCreate, Activity.onCreate dan banyak inisialisasi pustaka dipanggil secara berurutan, Hot Start melewati semua tahap ini. Pengembang harus memahami kode mana yang dieksekusi tepat saat mulai panas — seringkali inisialisasi berat SDK, analitik, dan container DI diulangi baik di Cold maupun Hot Start, meskipun saat mulai panas tidak lagi diperlukan.

Cold Start, Warm Start dan Hot Start: Perbandingan

Tiga skenario peluncuran aplikasi berbeda dalam kedalaman inisialisasi. Cold Start (mulai dingin) terjadi ketika aplikasi diluncurkan pertama kali setelah instalasi, restart perangkat atau pembongkaran dari memori. Sistem membuat proses Linux baru, memuat kelas Application, membuat instance ContentProvider, melakukan inisialisasi pustaka dan baru kemudian menampilkan Activity. Seluruh proses memakan waktu 2–10 detik tergantung pada kompleksitas aplikasi dan karakteristik perangkat.

Warm Start (mulai hangat) — skenario perantara. Proses aplikasi hidup di memori, tetapi Activity telah dihancurkan dan harus dibuat ulang. Ini terjadi, misalnya, saat rotasi layar atau saat kembali dari aplikasi lain, ketika Activity dibongkar karena kekurangan memori, tetapi prosesnya tetap ada. Warm Start mencakup pemanggilan Activity.onCreate dan Activity.onStart, tetapi tidak termasuk Application.onCreate dan inisialisasi ContentProvider. Waktu Warm Start — dari 500 ms hingga 2 detik. Hot Start — yang tercepat dari ketiganya: Activity sudah ada di back stack, proses hidup, dan sistem hanya memanggil Activity.onRestart, onStart dan onResume. Waktu Hot Start — 200–500 ms. Perbedaan dari Warm Start adalah bahwa Activity tidak dibuat dari awal — ia dipulihkan dari instance yang sudah ada.

Android Lifecycle saat Hot Start

Di Android Hot Start dimulai ketika pengguna kembali ke aplikasi melalui layar Recents atau dengan mengklik ikon dalam keadaan diminimalkan. Sistem memeriksa apakah proses hidup, dan jika ya — memanggil secara berurutan Activity.onRestart, onStart dan onResume. Metode onCreate tidak dipanggil saat Hot Start, karena instance Activity sudah ada di memori. Ini adalah perbedaan penting dari Warm Start, di mana onCreate tetap dipanggil karena penghancuran Activity. Menurut Google I/O 2019, waktu tipikal Hot Start di Android adalah 200–400 ms, dan setiap perlambatan pada tahap ini secara langsung meningkatkan perceived launch time.

Pengembang sering tidak menyadari bahwa kode inisialisasi UI, langganan LiveData atau konfigurasi RecyclerView dieksekusi tidak hanya di onCreate, tetapi juga di onStart atau onResume. Saat Hot Start, blok kode ini dieksekusi lagi, meskipun UI sudah dikonfigurasi. Disarankan untuk memisahkan inisialisasi satu kali (di onCreate dengan pemeriksaan savedInstanceState) dan logika yang dapat dilanjutkan (onStart/onResume). Misalnya, operasi berat — konfigurasi adaptor, memuat daftar — sebaiknya dipindahkan ke blok yang tidak dieksekusi saat onRestart, atau periksa savedInstanceState.

Contoh Pelacakan Tipe Peluncuran

Kode berikut di Kotlin mendemonstrasikan cara sederhana untuk menentukan skenario start dan mengukur waktu. Variabel launchTimeStamp mencatat momen awal peluncuran, dan isColdStart memungkinkan pemisahan logika untuk start dingin dan panas.

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // inisialisasi satu kali
        } else {
            isColdStart = false
            // Hot Start — Activity dipulihkan
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start: $launchTime ms")
        }
    }
}

iOS Lifecycle saat Mulai Panas

Di iOS Hot Start sesuai dengan kembalinya aplikasi dari latar belakang melalui sceneDidBecomeActive (UIKit) atau onAppear (SwiftUI). Sistem operasi tidak membuat ulang proses jika aplikasi berada dalam status Suspended atau Background. Saat mulai panas, applicationDidBecomeActive dipanggil di AppDelegate, tetapi applicationDidFinishLaunching tidak dipanggil — ini adalah analogi Android, di mana Application.onCreate dilewati. iOS membongkar aplikasi dari memori lebih agresif: jika perangkat kekurangan RAM, sistem dapat membongkar aplikasi latar belakang, dan peluncuran berikutnya akan menjadi Cold Start. Menurut Apple Developer Documentation, rata-rata waktu Hot Start di iOS adalah 300–600 ms.

Perbedaan utama iOS — tidak adanya analog langsung Warm Start dalam pengertian Android. Di iOS saat meminimalkan aplikasi, sceneDidEnterBackground dipanggil, dan saat kembali — sceneWillEnterForeground dan sceneDidBecomeActive. Jika sistem membongkar scene tetapi membiarkan proses tetap hidup, peluncuran berikutnya akan menjadi Cold dari sudut pandang scene, tetapi Hot dari sudut pandang proses. Pengembang harus mempertimbangkan ini saat menempatkan kode inisialisasi: langganan ke NotificationCenter, pembaruan UI dan pengaturan ulang status harus tepat di sceneDidBecomeActive, bukan hanya di viewDidLoad.

Contoh Penanganan Hot Start di iOS

Kode di Swift ini menunjukkan cara melacak jumlah mulai panas dan memisahkan logika. Penghitung foregroundCount bertambah setiap kali kembali dari latar belakang.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — inisialisasi penuh
            setupSDKs()
        } else {
            // Hot Start — hanya pembaruan UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // pembaruan data di layar
    }
}

Faktor yang Memengaruhi Kecepatan Hot Start

Kecepatan Hot Start dipengaruhi oleh beberapa kategori faktor. Pertama — jumlah pekerjaan di metode lifecycle onStart dan onResume. Jika pengembang menempatkan di metode ini pemuatan data dari jaringan, parsing JSON, inisialisasi adaptor atau perhitungan berat, setiap blok tersebut menambahkan puluhan dan ratusan milidetik ke waktu mulai. Menurut data alat Android Vitals, aplikasi dengan durasi Hot Start lebih dari 800 ms kehilangan hingga 20% pengguna saat kembali lagi.

Kategori kedua — fragmen dan View yang dipulihkan dari savedInstanceState. Jika fragmen berisi ViewPager2 berat, WebView atau hierarki kompleks dengan sarang dalam, pemulihannya menghabiskan sumber daya CPU. Menurut Google I/O 2023, setiap ViewGroup bersarang menambahkan rata-rata 2–5 ms ke waktu rendering saat Hot Start. Kategori ketiga — SDK pihak ketiga: pustaka analitik, crash-reporting, A/B-testing dan pemuat DEX dapat melakukan inisialisasi setiap kali kembali dari latar belakang. Disarankan untuk memeriksa SDK mana yang menjalankan kode tepat di onStart/onResume, dan menunda tugas yang tidak kritis ke thread latar belakang.

Metode Optimasi Mulai Panas

Optimasi Hot Start bermuara pada meminimalkan pekerjaan di metode lifecycle kelanjutan. Metode pertama — inisialisasi malas: semua kode yang tidak diperlukan untuk bingkai UI pertama harus dieksekusi setelah pemanggilan onResume dengan penundaan melalui Handler.postDelayed atau Coroutine.launch(Dispatchers.IO). Metode kedua — caching status View: saat meminimalkan aplikasi, simpan data di cache in-memory, sehingga saat Hot Start tidak perlu memuat ulang dari database atau jaringan. Metode ketiga — menggunakan SavedStateHandle di Android dan StateRestorationPolicy di iOS untuk meminimalkan jumlah data yang dipulihkan.

Pemuatan Malas setelah Hot Start

Dalam contoh ini Handler.postDelayed menunda inisialisasi analitik selama 500 ms setelah rendering bingkai pertama. Ini tidak memengaruhi perceived launch time, karena pengguna sudah melihat antarmuka.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // inisialisasi setelah bingkai pertama
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Menggunakan Pustaka App Startup

AndroidX App Startup memungkinkan pengelolaan urutan inisialisasi komponen saat mulai. Semua ContentProvider diinisialisasi secara otomatis saat Cold Start, tetapi Anda dapat menonaktifkan inisialisasi otomatis untuk komponen yang tidak diperlukan saat Hot Start.

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

Alat Pemantauan Waktu Peluncuran

Untuk mengukur waktu Hot Start ada baik alat bawaan platform maupun solusi pihak ketiga. Di Android alat kuncinya adalah Android Vitals di Google Play Console — secara otomatis mengumpulkan metrik waktu peluncuran untuk semua skenario (Cold, Warm, Hot) dengan perincian berdasarkan model perangkat dan versi OS. Selain itu, dapat digunakan Macrobenchmark dari AndroidX — pustaka untuk pengujian kinerja mulai otomatis. Di iOS, padanannya adalah MetricKit, yang mengumpulkan data tentang waktu peluncuran, frekuensi bingkai, dan penggunaan memori.

Untuk profil mendetail mulai panas, Firebase Performance Monitoring (melacak custom traces) dan New Relic dengan dasbor waktu peluncuran cocok. Di sisi pengembang untuk pengukuran manual digunakan reportFullyDrawn di Android — API yang memberi tahu sistem saat tepat ketika UI telah dirender dan siap untuk interaksi. Di iOS padanannya adalah endActivity di MetricKit. Dengan menggabungkan alat-alat ini, Anda dapat mengidentifikasi SDK atau blok kode mana yang memperlambat Hot Start tepat di perangkat tertentu.

Contoh Macrobenchmark untuk Hot Start

Kode di Kotlin menggunakan pustaka Macrobenchmark untuk mengukur Cold dan Hot Start. Tes menjalankan Activity dan mengukur waktu hingga status complete.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}