Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Şekil 1. Kullanıcıya bir ANR iletişim kutusu gösteriliyor.
Bu dokümanda, Android sisteminin bir uygulamanın yanıt verip vermediğini nasıl belirlediği ve uygulamanızı nasıl duyarlı tutacağı gösterilmektedir.
Kodunuz ne kadar iyi yazılmış olursa olsun uygulamanız yavaşlayabilir, takılabilir, uzun süre donabilir veya girişi işlemesi uzun sürebilir. Uygulamanız ön plandaysa ve yanıt vermiyorsa kullanıcı, Şekil 1'de gösterildiği gibi Yanıt Vermiyor (ANR) iletişim kutusunu görür. ANR iletişim kutusu, kullanıcının uygulamayı çıkmaya zorlamasına olanak tanır. Uygulama ön planda değilse sessizce durdurulur. ANR iletişim kutularını en aza indirmek için uygulamanızın duyarlılığını tasarlamak çok önemlidir.
ANR tetikleyicileri
Genel olarak bir uygulama, ana iş parçacığındaki (UI iş parçacığı olarak da bilinir) kullanıcı girişine yanıt veremediğinde sistem bir ANR gösterir. Bu durum, sistemin gelen kullanıcı girişi etkinliklerini işlemesini engeller.
Örneğin, bir uygulama, kullanıcı arayüzü iş parçacığında ağ erişimi gibi engelleyici bir G/Ç işlemi gerçekleştirirse ANR meydana gelebilir. Başka bir örnek de bir uygulamanın ayrıntılı bir bellek içi yapı oluşturmak veya oyundaki bir sonraki hamleyi kullanıcı arayüzü iş parçacığında hesaplamak için çok fazla zaman harcamasıdır.
Android'de uygulama duyarlılığı ActivityManager ve WindowManager sistem hizmetleri tarafından izlenir. Android, aşağıdaki koşullardan birini algıladığında uygulama için ANR iletişim kutusunu görüntüler:
Tuşa basma veya ekrana dokunma etkinlikleri gibi giriş etkinliklerine 5 saniye içinde yanıt verilmemelidir.
Aşağıda ANR'lerden kaçınmaya yönelik genel ipuçları verilmiştir. Farklı ANR türlerini teşhis etme ve hata ayıklama hakkında daha fazla
bilgi için bu bölümdeki diğer sayfalara bakın.
Ana iş parçacığının engelini her zaman açık tutun ve ileti dizilerini stratejik olarak kullanın.
Uygulamanın ana iş parçacığında engelleme veya uzun süreli işlemler gerçekleştirmeyin.
Bunun yerine, bir çalışan iş parçacığı oluşturun ve işin çoğunu burada yapın.
Ana iş parçacığı ile diğer iş parçacıkları arasındaki kilit anlaşmazlığını en aza indirmeye çalışın.
Ana iş parçacığında, yayınları işleme veya hizmetleri çalıştırma gibi kullanıcı arayüzüyle ilgili olmayan tüm işlemleri en aza indirin. Kullanıcı arayüzü iş parçacığında çalışan herhangi bir yöntem, söz konusu iş parçacığında mümkün olduğunca az çalışma yapmalıdır. Özellikle onCreate() ve onResume() gibi temel yaşam döngüsü yöntemlerini ayarlamak için aktivitelerin mümkün olduğunca az çalışması gerekir. Bir arka plan iş parçacığı üzerinde çalışmayı planlama ve kullanıcı arayüzüyle iletişim kurma konusunda mevcut çözümler hakkında daha fazla bilgi edinmek için Arka planda çalışmaya genel bakış bölümüne bakın.
İş parçacığı havuzlarını bileşenler arasında paylaşırken dikkatli olun. Aynı iş parçacıklarını, uzun engelleyebilecek işlemler ve yayın alma gibi zaman açısından hassas görevler için kullanmayın.
Uygulama hızlı başlatılır. Uygulamanın başlangıç kodunda, hançerin ilk kullanıma hazırlanması sırasında çalıştırılan yöntemler gibi yavaş veya engelleyici işlemleri en aza indirin.
BroadcastReceiver kullanıyorsanız yayın alıcılarını Context.registerReceiver kullanarak ana olmayan bir iş parçacığında çalıştırmayı düşünebilirsiniz. Daha fazla bilgi için BroadcastReceiver'da ANR'ler başlıklı makaleyi inceleyin.
Yayın alıcıları arka planda bir ayarı kaydetme veya Notification kaydettirme gibi küçük miktarlarda iş yapmak üzere olduğundan BroadcastReceiver yürütme süresi kısıtlıdır. Bu nedenle, kullanıcı arayüzü iş parçacığında çağrılan diğer yöntemlerde olduğu gibi, uygulamalar bir yayın alıcısında uzun süreli olabilecek işlemlerden veya hesaplamalardan kaçınmalıdır. Kullanıcı arayüzü iş parçacığı aracılığıyla uzun süreli görevleri gerçekleştirmek yerine, bu görevleri daha sonra yürütmek üzere arka planda gerçekleştirin. Olası çözümler hakkında daha fazla bilgi için Arka planda çalışmaya genel bakış bölümüne bakın.
BroadcastReceiver nesneleriyle ilgili diğer bir yaygın sorun, nesneleri çok sık çalıştıklarında ortaya çıkar. Arka planda sık yürütme işlemi, diğer uygulamaların kullanabileceği bellek miktarını azaltabilir. BroadcastReceiver nesnelerini etkili bir şekilde etkinleştirme ve devre dışı bırakma hakkında daha fazla bilgi için Yayınlara genel bakış konusuna bakın.
Duyarlılığı güçlendirin
Genellikle 100-200 ms., kullanıcıların bir uygulamadaki yavaşlığı algıladığı eşiktir. Aşağıda, uygulamanızın kullanıcılara duyarlı görünmesini sağlayacak ek ipuçları verilmiştir:
Uygulamanız kullanıcı girişine yanıt olarak arka planda çalışıyorsa ilerlemenin devam ettiğini gösterin (örneğin, kullanıcı arayüzünüze ProgressBar ile).
Özellikle oyunlarda, çalışan iş parçacığındaki hareket hesaplamaları yapın.
Uygulamanızın ilk kurulum aşaması çok zaman alıyorsa bir başlangıç ekranı göstermeyi veya ana görünümü mümkün olduğunca hızlı oluşturmayı düşünün.
Yüklemenin devam ettiğini belirtin ve bilgileri eşzamansız olarak doldurun.
Her iki durumda da, kullanıcının uygulamanın donduğunu algılamaması için bir şekilde ilerleme kaydedildiğini belirtmenizi öneririz.
Uygulamanızın yanıt verme hızındaki performans sorunlarını belirlemek için Perfetto ve CPU Profiler gibi performans araçlarını kullanın.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
