ANR di Android: apa itu, penyebab, dan metode perbaikan

Apa itu ANR di Android

ANR (Application Not Responding) — adalah mekanisme perlindungan pengguna di Android yang aktif ketika aplikasi berhenti merespons input. Sistem melacak waktu pemrosesan peristiwa: jika BroadcastReceiver tidak menyelesaikan onReceive dalam 10 detik, Service tidak kembali dari onCreate dalam 20 detik, dan ContentProvider tidak merespons dalam 15 detik — Android menghasilkan ANR.

Bagaimana ANR terlihat bagi pengguna

Ketika ANR terjadi, Android menampilkan dialog sistem di atas semua jendela: "Aplikasi Tidak Merespons. Tutup atau tunggu?". Pengguna dapat menutup aplikasi atau menunggu pemulihannya. Jika ANR sering berulang, pengguna akan menghapus aplikasi. Google Play mempertimbangkan tingkat ANR — persentase sesi dengan ANR — dalam algoritma peringkat.

Perbedaan ANR dengan pembekuan di iOS

Di iOS tidak ada padanan ANR dengan dialog sistem. Sebagai gantinya, Apple menggunakan Watchdog yang menghentikan proses aplikasi dengan kode 0x8badf00d. Pengguna tidak melihat dialog — aplikasi hanya tertutup ke layar utama. Hal ini membuat ANR di Android lebih terlihat oleh pengguna, tetapi memberikan sistem lebih banyak informasi untuk diagnosis.

Penyebab utama ANR

ANR terjadi ketika sistem melacak batas waktu untuk salah satu dari empat jenis komponen. Setiap komponen memiliki batas waktunya sendiri.

Pemblokiran di BroadcastReceiver

BroadcastReceiver dieksekusi di thread utama. Jika onReceive memulai permintaan jaringan sinkron, operasi penulisan panjang ke database, atau menunggu pemblokiran — setelah 10 detik ANR muncul. Solusi: gunakan goAsync() dan WorkManager untuk pemrosesan latar belakang. Skenario tipikal — menerima notifikasi Push dari FCM dan menyimpan sinkron di Room.

Operasi panjang di Service

Service.onCreate dan Service.onStartCommand memiliki batas 20 detik. Jika layanan memulai inisialisasi berat (memuat pustaka, membaca konfigurasi dari jaringan) di thread utama — ANR tidak terhindarkan. Gunakan IntentService (usang) atau WorkManager untuk eksekusi terjamin di thread latar belakang.

ContentProvider dengan inisialisasi panjang

ContentProvider.onCreate dieksekusi sebelum panggilan Application.onCreate dan memiliki batas 15 detik. Jika penyedia melakukan migrasi database, memuat kamus, atau inisialisasi SDK dari jaringan — ini menyebabkan ANR saat memulai aplikasi. Solusi: inisialisasi lazy, memindahkan operasi berat ke WorkManager.

• BroadcastReceiver — 10 detik untuk onReceive; gunakan goAsync() untuk pemrosesan latar belakang
• Service — 20 detik untuk onCreate/onStartCommand; gunakan WorkManager atau CoroutineWorker
• ContentProvider — 15 detik untuk onCreate; pindahkan inisialisasi ke Application.onCreate dengan startup tertunda
• Thread UI — 5 detik tanpa pemrosesan peristiwa; pemblokiran apa pun yang lebih dari 5 detik menyebabkan ANR

Cara mendiagnosis ANR

Android menyediakan beberapa alat untuk analisis ANR: dari log sistem hingga pustaka khusus.

Analisis traces.txt

Pada setiap ANR, Android menyimpan file /data/anr/traces.txt dengan dump tumpukan semua thread aplikasi. Temukan thread "main" — metode terakhir di tumpukan menunjukkan penyebabnya. Pola tipikal: Thread.sleep(), InputStream.read(), BinderProxy.transact(). Untuk mengekstrak file dari perangkat, gunakan adb dengan hak superuser.

Firebase Crashlytics dengan laporan ANR

Firebase Crashlytics secara otomatis mengumpulkan ANR dan menampilkannya di dasbor bersama dengan pelacakan. Untuk Android 11+, laporan ANR datang dengan tumpukan lengkap thread utama. Integrasi memerlukan penambahan dependensi dan inisialisasi FirebaseApp di Application.onCreate.

