Crash dalam Pengembangan Mobile: apa itu, jenis dan metode pencegahan

Apa itu Crash

Crash — adalah penghentian paksa aplikasi yang disebabkan oleh exception yang tidak tertangani atau sinyal sistem fatal yang tidak ditangani dalam kode aplikasi. Ketika sistem atau mesin virtual (JVM, ART) mendeteksi kondisi fatal — NullPointerException, IndexOutOfBoundsException, OutOfMemoryError — ia segera menghentikan proses dan mengeluarkannya dari memori. Pengguna melihat aplikasi tiba-tiba tertutup tanpa pemberitahuan kesalahan sistem apa pun. Menurut Google, aplikasi dengan tingkat crash-free di bawah 99% kehilangan hingga 20% pengguna aktif per bulan.

Di Android mekanisme penanganan crash berbeda dari sistem desktop. Alih-alih dialog debug dengan stack trace, Android langsung mematikan proses dan tidak menyimpan informasi detail. Pengumpulan informasi tentang crash adalah tugas pustaka pihak ketiga (Crashlytics, Sentry, Bugsnag), yang menangkap exception melalui Thread.setDefaultUncaughtExceptionHandler sebelum proses dihentikan.

iOS menggunakan mekanisme serupa dengan NSException dan Mach exceptions untuk menangani kesalahan fatal. Pada exception yang tidak tertangani, sistem menghentikan aplikasi, dan laporan disimpan sebagai file .crash. Pengumpulan crash di iOS memerlukan integrasi dengan Crashlytics atau laporan bawaan melalui Xcode Organizer.

Jenis-jenis utama kegagalan

Lima kategori kegagalan mencakup 90% dari semua crash di aplikasi mobile. Memahami setiap jenis membantu mendiagnosis dan memperbaiki masalah lebih cepat di lingkungan produksi.

NullPointerException — raja kegagalan

NullPointerException (NPE) — jenis crash paling umum di semua aplikasi Java/Kotlin. Terjadi ketika mencoba memanggil metode atau mengakses bidang objek yang bernilai null. Skenario tipikal: bidang Activity yang belum diinisialisasi saat rotasi layar, respons null dari server saat deserialisasi JSON, navigasi yang tidak hati-hati melalui adapter RecyclerView.

Kotlin memecahkan masalah NPE di tingkat bahasa melalui tipe null-safe: String? tidak dapat digunakan tanpa pemeriksaan eksplisit. Namun, kompatibilitas Java dan Reflection masih menciptakan risiko. Gunakan anotasi @NonNull dan @Nullable dan aktifkan strictNullChecks di alat analisis statis.

fun safeLength(text: String?): Int {
    return text?.length ?: 0 // penanganan null yang aman
}

IndexOutOfBoundsException dan kesalahan koleksi

IndexOutOfBoundsException terjadi ketika mengakses indeks yang tidak ada dari daftar atau array. Skenario umum: menghapus elemen dari RecyclerView tanpa sinkronisasi dengan adapter, modifikasi ArrayList multi-thread tanpa penguncian, perhitungan posisi yang salah di ViewPager. ConcurrentModificationException — kerabat dekat saat iterasi dan modifikasi koleksi secara bersamaan.

Gunakan CopyOnWriteArrayList untuk akses multi-thread atau koleksi Lock-free dari java.util.concurrent. Untuk sinkronisasi dengan UI, gunakan DiffUtil, yang menghitung perbedaan antara daftar lama dan baru dengan aman dan efisien.

ClassCastException — masalah tipe

ClassCastException terjadi saat mengonversi objek ke tipe yang tidak kompatibel. Di Android, penyebab tipikal: tipe ViewHolder yang salah di RecyclerView (tipe sel berbeda tanpa getItemViewType yang benar), konversi Fragment yang salah saat navigasi, objek Serializable dengan versi kelas yang berbeda.

Gunakan konversi aman Kotlin melalui operator as?, yang mengembalikan null saat ketidakcocokan tipe. Di Java — pemeriksaan melalui instanceof sebelum konversi. Untuk objek Parcelable, wajib mendeklarasikan CREATOR di setiap kelas.

IllegalStateException dan kesalahan logis

IllegalStateException menandakan pemanggilan metode dalam kondisi objek yang tidak sesuai. Contoh tipikal di Android — getSupportFragmentManager() setelah onSaveInstanceState, ketika commit() fragment tidak diizinkan. Kasus umum lainnya — memanggil dismiss() pada dialog yang sudah ditutup.

Periksa kondisi siklus hidup sebelum operasi dengan FragmentManager. Gunakan commitAllowingStateLoss() hanya ketika Anda yakin kehilangan kondisi tidak kritis. Di Kotlin, buat builder mirip DSL yang mengecualikan kondisi yang salah di tingkat tipe.

Native Crash (sinyal SIGSEGV, SIGABRT)

Native Crash terjadi dalam kode asli C/C++ saat pelanggaran memori: akses melalui pointer null, double-free, stack buffer overflow. Di Android, crash semacam itu terjadi di pustaka NDK, mesin game (Unity, Unreal), dan ketergantungan sistem. Native Crash TIDAK ditangkap oleh Thread.setDefaultUncaughtExceptionHandler — ia mematikan proses seketika.

Untuk diagnosis crash asli, gunakan file minidump (Breakpad) atau tombstone Android. Firebase Crashlytics mendukung pengumpulan crash asli melalui NDK SDK. Di iOS, masalah serupa diselesaikan melalui PLCrashReporter.

Alat pelaporan kegagalan

