Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Gambar 1. Dialog ANR yang ditampilkan kepada pengguna.
Dokumen ini menjelaskan cara sistem Android mengetahui bahwa aplikasi tidak
merespons dan menunjukkan cara menjaga aplikasi Anda tetap responsif.
Terlepas dari seberapa baik kode Anda ditulis, aplikasi masih mungkin akan
terasa lambat, hang, berhenti selama jangka waktu yang signifikan, atau memakan waktu terlalu lama untuk memproses
input. Jika aplikasi berada di latar depan dan tidak responsif, pengguna akan melihat
dialog Aplikasi Tidak Merespons (ANR), seperti dalam gambar 1. Dialog ANR
memungkinkan pengguna memaksa keluar aplikasi. Jika tidak berada di latar depan, aplikasi akan
dihentikan secara diam-diam. Sangat penting untuk mendesain daya respons ke dalam aplikasi Anda guna
meminimalkan dialog ANR.
Pemicu ANR
Umumnya, sistem menampilkan ANR jika aplikasi tidak dapat merespons input pengguna di
thread utama—juga dikenal sebagai UI thread—sehingga mencegah sistem
memproses peristiwa input pengguna yang masuk.
Misalnya, ANR dapat terjadi jika aplikasi menjalankan operasi I/O pemblokir, seperti
akses jaringan, di UI thread. Contoh lain adalah saat aplikasi menghabiskan terlalu
banyak waktu untuk membangun struktur dalam memori yang rumit atau menghitung langkah berikutnya
dalam game di UI thread.
Di Android, daya respons aplikasi dipantau oleh layanan sistem ActivityManager dan
WindowManager. Android menampilkan dialog ANR untuk aplikasi
saat mendeteksi salah satu kondisi berikut:
Tidak ada respons terhadap peristiwa input—misalnya, peristiwa sentuh layar atau tombol—dalam 5
detik.
Berikut adalah tips umum untuk menghindari ANR. Untuk detail selengkapnya tentang cara mendiagnosis
dan men-debug berbagai jenis ANR, lihat halaman lain di bagian ini.
Pastikan thread utama selalu tidak diblokir, dan gunakan thread secara strategis.
Jangan menjalankan operasi pemblokir atau yang berjalan lama di thread utama aplikasi.
Sebagai gantinya, buat thread pekerja dan lakukan sebagian besar pekerjaan di sana.
Cobalah untuk meminimalkan pertentangan kunci antara thread utama dan thread
lainnya.
Minimalkan pekerjaan yang tidak terkait dengan UI di thread utama, misalnya, saat menangani
siaran atau menjalankan layanan. Setiap metode yang berjalan di UI thread harus
melakukan pekerjaan sesedikit mungkin di thread tersebut. Secara khusus, aktivitas harus
diminimalkan untuk menyiapkan metode siklus proses utama seperti
onCreate() dan onResume(). Lihat Ringkasan pekerjaan latar belakang untuk
informasi selengkapnya tentang solusi yang tersedia guna menjadwalkan pekerjaan di thread
latar belakang dan berkomunikasi kembali dengan UI.
Berhati-hatilah saat membagikan kumpulan thread antarkomponen. Jangan gunakan thread yang
sama untuk operasi yang berpotensi memblokir dalam waktu lama dan tugas yang mendesak,
seperti penerimaan siaran.
Pastikan agar startup aplikasi cepat. Minimalkan operasi lambat atau pemblokir dalam kode startup
aplikasi, misalnya, metode yang dijalankan selama inisialisasi dagger.
Jika Anda menggunakan BroadcastReceiver, pertimbangkan untuk menjalankan penerima siaran di
thread non-utama menggunakan Context.registerReceiver. Untuk mengetahui informasi selengkapnya,
lihat ANR di BroadcastReceiver.
Waktu eksekusi BroadcastReceiver dibatasi karena penerima siaran
ditujukan untuk melakukan pekerjaan kecil dan terpisah di latar belakang, seperti
menyimpan setelan atau mendaftarkan Notification. Jadi, sebagaimana metode
lain yang dipanggil di UI thread, aplikasi harus menghindari operasi atau penghitungan
yang dapat berjalan lama di penerima siaran. Alih-alih melakukan
tugas yang berjalan lama melalui UI thread, jalankan tugas di latar belakang untuk
dieksekusi nanti. Lihat Ringkasan pekerjaan latar belakang untuk mengetahui informasi selengkapnya tentang kemungkinan solusi.
Masalah umum lainnya dengan objek BroadcastReceiver terjadi jika objek tersebut terlalu
sering dijalankan. Eksekusi latar belakang yang sering dapat mengurangi jumlah memori
yang tersedia untuk aplikasi lain. Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan dan menonaktifkan
objek BroadcastReceiver secara efisien, lihat Ringkasan siaran.
Memperkuat daya respons
Umumnya, 100 hingga 200 md adalah batas yang akan membuat pengguna merasakan kelambatan di
aplikasi. Berikut adalah tips tambahan untuk membuat aplikasi Anda tampak responsif bagi pengguna:
Jika aplikasi melakukan operasi di latar belakang sebagai respons terhadap input pengguna, tunjukkan
bahwa progres sedang berlangsung, seperti dengan ProgressBar di UI Anda.
Khususnya untuk game, lakukan penghitungan untuk gerakan dalam thread pekerja.
Jika aplikasi Anda memiliki fase penyiapan awal yang memakan waktu, pertimbangkan untuk menampilkan
layar pembuka atau merender tampilan utama secepat mungkin.
Tunjukkan bahwa pemuatan sedang berlangsung dan isi informasinya secara asinkron.
Dalam kedua kasus tersebut, sebaiknya tunjukkan apakah progres sedang berlangsung,
sehingga pengguna tidak merasa bahwa aplikasi berhenti.
Gunakan alat performa seperti Perfetto dan CPU Profiler untuk
menentukan bottleneck dalam daya respons aplikasi Anda.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-27 UTC."],[],[],null,["# Keep your app responsive\n\n**Figure 1.** An ANR dialog displayed to the user.\n\nThis document describes how the Android system determines whether an app isn't\nresponding and shows how to keep your app responsive.\n\nNo matter how well-written your code is, it's possible for your app to still\nfeel sluggish, hang, freeze for significant periods, or take too long to process\ninput. If your app is in the foreground and is unresponsive, the user gets an\nApplication Not Responding (ANR) dialog, as shown in figure 1. The ANR dialog\nlets the user force quit the app. If the app isn't in the foreground, then it's\nsilently stopped. It's critical to design responsiveness into your app to\nminimize ANR dialogs.\n\nANR triggers\n------------\n\nGenerally, the system displays an ANR if an app can't respond to user input on\nthe main thread---also known as the UI thread---preventing the system from\nprocessing incoming user input events.\n\nFor example, an ANR can occur if an app performs a blocking I/O operation, such\nas network access, on the UI thread. Another example is when an app spends too\nmuch time building an elaborate in-memory structure or computing the next move\nin a game on the UI thread.\n\nIn Android, app responsiveness is monitored by the [`ActivityManager`](/reference/android/app/ActivityManager) and\n[`WindowManager`](/reference/android/view/WindowManager) system services. Android displays the ANR dialog for an app\nwhen it detects one of the following conditions:\n\n- No response to an input event---such as key press or screen tap events---within 5 seconds.\n- A [`BroadcastReceiver`](/reference/android/content/BroadcastReceiver) doesn't finish executing within 10 to 20 seconds, for foreground intents. For more information, see [Broadcast receiver timeout](/topic/performance/anrs/diagnose-and-fix-anrs#broadcast-receiver-anr).\n\nAvoid ANRs\n----------\n\nThe following are general tips to avoid ANRs. For more details about diagnosing\nand debugging different types of ANRs, see the other pages in this section.\n\n- Keep the main thread unblocked at all times, and use threads strategically.\n\n - Don't perform blocking or long-running operations on the app's main thread.\n Instead, create a worker thread and do most of the work there.\n\n - Try to minimize any lock contention between the main thread and other\n threads.\n\n - Minimize any non-UI related work on the main thread, such as when handling\n broadcasts or running services. Any method that runs in the UI thread must\n do as little work as possible on that thread. In particular, activities must\n do as little as possible to set up in key lifecycle methods, such as\n `onCreate()` and `onResume()`. See [Background work overview](/guide/background) for more\n information about available solutions for scheduling work on a background\n thread and communicating back with the UI.\n\n - Be careful when sharing thread pools between components. Don't use the same\n threads for potentially long-blocking operations and time-sensitive tasks\n such as broadcast receiving.\n\n | **Note:** Because such threading usually is accomplished at the class level, you can think of responsiveness as a class problem. Compare this with basic code performance, which is a method-level concern.\n- Keep app startup fast. Minimize slow or blocking operations in the app's\n startup code, such as methods run during dagger initialization.\n\n- If you're using `BroadcastReceiver`, consider running broadcast receivers in a\n non-main thread using [`Context.registerReceiver`](/reference/android/content/Context#registerReceiver(android.content.BroadcastReceiver,%20android.content.IntentFilter,%20java.lang.String,%20android.os.Handler,%20int)). For more information,\n see [ANRs in BroadcastReceiver](#anrs-in-broadcast-receiver).\n\n - If you use [`goAsync()`](/reference/android/content/BroadcastReceiver#goAsync()), make sure [`PendingResult.finish`](/reference/kotlin/android/content/BroadcastReceiver.PendingResult?#finish) is called quickly before the ANR timeout.\n\nANRs in BroadcastReceiver\n-------------------------\n\n`BroadcastReceiver` execution time is constrained because broadcast receivers\nare meant to do small, discrete amounts of work in the background, such as\nsaving a setting or registering a [`Notification`](/reference/android/app/Notification). So, as with other\nmethods called in the UI thread, apps must avoid potentially long-running\noperations or calculations in a broadcast receiver. Instead of performing\nlong-running tasks via the UI thread, perform them in the background for later\nexecution. See [Background work overview](/guide/background) for more information about possible\nsolutions.\n\nAnother common issue with `BroadcastReceiver` objects occurs when they execute\ntoo frequently. Frequent background execution can reduce the amount of memory\navailable to other apps. For more information about how to enable and disable\n`BroadcastReceiver` objects efficiently, see [Broadcasts overview](/guide/components/broadcasts).\n| **Tip:** You can use [`StrictMode`](/reference/android/os/StrictMode) to help find potentially lengthy operations such as network or database operations that you might accidentally be doing on your main thread.\n\nReinforce responsiveness\n------------------------\n\nGenerally, 100 to 200ms is the threshold beyond which users perceive slowness in\nan app. Here are additional tips for making your app seem responsive to users:\n\n- If your app is doing work in the background in response to user input, show\n that progress is being made, such as with a [`ProgressBar`](/reference/android/widget/ProgressBar) in your UI.\n\n- For games specifically, do calculations for moves in a worker thread.\n\n- If your app has a time-consuming initial setup phase, consider showing a\n [splash screen](/develop/ui/views/launch/splash-screen) or rendering the main view as quickly as possible.\n Indicate that loading is in progress and fill the information asynchronously.\n In either case, we recommend indicating somehow that progress is being made,\n so that the user doesn't perceive that the app is frozen.\n\n- Use performance tools such as [Perfetto](/topic/performance/tracing) and [CPU Profiler](/studio/profile/cpu-profiler) to\n determine bottlenecks in your app's responsiveness."]]
