ANR dalam pengembangan Android — apa itu, penyebab dan cara memperbaikinya

Apa itu ANR

ANR (Application Not Responding) — adalah kotak dialog sistem operasi Android yang muncul ketika aplikasi berhenti merespons masukan pengguna. Sistem melacak waktu pemrosesan peristiwa melalui InputDispatcher: jika sentuhan atau penekanan tombol tidak diproses dalam 5 detik, Android menampilkan dialog dengan tawaran untuk menutup atau menunggu aplikasi.

Mekanisme ANR melindungi pengalaman pengguna dari aplikasi yang macet. Android tidak mengizinkan satu aplikasi memblokir seluruh sistem — tidak seperti sistem Desktop, platform seluler secara paksa membatasi waktu pemrosesan peristiwa. BroadcastReceiver memiliki batas 10 detik, dan layanan foreground — 20 detik.

ANR BUKAN pengecualian dalam kode — ini adalah mekanisme sistem di tingkat proses Linux. Android mengirim sinyal SIGQUIT ke proses, setelah itu sistem menyimpan tumpukan panggilan semua thread ke file traces.txt. Pengembang menerima ANR bukan sebagai pengecualian catch, melainkan sebagai laporan setelah restart aplikasi. Di Android 11+ muncul API ApplicationExitInfo yang memungkinkan mendapatkan penyebab penghentian proses secara terprogram, termasuk ANR — ini menyederhanakan pengumpulan statistik tanpa parsing manual traces.txt.

Penyebab utama ANR

Lima kategori operasi secara stabil menyebabkan ANR di aplikasi Android. Masing-masing memblokir thread utama, mencegah sistem memproses peristiwa input dan menggambar ulang layar.

Permintaan jaringan di thread utama

Permintaan HTTP sinkron yang dijalankan di thread UI — penyebab ANR paling umum pada pengembang pemula. Bahkan permintaan cepat ke server dapat memakan waktu 1–3 detik, dan dengan koneksi lemah — 30 detik atau lebih. Android secara eksplisit melarang operasi jaringan di thread utama sejak API 11, dengan melemparkan NetworkOnMainThreadException.

Gunakan Coroutines atau RxJava untuk panggilan asinkron. Coroutine dengan dispatcher Dispatchers.IO menjalankan permintaan di thread latar belakang, dan hasilnya dikirim ke thread utama melalui Dispatchers.Main. Ini sepenuhnya menghilangkan pemblokiran thread UI oleh operasi jaringan.

fun fetchUserData() {
    CoroutineScope(Dispatchers.Main).launch {
        val result = withContext(Dispatchers.IO) {
            api.getUserData() // operasi latar belakang
        }
        updateUI(result) // hasil di thread utama
    }
}

Perhitungan intensif di thread UI

Pemrosesan array data besar, parsing JSON atau XML, bekerja langsung dengan bitmap di thread utama — penyebab ANR kedua paling umum. Bahkan 300 milidetik kerja terus-menerus thread UI tanpa kembali ke loop peristiwa menyebabkan keterlambatan rendering yang nyata, dan nilai batas 5 detik dicatat sebagai ANR.

WorkManager dan layanan latar belakang dirancang untuk memindahkan perhitungan berat dari thread utama. Gunakan AsyncTask (usang), ListenableFuture atau Kotlin Flow untuk mengirim data dalam bagian, tanpa memblokir UI.

Pemblokiran sinkronisasi dan Deadlock

Deadlock terjadi ketika dua thread memegang kunci dan saling menunggu. Jika salah satu thread adalah utama, sistem mencatat ANR tepat setelah 5 detik. Thread.join(), CountDownLatch.await() dan blok synchronized yang dipanggil dari thread UI membawa risiko pemblokiran.

Hindari semua operasi pemblokiran di thread utama. Gunakan ConcurrentHashMap sebagai pengganti synchronized, coroutine dengan async/await sebagai pengganti Thread.join(). Aturan ini berlaku untuk semua bahasa di Android: Java, Kotlin atau C++ melalui JNI.

Pekerjaan panjang BroadcastReceiver

BroadcastReceiver secara default dijalankan di thread utama. Jika onReceive() sibuk lebih dari 10 detik, Android menampilkan ANR. Memuat data dari database atau jaringan di dalam onReceive adalah jalan pasti menuju kemacetan.

Gunakan goAsync() di dalam BroadcastReceiver untuk beralih ke thread latar belakang, atau registerReceiver dengan getBackgroundBroadcastReceiver(). Ini memungkinkan pemrosesan peristiwa tanpa memblokir UI.

ContentProvider dan SQLite di thread utama

Kueri berat ke ContentProvider atau bekerja langsung dengan SQLite di thread UI — penyebab ANR yang kurang jelas namun sering terjadi. Saat migrasi database atau penyisipan massal ribuan catatan, waktu eksekusi dapat melebihi batas 5 detik.