Android Studio Profiler dengan pelacakan thread

CPU Profiler di Android Studio memungkinkan Anda merekam pelacakan kerja aplikasi dan melihat metode mana yang menghabiskan waktu CPU. Aktifkan "Record with method traces" dan reproduksi skenario yang menyebabkan ANR. Pada garis waktu akan terlihat metode mana yang dieksekusi di thread utama saat pembekuan.

Contoh integrasi Firebase Crashlytics untuk mengumpulkan ANR di Android:

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        FirebaseCrashlytics.getInstance()
            .setCrashlyticsCollectionEnabled(true)
        StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build())
    }
}

Metode perbaikan ANR

Perbaikan ANR terutama berarti memindahkan semua operasi panjang dari thread utama ke thread latar belakang. Mari kita lihat teknik spesifik untuk setiap jenis komponen.

Menggunakan WorkManager untuk tugas latar belakang

WorkManager — solusi yang direkomendasikan Google untuk pekerjaan latar belakang. Ini menjamin eksekusi tugas di thread latar belakang dengan mempertimbangkan status perangkat. Tidak seperti Service, WorkManager tidak memblokir thread utama dan tahan terhadap restart aplikasi. Untuk BroadcastReceiver, gunakan goAsync() dan teruskan hasil PendingResult ke WorkManager.

Kotlin Coroutines dengan dispatcher yang tepat

Jalankan semua permintaan jaringan, pekerjaan database, dan operasi file dengan Dispatchers.IO. Thread utama hanya boleh memperbarui UI. Gunakan viewModelScope untuk pembatalan otomatis coroutine saat Activity dihancurkan. Hindari runBlocking() dalam konteks apa pun — ini adalah pemblokiran sinkron thread saat ini.

Inisialisasi lazy ContentProvider

Jika ContentProvider melakukan inisialisasi panjang, gunakan mekanisme pemuatan tertunda: buat penyedia yang segera mengembalikan data, dan jalankan inisialisasi berat melalui WorkManager dengan penundaan. Ini mencegah ANR saat memulai aplikasi, ketika sistem paling sensitif terhadap penundaan.

Contoh penggunaan BroadcastReceiver yang benar dengan goAsync di Android:

class FcmReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        val pendingResult = goAsync()
        WorkManager.getInstance(context!!)
            .enqueue(OneTimeWorkRequest.from(NotificationWorker::class.java))
        pendingResult.finish()
    }
}

Pencegahan ANR dalam pengembangan

Cara terbaik untuk melawan ANR adalah mencegah kemunculannya di tahap pengembangan melalui alat dan solusi arsitektur.

StrictMode untuk mendeteksi pemblokiran thread utama

StrictMode dengan kebijakan detectNetwork() dan detectDiskReads()/detectDiskWrites() yang diaktifkan mendeteksi potensi ANR di tahap pengembangan. Di build Debug, atur penaltyDeath — setiap pelanggaran akan menyebabkan crash segera, dan pengembang akan melihat masalah sebelum commit.

Firebase Performance Monitoring untuk metrik produksi

Firebase Performance melacak waktu eksekusi operasi kunci dan menunjukkan skenario mana yang melebihi ambang ANR. Konfigurasikan pelacakan kustom untuk setiap layar dan permintaan jaringan. Jika waktu eksekusi melebihi 3 detik — ini adalah potensi ANR yang memerlukan optimasi.

Pengujian dengan penundaan jaringan dan disk

Simulasikan kondisi lambat: batasi kecepatan jaringan melalui Network Link Conditioner di iOS atau Android Emulator. Perlambat pembacaan dari disk melalui emulasi memori lambat. ANR sering muncul tepat dalam kondisi seperti itu, pada perangkat cepat pengembang tidak terlihat.

• BroadcastReceiver — selalu gunakan goAsync() untuk pemrosesan lebih dari 1 detik
• Service — ganti dengan WorkManager atau CoroutineWorker dengan dispatcher latar belakang
• ContentProvider — hindari jaringan dan database di onCreate, gunakan lazy-init dengan WorkManager
• Thread UI — StrictMode dengan penaltyDeath di Debug, Firebase Performance untuk pemantauan produksi