Crash aplikasi: apa itu, penyebab gagal dan metode deteksi

Apa itu crash aplikasi

Crash — penghentian tak terduga program yang disebabkan oleh situasi luar biasa yang tidak ditangani oleh kode. Di OS mobile, crash menyebabkan penutupan instan aplikasi dan menampilkan layar “Aplikasi berhenti” atau kembali ke layar beranda.

Crash terbagi menjadi dua kelas besar. Error yang ditangani — blok try/catch menangkap pengecualian, aplikasi tetap berjalan, mungkin dengan hilangnya fungsionalitas. Crash yang tidak ditangani — pengecualian naik ke level OS dan sistem mematikan proses. Tipe kedua sangat berbahaya karena pengguna tidak dapat menyimpan data.

Sistem dengan dua juta pengguna dan crash rate 0,1% kehilangan 2.000 pengguna di setiap rilis. Menurut Google Play Console (2024), aplikasi dengan crash rate di atas 1,5% dikeluarkan dari rekomendasi dan kehilangan hingga 30% traffic organik.

Penyebab utama crash di aplikasi mobile

NullPointerException (NPE) — raja crash di Java/Kotlin. Mencoba memanggil metode pada objek null. Di Kotlin, NPE lebih jarang terjadi berkat null safety, tetapi masih mungkin saat menggunakan operator !! atau berinteraksi dengan kode Java. memperkirakan: NPE merupakan 25% dari semua crash aplikasi Android.

IndexOutOfBoundsException — mengakses elemen daftar dengan indeks yang tidak ada. Penyebab umum: data datang dari server dalam format tak terduga dan UI mencoba menampilkan posisi yang tidak ada. Solusi — selalu periksa ukuran koleksi sebelum mengakses melalui indeks.

ANR (Application Not Responding) — masalah spesifik Android. Thread UI diblokir lebih dari 5 detik. Penyebab utama: permintaan jaringan di thread utama, komputasi berat, sinkronisasi dengan database. StrictMode di Android membantu mendeteksi pemblokiran thread UI di tahap pengembangan.

OutOfMemoryError (OOM) — aplikasi melebihi batas memori. Di perangkat mobile dengan RAM 2–4 GB, OOM adalah masalah umum saat bekerja dengan gambar besar atau daftar tak terbatas tanpa paginasi. Solusi — Glide/Coil untuk memuat gambar, LruCache untuk caching, ViewHolder di RecyclerView.

Runtime exceptions dan error fatal

Runtime exceptions — error yang tidak diperiksa kompiler saat pembangunan. Mereka hanya muncul saat mengeksekusi kode di perangkat tertentu dengan data tertentu. Di Java, ini adalah RuntimeException dan subkelasnya: NullPointerException, IllegalArgumentException, ArithmeticException.

Error fatal (FATAL) — bukan runtime, melainkan kegagalan sistem. Signal 11 (SIGSEGV) — pelanggaran segmentasi memori di kode native. Signal 6 (SIGABRT) — penghentian darurat yang disebabkan oleh aplikasi itu sendiri melalui abort(). Crash semacam itu sulit didiagnosis karena stack trace sering tidak menunjukkan konteks yang dapat dipahami.

Di iOS, penyebab utamanya adalah NSInvalidArgumentException (nil tak terduga dalam parameter) dan EXC_BAD_ACCESS (akses ke memori yang dibebaskan). Swift mengurangi jumlah crash dibandingkan Objective-C, tetapi error di runtime ObjC dan pustaka C masih menyebabkan kegagalan.

Monitoring dan pengumpulan log crash

Firebase Crashlytics — standar untuk aplikasi mobile. Secara otomatis mengumpulkan stack trace, menambahkan log, ID pengguna, dan metadata perangkat. Mengelompokkan crash berdasarkan tanda tangan (kelas error + baris). Real-time alerts — pemberitahuan ketika crash rate melebihi ambang batas yang ditentukan (mis. >0,1% per jam).

Sentry — alternatif dengan kemampuan yang lebih fleksibel. Memungkinkan pembuatan custom contexts, penambahan breadcrumbs, konfigurasi in-app filtering untuk mengecualikan error yang tidak penting. Source maps untuk Kotlin dan Swift memungkinkan melihat kode sumber, bukan nama yang diobfusasi.

Best practices untuk log: kirim metadata penting sebelum menjalankan operasi berbahaya. Tambahkan custom keys (nomor versi API, layar terakhir, ukuran data masukan). Ini mengubah stack trace yang tidak berguna menjadi informasi yang dapat ditindaklanjuti.

Contoh: mengatur Crashlytics di Android

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

undefined

Optional binding dan null safety — di Kotlin gunakan `?` untuk tipe nullable, `let` dan `?:` untuk penanganan null yang aman. Di Swift — optionals dan guard let. Modern Kotlin (2024) menambahkan anotasi Contract: @ContractsDsl memungkinkan mendeklarasikan bahwa fungsi tidak mengembalikan null, dan kompiler memeriksanya.

Error handling di jaringan — setiap permintaan jaringan harus menangani timeout, error parsing, dan penolakan server. Retrofit dengan tipe Result — sealed class yang menjamin bahwa error akan ditangani. Gaya No Exception: alih-alih try/catch, gunakan sealed Result untuk penanganan sukses dan error secara eksplisit.

Feature flags — nonaktifkan fungsionalitas bermasalah dari jarak jauh tanpa merilis versi baru. Firebase Remote Config memungkinkan mengubah perilaku aplikasi tanpa publikasi di toko.

Peluncuran bertahap — rilis versi baru untuk 5% audiens dan pantau crash rate. Jika rate tetap di bawah target (biasanya <0,1%), perluas ke 25%, lalu 50%, lalu 100%. Google Play Console dan App Store Connect mendukung peluncuran bertahap untuk penghentian otomatis saat melebihi ambang batas.

Rencana tindakan saat menemukan error

1: Klasifikasi — tentukan tingkat keparahan: Critical (crash pada >1% pengguna), High (0,1–1%), Medium (<0,1%). Untuk Critical crash — respons segera. Google Play Console secara otomatis mengklasifikasikan crash berdasarkan jumlah pengguna yang terkena dampak.

2: Analisis stack trace — buka log di Crashlytics, lihat lokasi pasti kegagalan. Periksa custom keys: layar apa, data apa, versi OS. Bandingkan dengan penerapan terakhir — seringkali crash disebabkan oleh perubahan baru dalam kode yang memengaruhi skenario penggunaan tak terduga.

3: Reproduksi — coba reproduksi crash di perangkat atau emulator dengan parameter serupa. Jika tidak berhasil, periksa log crash untuk pola: model tertentu (Samsung A10), versi Android (API < 26), locale. Solusi — tambahkan kondisi protektif yang mencakup skenario.

4: Perbaikan dan monitoring — rilis hotfix dengan prioritas. Setelah rilis, pastikan crash rate untuk tipe ini turun ke nol. Tulis tes regresi yang mencakup skenario crash. Tanpa tes, bug yang sama dapat kembali pada refactoring berikutnya.