Pindahkan semua operasi database ke thread latar belakang melalui Room dengan fungsi suspend. Room secara otomatis memeriksa bahwa kueri tidak dijalankan di thread utama dan melemparkan pengecualian jika dilanggar.

Cara mendiagnosis ANR

Diagnosis ANR berbeda dari debugging pengecualian biasa — Anda tidak dapat menangkap ANR di try-catch. Sumber informasi utama adalah file traces.txt yang dibuat Android saat kemacetan terjadi.

traces.txt berisi tumpukan panggilan semua thread aplikasi pada saat ANR. Untuk membaca file dari perangkat nyata, jalankan perintah adb bugreport yang mengumpulkan laporan sistem lengkap, termasuk semua ANR baru-baru ini. Untuk emulator, file tersedia di /data/anr/traces.txt. Tumpukan panggilan menunjukkan metode mana yang dijalankan di thread utama pada saat pemblokiran.

adb bugreport bugreport.zip
unzip -p bugreport.zip "*traces*" > traces.txt

Google Play Console menyediakan bagian ANR & Crash dengan laporan agregat dan frekuensi kesalahan. Untuk setiap ANR ditampilkan tumpukan panggilan dan statistik per perangkat: model, versi Android, wilayah. Ini memungkinkan identifikasi ANR yang bergantung pada perangkat atau versi sistem tertentu.

Android Studio sejak 2021 berisi ANR Watchdog di profiler. Secara otomatis merekam dump thread jika thread utama tidak merespons lebih dari waktu ambang. Alat ini menunjukkan linimasa peristiwa: operasi apa yang dimulai, metode apa yang dijalankan, dan pada tahap mana pemblokiran terjadi.

Cara mencegah ANR

Pencegahan ANR didasarkan pada satu aturan fundamental: thread utama hanya boleh memproses peristiwa UI. Operasi apa pun yang berlangsung lebih dari 16 milidetik (waktu satu frame) harus dijalankan di thread latar belakang.

StrictMode — pemeriksaan otomatis

StrictMode — alat bawaan Android untuk mendeteksi potensi ANR pada tahap pengembangan. Aktifkan di Application.onCreate() dengan flag untuk operasi disk dan jaringan. Saat dilanggar, StrictMode melemparkan pengecualian atau menulis ke logcat.

if (BuildConfig.DEBUG) {
    StrictMode.ThreadPolicy.Builder()
        .detectDiskReads()
        .detectDiskWrites()
        .detectNetwork()
        .penaltyLog()
        .build()
        .let { StrictMode.setThreadPolicy(it) }
}

Pola asinkron: Coroutines dan RxJava

Kotlin Coroutines — cara standar kerja asinkron di aplikasi Android modern. Prinsip dasar: operasi input-output dijalankan di Dispatchers.IO, hasilnya dikirim ke Dispatchers.Main untuk pembaruan UI. Untuk skenario Flow, gunakan Dispatchers.Default untuk tugas intensif CPU.

RxJava tetap populer di proyek lama. subscribeOn(Schedulers.io()) dan observeOn(AndroidSchedulers.mainThread()) — set minimal untuk pencegahan ANR. Aturan yang sama: tidak ada Observable atau Flowable yang boleh mengeluarkan data dari thread utama.

Monitoring di produksi

Firebase Crashlytics sejak versi SDK 18.4.0 mendukung monitoring ANR langsung jadi. Untuk Android 11+ Crashlytics menggunakan API sistem ApplicationExitInfo yang memberikan penyebab pasti penghentian: ANR, Crash, atau dibunuh oleh sistem. Aktifkan kunci kustom dengan parameter layar dan status untuk analisis kontekstual.

Alat deteksi ANR

Lima alat mencakup semua tahap kerja dengan ANR: dari debugging di stasiun kerja hingga monitoring di produksi. Setiap alat menyelesaikan tugasnya dan menyediakan data untuk berbagai skenario.

Setiap alat memiliki ceruknya sendiri: StrictMode menangkap pelanggaran jelas di tahap awal, Crashlytics menunjukkan frekuensi nyata ANR pada pengguna, dan adb bugreport memberikan gambaran paling lengkap untuk kasus kompleks. Gabungkan mereka untuk cakupan penuh.

Firebase Performance Monitoring

Firebase Performance melacak waktu respons thread UI dan secara otomatis membuat jejak untuk operasi yang mencurigakan panjangnya. Jika thread utama diblokir lebih dari 500 md, Performance mencatat jejak kustom dengan nama metode penyebab. Ini memungkinkan deteksi skenario ANR tanpa partisipasi pengguna dan sebelum menjadi kritis.

Integrasi dengan Firebase Crashlytics memberikan gambaran lengkap: Performance menunjukkan perlambatan sebelum ANR, dan Crashlytics — fakta kemacetan itu sendiri. Konfigurasikan peringatan di Firebase Console untuk peristiwa ANR rate di atas 0,1% dan Anda akan menerima pemberitahuan tentang masalah baru sebelum keluhan massal pengguna.