Tiga alat mendominasi pasar pelaporan crash mobile. Masing-masing menyediakan pengumpulan stack trace, agregasi berdasarkan versi aplikasi, dan pemberitahuan tentang crash baru.

Firebase Crashlytics

Crashlytics — pelapor crash paling populer untuk aplikasi mobile, bagian dari ekosistem Firebase. Ia secara otomatis mengumpulkan stack trace, data perangkat, versi OS, dan kunci kustom pengguna. Integrasi memakan waktu 10 menit melalui Firebase Console dan Gradle Plugin. Crashlytics juga mendukung log nyata (Logcat) dan pelacakan kustom.

FirebaseCrashlytics.getInstance()
    .setCustomKey("current_screen", "ProfileFragment")

FirebaseCrashlytics.getInstance()
    .log("User tapped login button")

Sentry

Sentry — alternatif Crashlytics dengan sistem penyaringan yang lebih fleksibel dan dukungan 90+ platform. Tidak seperti Firebase, Sentry menyediakan server self-hosted untuk perusahaan dengan persyaratan data yang ketat. Sentry mendukung pelacakan distributif, breadcrumbs, dan integrasi dengan pipeline CI/CD.

Bugsnag dan AppCenter

Bugsnag menonjol dengan dukungan peringatan berbasis tingkat keparahan: membagi crash menjadi kritis, kesalahan, dan peringatan. AppCenter dari Microsoft — alat gratis dengan fungsionalitas dasar untuk proyek kecil. Keduanya mendukung Android, iOS, React Native, dan Flutter.

Cara menganalisis kegagalan

Analisis kegagalan adalah proses merekonstruksi gambaran lengkap peristiwa. Stack trace hanya menunjukkan titik kegagalan terakhir, tetapi tidak memberikan konteks yang menyebabkan masalah. Pendekatan profesional mencakup empat tahap.

Tahap pertama — membaca stack trace. Tentukan kelas, metode, dan baris kode tempat exception terjadi. Ikuti rantai panggilan dari bingkai atas ke bawah: baris terakhir di tumpukan adalah lokasi crash, dan baris atas adalah urutan panggilan. Deobfuskasi (pemetaan ProGuard/R8) wajib untuk build produksi.

Tahap kedua — konteks perangkat. Crashlytics menunjukkan model perangkat, versi OS, memori yang tersedia, dan versi aplikasi. Misalnya, crash hanya di Samsung Galaxy S10 dengan Android 11 menunjukkan masalah dengan versi tertentu One UI, bukan kesalahan kode umum.

Tahap ketiga — reproduksi di perangkat uji. Jika crash tidak dapat direproduksi secara stabil, tanyakan langkah-langkah tepat kepada pengguna atau gunakan Remote Config untuk pencatatan sebelum bagian kode yang bermasalah. Pengujian AB perbaikan pada sebagian audiens membantu mengonfirmasi solusi.

Tahap keempat — pemantauan setelah perbaikan. Setelah mempublikasikan perbaikan, amati frekuensi crash selama 3–5 hari. Jika crash benar-benar hilang — perbaikan berhasil. Jika frekuensi menurun tetapi tidak menjadi nol — ada skenario kedua yang memerlukan analisis terpisah.

Praktik pencegahan kegagalan

Pendekatan sistematis untuk pencegahan crash mencakup alat analisis statis, pengujian wajib kasus batas, dan penanganan kesalahan yang tepat di semua tingkat aplikasi.

Analisis kode statis

Detekt (Kotlin) dan Lint (Android) menemukan masalah potensial pada tahap kompilasi: variabel yang tidak digunakan, NPE potensial, penggunaan API yang salah. Aktifkan alat-alat ini di pipeline CI dengan ambang kesalahan. Misalnya, Detekt dengan konfigurasi 30+ peringatan atau error-blocking tidak meloloskan build.

Pengujian unit dan pengujian UI

Cakupan skenario penggunaan utama dengan pengujian unit adalah perlindungan dasar terhadap crash regresif. Uji model data, ViewModel, dan lapisan UseCase dengan kasus batas: nilai null, daftar kosong, JSON tidak valid. Pengujian UI melalui Espresso atau Compose Test mencakup flow kritis: otentikasi, pembayaran, orientasi.

Graceful Degradation

Rancang aplikasi sehingga kegagalan di satu modul tidak menjatuhkan seluruh layar. Gunakan blok catch di tingkat ViewModel dengan mengembalikan status cadangan: menampilkan placeholder alih-alih daftar, data cache saat tidak ada jaringan, gambar cadangan saat kesalahan pemuatan. Ini mengubah potensi crash menjadi skenario UX yang terkendali.

Peluncuran bertahap dengan pemantauan

Staged rollouts — praktik standar Google Play dan App Store: versi baru didistribusikan ke 5%, kemudian 20%, dan akhirnya 100% audiens dengan interval 1–3 hari. Pada setiap tahap, frekuensi crash dipantau: jika tingkat crash-free turun di bawah 99,5%, peluncuran berhenti secara otomatis. Firebase Remote Config memungkinkan menonaktifkan fitur bermasalah tanpa mempublikasikan versi baru.

Kontrol versi ketergantungan

Renovate atau Dependabot di CI secara otomatis memeriksa pustaka untuk kerentanan yang diketahui dan bug kritis. Memperbarui satu ketergantungan dapat menghilangkan seluruh kelas crash. Namun, uji pembaruan di lingkungan staging sebelum peluncuran ke produksi — versi baru pustaka mungkin berisi perubahan yang tidak kompatibel.