ANR'leri teşhis etme ve düzeltme

Bir Android uygulamasının kullanıcı arayüzü iş parçacığı çok uzun süre engellendiğinde sistem, "Uygulama Yanıt Vermiyor" mesajı (ANR) hatası. Bu sayfada farklı ANR türleri, bunların nasıl teşhis edileceği ve düzeltilmesine yönelik öneriler. Tüm Listelenen varsayılan zaman aşımı süresi aralıkları AOSP ve Pixel cihazlar içindir; bu zamanlar farklılık gösterebilir.

ANR'lerin nedenini belirlerken, en iyi sonuçları almak için sistem ve uygulama sorunlarını ayırt edebilme.

Sistem kötü durumda olduğunda aşağıdaki sorunlar ANR'lere neden olabilir:

• Sistem sunucusundaki geçici sorunlar genellikle hızlı bağlayıcı çağrılarının yavaşlar.
• Sistem sunucusu ve yüksek cihaz yükü ile ilgili sorunlar, uygulama ileti dizilerinin için iyi bir fırsattır.

Kullanabiliyorsanız sistem ve uygulama sorunlarını ayırt etmenin iyi bir yolu Perfetto izlerini kullanmak için:

• İleti dizisi durumuna bakarak uygulamanın ana iş parçacığının planlanıp planlanmadığını kontrol edin nasıl çalıştığını görmek için Perfetto'da takip edin.
• Kilit anlaşmazlığı gibi sorunlar için system_server ileti dizilerine bakın.
• Yavaş bağlayıcı aramaları için varsa bunun nedenini görmek için yanıt ileti dizisine (varsa) bakın yavaşlar.

Giriş gönderme zaman aşımı

Giriş dağıtım ANR'leri, uygulamanın ana iş parçacığı bir girişe yanıt vermediğinde ortaya çıkar kaydırma veya tuşa basma gibi işlemleri zamanında hatırlatın. Uygulama ön planda olduğu için giriş dağıtım zaman aşımları gerçekleştiğinde, bu durumlar kullanıcı tarafından neredeyse her zaman görülebilir büyük önem taşır.

Varsayılan zaman aşımı süresi: 5 saniye.

Giriş gönderme ANR'leri genellikle ana iş parçacığındaki sorunlardan kaynaklanır. Temel kilit alınması beklenirken iş parçacığı engellendiyse, tutucu iş parçacığı da dahil edilir.

Giriş sevkıyat ANR'lerini önlemek için aşağıdaki en iyi uygulamaları uygulayın:

• Ana iş parçacığında engelleme veya uzun süreli işlemler gerçekleştirmeyin. Dikkatlice yanlışlıkla yakalamak için StrictMode kullanılıyor etkinliği görebilirsiniz.
• Ana iş parçacığı ile diğer iş parçacıkları arasındaki kilit anlaşmazlığını en aza indirin.
• Ana iş parçacığında, kullanıcı arayüzü harici işleri en aza indirin (ör. yayınları veya çalışır.

Yaygın nedenler

Giriş gönderme ANR'leriyle ilgili bazı yaygın nedenleri ve önerilen düzeltmeleri burada bulabilirsiniz.

Neden	Ne olur?	Önerilen düzeltmeler
Bağlayıcı çağrısı yavaş	Ana iş parçacığı uzun bir eşzamanlı bağlayıcı çağrısı yapıyor.	Aşağıdaki durumlarda görüşmeyi ana ileti dizisinden taşıyın veya görüşmeyi optimize etmeye çalışın: sahip olmalısınız.
Birbirini izleyen çok sayıda bağlayıcı çağrısı	Ana iş parçacığı art arda birçok eşzamanlı bağlayıcı çağrısı yapar.	Bağlayıcı çağrılarını sıkı bir döngü içinde gerçekleştirmeyin.
G/Ç engelleme	Ana iş parçacığı, veritabanı veya ağ gibi engelleme G/Ç çağrısını yapıyor erişim.	Tüm engelleme KS'lerini ana ileti dizisinden taşıyın.
Kilit anlaşmazlığı	Kilit alınmasını bekleyen ana iş parçacığı engellendi.	Ana iş parçacığı ile diğer iş parçacığı arasındaki kilit anlaşmazlığını azaltın. Diğer iş parçacığındaki yavaş kodu optimize edin.
Pahalı kare	Tek bir karede çok fazla oluşturma işlemi, ciddi sorunlara neden oluyor.	Çerçeveyi oluşturmakla daha az iş yapın. n^2 algoritması kullanmayın. Tekliflerinizi otomatikleştirmek ve optimize etmek için kaydırma veya sayfalama gibi şeyler için verimli bileşenler (örneğin, Jetpack Çağrı kitaplığı.
Başka bir bileşen tarafından engellendi	Yayın alıcı gibi farklı bir bileşen çalışıyor ve ana ileti dizisi engelleniyor.	Kullanıcı arayüzüyle ilgili olmayan işleri mümkün olduğunca ana ileti dizisinden çıkarın. Yayını çalıştır alıcı sayısı daha fazladır.
GPU askıya alma	GPU'nun askıya alınması, oluşturma işleminin engellenmesine neden olur ve bu nedenle ANR'ye bir giriş gönderilir.	Maalesef uygulama tarafında genellikle herhangi bir düzeltme yoktur. Eğer mümkün değilse sorunu gidermek için donanım ekibiyle iletişime geçin.

Hata ayıklama

Google Play'deki ANR kümesi imzasına bakarak hata ayıklamaya başlayın Console veya Firebase Crashlytics. Küme genellikle en üstteki çerçeveleri kullanabilirsiniz.

Not: "nativePollOnce" yazan giriş gönderme ANR kümelerini yoksayın veya "ana ileti dizisi boşta." Bunlar genellikle yığın dökümünün alındığı ANR'lere karşılık gelir çok geç. Genellikle işlem yapılamaz bu nedenle göz ardı edilebilir. Genel olarak, diğer kümelerde de gerçek ANR sorunları yaşanacağından, gerçek sorunlar gizleniyor. Daha fazla bilgi için nativePollBefore'a göz atın.

Aşağıdaki akış grafiğinde, giriş zaman aşımının nedeninin nasıl belirleneceği gösterilmektedir ANR'yi gönderin.

Şekil 1. Giriş gönderme ANR'sinde hata ayıklama

Play vitals, bu yaygın ANR nedenlerinden bazılarını algılayıp hata ayıklamaya yardımcı olabilir. Örneğin, Örneğin, vitals'ın kilit anlaşmazlığı nedeniyle bir ANR ANR Analizler bölümünde sorunu ve önerilen düzeltmeyi özetleyebilirsiniz.

Şekil 2. Play vitals ANR algılama.

Odaklanılmış pencere yok

Dokunma gibi etkinlikler, isabete dayalı olarak doğrudan ilgili pencereye gönderilir. anahtarlar gibi etkinlikler için bir hedef gerekir. Bu hedefe odaklanmış pencere gibi görünür. Her ekranda yalnızca tek bir odaklanmış pencere vardır ve bu genellikle kullanıcının o anda etkileşimde bulunduğu pencere. Odaklanılmış bir pencere bulunamıyorsa giriş, odaksız pencere ANR'si başlatır. Odaklanmamış pencere ANR'si bir tür giriş gönderme ANR'sidir.

Varsayılan zaman aşımı süresi: 5 saniye.

Yaygın nedenler

Odaklı olmayan pencere ANR'leri genellikle aşağıdaki sorunlardan kaynaklanır:

• Uygulama çok fazla iş yapıyor ve ilk kareyi çizemeyecek kadar yavaş.
• Ana pencereye odaklanılamıyor. Bir pencere FLAG_NOT_FOCUSABLE ise kullanıcı bu cihaza önemli veya düğme etkinlikleri gönderemez.

Kotlin

override fun onCreate(savedInstanceState: Bundle) {
  super.onCreate(savedInstanceState)
  setContentView(R.layout.activity_main)
  window.addFlags(WindowManager.LayoutParams.FLAG_FLAG_NOT_FOCUSABLE)
}

Java

@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.activity_main);
  getWindow().addFlags(WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE);
}

Yayın alıcı zaman aşımı

Yayın alıcı ANR, yayın alıcısının işlem sırasında zamanında yayınlamalısınız. Eşzamanlı alıcılar veya çağrı yapmayan alıcılar için goAsync(), zaman aşımı onReceive() işleminin tamamlanmadığı anlamına gelir gerekir. Eş zamansız alıcılar veya goAsync() çağrısı yapan alıcılar için zaman aşımı PendingResult.finish() zamanında aranmamış.

Yayın alıcı ANR'leri genellikle şu ileti dizilerinde gerçekleşir:

• Ana iş parçacığı (sorun, uygulamanın yavaş başlatılmasıyla ilgiliyse).
• İş parçacığı yayın alıcısını çalıştırıyorsa sorun yavaşsa onReceive() kodu.
• Çalışan iş parçacıklarını (sorun yavaşsa goAsync() yayın kodu) yayınlayın.

Yayın alıcı ANR'lerini önlemek için aşağıdaki en iyi uygulamaları izleyin:

• Uygulama başlatılmasının hızlı olduğundan emin olun. Çünkü bu işlem, aşağıdaki durumlarda ANR zaman aşımında sayılır Uygulama, yayını işlemeye başlar.
• goAsync() kullanılıyorsa PendingResult.finish() öğesinin hızlı bir şekilde çağrıldığından emin olun. Bu, eşzamanlı yayın alıcılarıyla aynı ANR zaman aşımına tabidir.
• goAsync() kullanılıyorsa çalışan ileti dizilerinin ile paylaşılmadığından emin olun diğer uzun süreli veya engelleme işlemleri.
• Şurada yayın alıcılarını çalıştırmak için registerReceiver() kullanabilirsiniz: ana iş parçacığında çalışan kullanıcı arayüzü kodunun çalışmasını engellememek için ana olmayan iş parçacığı.

Zaman aşımı süreleri

Yayın alma zaman aşımı süreleri, ön plan intent işaretinin ve platform sürümü belirlenir.

Niyet türü	Android 13 ve önceki sürümler	Android 14 ve sonraki sürümler
Ön plan önceliği amacı (FLAG_RECEIVER_FOREGROUND) ayar)	10 saniye	İşlemde CPU eksikliği olup olmadığına bağlı olarak 10-20 saniye
Arka planda öncelik amacı (FLAG_RECEIVER_FOREGROUND ayarlanmadı)	60 saniye	İşlemde CPU eksikliği olup olmadığına bağlı olarak 60-120 saniye

FLAG_RECEIVER_FOREGROUND işaretinin ayarlanıp ayarlanmadığını anlamak için "flg=" ifadesini arayın. ANR konusu ve 0x10000000 olup olmadığını kontrol edin. Bu bit ayarlanmışsa niyet FLAG_RECEIVER_FOREGROUND olarak ayarlanmış olduğundan zaman aşımı süresi daha kısadır.

Kısa yayın zaman aşımı (10-20 saniye) olan örnek ANR konusu:

Broadcast of Intent { act=android.inent.action.SCREEN_ON flg=0x50200010 }

Uzun yayın zaman aşımına (60-120 saniye) sahip örnek ANR konusu:

Broadcast of Intent { act=android.intent.action.TIME_SET flg=0x25200010 }

Yayın süreleri nasıl ölçülür?

Yayın süresi ölçümü, yayın Uygulamaya system_server ekler ve uygulama, yayınla. Uygulama işlemi çalışmıyorsa bir haber aktarması da gerekir. ANR zaman aşımı süresi içinde başlatılmalıdır. Bu nedenle, yavaş uygulama başlatma, yayın alıcı ANR'leri devreye girer.

Aşağıdaki şekilde, yayın alıcı ANR zaman çizelgesinin belirli uygulama işlemleri.

Şekil 3. Yayın alıcı ANR zaman çizelgesi.

ANR zaman aşımı ölçümü, alıcı yayın: tam olarak ne zaman gerçekleşeceği, içeriğin eşzamanlı mı yoksa asenkron alıcı)

• Eşzamanlı alıcılarda onReceive() geri döndüğünde ölçüm durur.
• Eşzamansız alıcılar için ölçüm, PendingResult.finish() çağrıldı.

ziyaret edin.

4. Şekil. Eşzamanlı için ANR zaman aşımı ölçümü uç noktaları ve eşzamansız alıcılar.

Yaygın nedenler

Yayın alıcı ANR'leriyle ilgili bazı yaygın nedenleri ve önerilen düzeltmeleri aşağıda bulabilirsiniz.

Neden	Geçerlilik kapsamı:	Ne oldu?	Önerilen düzeltme
Yavaş uygulama başlatma	Tüm alıcılar	Uygulamanın baştan başlatması çok uzun sürdü.	Yavaş uygulama başlatma işlemini optimize edin.
onReceive() planlanmadı	Tüm alıcılar	Yayın alıcı iş parçacığı başka bir işle meşguldü ve çalıştırılamadı onReceive() yöntemini başlatın.	Gerçekleştirme alıcı iş parçacığında uzun süreli görevler (veya alıcıyı özel ileti dizisinde gösterilir).
onReceive() yavaş	Çoğunlukla olmak üzere tüm alıcılar eşzamanlı olanlar	onReceive() yöntemi başlatıldı, ancak engellenmiş veya yavaş olduğundan zamanında tamamlanmadı.	Yavaş optimizasyon alıcı kodu.
Eş zamansız alıcı görevleri planlanmadı	goAsync(). alıcılar	onReceive() yöntemi iş yürütmeye çalıştı bir çalışan iş parçacığı havuzunda görünmesini engeller; böylece çalışma hiç başlamamıştır.	Yavaş veya engellenen aramaları optimize edin ya da yayın için farklı ileti dizileri kullanın ve uzun süreli diğer görevlerle kıyaslandığında iyidir.
Çalışanlar yavaş veya engellenmiş	goAsync() alıcı	Çalışan iş parçacığının bir yerinde engelleme veya yavaş çalışma vardı havuzda işlem yapmamızı sağlar. Bu durumda, PendingResult.finish zamanında çağrılmadı.	Yavaş async alıcıyı optimize et girin.
PendingResult.finish adlı kişiyi aramayı unuttum	goAsync() alıcı	Kod yolunda finish() çağrısı eksik.	finish() adlı cihazın her zaman çağrıldığından emin olun.

Hata ayıklama

Küme imzasına ve ANR raporuna göre alıcı çalışır; daha sonra mevcut olmayan veya çalışan kod yavaş yavaş.

Not: Şu hata mesajını içeren yayın alıcı ANR kümelerini yoksaymayın: "nativePollOnce" veya "ana iş parçacığı boşta" olarak görünür. ANR imzasındaki yığınlar Google Play Console ve Firebase Crashlytics, genellikle iş parçacığı; Ancak yayın alıcı, ana olmayan bir ileti dizisinde veya aramada çalışabilir goAsync() Bu kümeler üzerinde, alakalı kullanıcı özelliklerine bakarak iş parçacıkları yer alır.

Aşağıdaki akış grafiğinde bir yayının nedeninin nasıl belirleneceği gösterilmektedir alıcı ANR'si.

Şekil 5. Yayın alıcı ANR'sinde hata ayıklama

Alıcı kodunu bulma

Google Play Console, ANR'deki alıcı sınıfını ve yayın amacını gösterir. imzası var. Şunları arayın:

• cmp=<receiver class>
• act=<broadcast_intent>

Bir yayın alıcı ANR imzası örneği aşağıda verilmiştir:

com.example.app.MyClass.myMethod
Broadcast of Intent { act=android.accounts.LOGIN_ACCOUNTS_CHANGED
cmp=com.example.app/com.example.app.MyAccountReceiver }

onReceive() yöntemini çalıştıran iş parçacığını bulun

Özel bir işleyici belirtmek için Context.registerReceiver kullanıyorsanız bu işleyiciyi çalıştıran iş parçacığıdır. Aksi takdirde bu, ana iş parçacığıdır.

Örnek: eşzamansız alıcı görevleri planlanmamış

Bu bölümde, bir yayın alıcı ANR'sinde hata ayıklama örneği adım adım açıklanmıştır.

ANR imzasının aşağıdaki gibi göründüğünü varsayalım:

com.example.app.MyClass.myMethod
Broadcast of Intent {
act=android.accounts.LOG_ACCOUNTS_CHANGED cmp=com.example.app/com.example.app.MyReceiver }

İmzaya göre yayın amacının android.accounts.LOG_ACCOUNTS_CHANGED ve alıcı sınıfı: com.example.app.MyReceiver.

Alıcı kodundan "BG Thread" adlı iş parçacığı havuzunun [0,1,2,3]" bu yayının işlenmesiyle ilgili temel işi yapar. Yığına bakma dört arka plan (BG) iş parçacığının da aynı kalıba sahip olduğunu görebilirsiniz: bir engelleme araması yapıyorlar, getDataSync. Tüm BG ileti dizileri meşgul olduğundan yayın zamanında işlenemedi ve bu durum ANR'ye yol açtı.

BG Thread #0 (tid=26) Waiting

at jdk.internal.misc.Unsafe.park(Native method:0)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:211)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture:563)
at com.google.common.util.concurrent.ForwardingFuture.get(ForwardingFuture:68)
at com.example.app.getDataSync(<MyClass>:152)

...

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
at com.google.android.libraries.concurrent.AndroidExecutorsModule.lambda$withStrictMode$5(AndroidExecutorsModule:451)
at com.google.android.libraries.concurrent.AndroidExecutorsModule$$ExternalSyntheticLambda8.run(AndroidExecutorsModule:1)
at java.lang.Thread.run(Thread.java:1012)
at com.google.android.libraries.concurrent.ManagedPriorityThread.run(ManagedPriorityThread:34)

There are several approaches to fix the issue:

• Find out why getDataSync is slow and optimize.
• Don't run getDataSync on all four BG threads.
• More generally, ensure that the BG thread pool isn't saturated with long-running operations.
• Use a dedicated thread pool for goAsync worker tasks.
• Use an unbounded thread pool instead of the bounded BG thread pool

Example: slow app startup

A slow app startup can cause several types of ANRs, especially broadcast receiver and execute service ANRs. The cause of an ANR is likely slow app startup if you see ActivityThread.handleBindApplication in the main thread stacks.

Execute service timeout

An execute service ANR happens when the app's main thread doesn't start a service in time. Specifically, a service doesn't finish executing onCreate() and onStartCommand() or onBind() within the timeout period.

Default timeout period: 20 seconds for foreground service; 200 seconds for background service. The ANR timeout period includes the app cold start, if necessary, and calls to onCreate(), onBind(), or onStartCommand().

To avoid execute service ANRs, follow these general best practices:

• Make sure that app startup is fast, since it's counted in the ANR timeout if the app is started to run the service component.
• Make sure that the service's onCreate(), onStartCommand(), and onBind() methods are fast.
• Avoid running any slow or blocking operations on the main thread from other components; these operations can prevent a service from starting quickly.

Common causes

The following table lists common causes of execute service ANRs and suggested fixes.

Cause	What	Suggested fix
Slow app startup	The app takes too long to perform a cold start.	Optimize slow app start.
Slow onCreate(), onStartCommand(), or onBind()	The service component's onCreate(), onStartCommand(), or onBind() method takes too long to execute on the main thread.	Optimize slow code. Move slow operations off the critical path where possible.
Not scheduled (main thread blocked before onStart())	The app's main thread is blocked by another component before the service can be started.	Move other component's work off the main thread. Optimize other component's blocking code.

How to debug

From the cluster signature and ANR report in Google Play Console or Firebase Crashlytics, you can often determine the cause of the ANR based on what the main thread is doing.

Note: Ignore execute service ANR clusters that say "nativePollOnce" or "main thread idle." These usually correspond to ANRs where the stack dump is taken too late, and are generally not actionable. The actual ANR issues are usually present in other clusters, so real issues aren't being hidden. See nativePollOnce for more details.

The following flow chart describes how to debug an execute service ANR.

Figure 6. How to debug an execute service ANR.

If you've determined that the execute service ANR is actionable, follow these steps to help resolve the issue:

1. Find the service component class in the ANR signature. In Google Play Console, the service component class is shown in the ANR signature. In the following example ANR details, it's com.example.app/MyService.

   com.google.common.util.concurrent.Uninterruptibles.awaitUninterruptibly
   Executing service com.example.app/com.example.app.MyService
   

2. Determine whether the slow or block operation is part of app startup, the service component, or elsewhere by checking for the following important function call(s) in the main threads.

   Function call(s) in main thread stacks	What it means
   android.app.ActivityThread.handleBindApplication	App was starting up, so the ANR was caused by slow app start.
   <ServiceClass>.onCreate() [...] android.app.ActivityThread.handleCreateService	Service was being created, so the ANR was likely caused by slow onCreate() code.
   <ServiceClass>.onBind() [...] android.app.ActivityThread.handleBindService	Service was being bound, so the ANR was likely caused by slow onBind() code.
   <ServiceClass>.onStartCommand() [...] android.app.ActivityThread.handleServiceArgs	Service was being started, so the ANR was likely caused by slow onStartCommand() code.

   For example, if the onStartCommand() method in the MyService class is slow, the main threads will look like this:

   at com.example.app.MyService.onStartCommand(FooService.java:25)
   at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:4820)
   at android.app.ActivityThread.-$$Nest$mhandleServiceArgs(unavailable:0)
   at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2289)
   at android.os.Handler.dispatchMessage(Handler.java:106)
   at android.os.Looper.loopOnce(Looper.java:205)
   at android.os.Looper.loop(Looper.java:294)
   at android.app.ActivityThread.main(ActivityThread.java:8176)
   at java.lang.reflect.Method.invoke(Native method:0)
   

   Önemli işlev çağrılarından hiçbirini göremiyorsanız, olanaklar:

   • Hizmet çalışıyor veya kapanıyor. Bu durum, yığınların kabul edebilirsiniz. Bu durumda, ANR'yi yanlış pozitif olarak yoksayabilirsiniz.
   • Yayın alıcı gibi farklı bir uygulama bileşeni çalışıyor. Burada ana iş parçacığının bu bileşende engellenmiş olması, emin olun.

3. Bir temel işlev çağrısı görüyorsanız ve ANR'nin nerede olduğunu belirleyebiliyorsanız varsa, yavaş olanı bulmak için ana iş parçacığı yığınlarının geri kalanını veya kritik yolun dışına taşımanızı sağlar.

Hizmetler hakkında daha fazla bilgi için aşağıdaki sayfalara bakın:

• Hizmetlere genel bakış
• Ön plan hizmetleri
• Service

İçerik sağlayıcı yanıt vermiyor

İçerik sağlayıcı ANR'si, bir uzak içerik sağlayıcının sorguya yanıt vermek için belirlediğiniz zaman aşımı süresi sonlandırılır.

Varsayılan zaman aşımı süresi: İçerik sağlayıcı tarafından ContentProviderClient.setDetectNotResponding. ANR zaman aşımı süresi bir uzak içerik sağlayıcı sorgusunun çalıştırılacağı toplam süreyi içerir ve uzaktan başlatmayı içerir.

İçerik sağlayıcı ANR'lerini önlemek için aşağıdaki en iyi uygulamaları izleyin:

• Uygulama başlatılmasının hızlı olduğundan emin olun. Çünkü bu işlem, aşağıdaki durumlarda ANR zaman aşımında sayılır Uygulama, içerik sağlayıcıyı çalıştırmaya başlar.
• İçerik sağlayıcı sorgularının hızlı olduğundan emin olun.
• Tüm uygulamanın bağlayıcı ileti dizilerini gösterir.

Yaygın nedenler

Aşağıdaki tabloda, içerik sağlayıcı ANR'lerinin yaygın nedenleri ve önerilenler listelenmiştir. gider.

Neden	Ne olur?	Sinyal	Önerilen düzeltme
Yavaş içerik sağlayıcı sorgusu	İçerik sağlayıcının çalışması çok uzun sürüyor veya sağlayıcı engellendi.	android.content.ContentProvider$Transport.query karesi bağlayıcı ileti dizisindedir.	İçerik sağlayıcı sorgusunu optimize edin. Bağlayıcıyı neyin engellediğini öğrenin ileti dizisi.
Yavaş uygulama başlatma	İçerik sağlayıcı uygulamasının başlatılması çok uzun sürüyor.	ActivityThread.handleBindApplication karesinin içinde ana ileti dizisidir.	Uygulama başlatma işlemini optimize edin.
Bağlayıcı iş parçacığının tükenmesi: Tüm bağlayıcı iş parçacıkları meşgul	Tüm bağlayıcı iş parçacıkları diğer eşzamanlı isteklere hizmet vermekle meşgul. Bu nedenle içerik sağlayıcı bağlayıcı çağrısı çalıştırılamıyor.	Uygulama başlamıyor, tüm bağlayıcı ileti dizileri meşgul ve içerikler sağlayıcı çalışmıyor.	Bağlayıcı iş parçacıklarındaki yükü azaltın. Yani, eşzamanlı olmayan giden ileti sayısını azaltın. Gelen aramaları işlerken daha az iş yapabilir veya aramaları bağlayabilirsiniz.

Hata ayıklama

Bir içerik sağlayıcı ANR'sinde küme imzasını ve ANR raporunu kullanarak hata ayıklamak için veya Firebase Crashlytics, ana iş parçacığı ve bağlayıcı iş parçacıklarının ne durumda olduğunu gösterir.

Aşağıdaki akış grafiğinde, içerik sağlayıcı ANR'sinin nasıl ayıklanacağı açıklanmaktadır:



Şekil 7. İçerik sağlayıcı ANR'sinde hata ayıklama

Aşağıdaki kod snippet'i, yavaş bir içerik sağlayıcı sorgusu nedeniyle engellendi. Bu durumda içerik sağlayıcı sorgusu bir veritabanını açarken kilit bekliyor.

binder:11300_2 (tid=13) Blocked

Waiting for osm (0x01ab5df9) held by at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers:182)
at com.example.app.MyClass.blockingGetOpenDatabase(FooClass:171)
[...]
at com.example.app.MyContentProvider.query(MyContentProvider.java:915)
at android.content.ContentProvider$Transport.query(ContentProvider.java:292)
at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:107)
at android.os.Binder.execTransactInternal(Binder.java:1339)
at android.os.Binder.execTransact(Binder.java:1275)

Aşağıdaki kod snippet'i, uygulamanın yavaş başlatılması nedeniyle engellendi. Bu durumda, uygulamanın başlatılması neden çok yavaş? kilit çakışması.

main (tid=1) Blocked

[...]
at dagger.internal.DoubleCheck.get(DoubleCheck:51)
- locked 0x0e33cd2c (a qsn)at dagger.internal.SetFactory.get(SetFactory:126)
at com.myapp.Bar_Factory.get(Bar_Factory:38)
[...]
at com.example.app.MyApplication.onCreate(DocsApplication:203)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1316)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6991)
at android.app.ActivityThread.-$$Nest$mhandleBindApplication(unavailable:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2235)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at android.app.ActivityThread.main(ActivityThread.java:8170)
at java.lang.reflect.Method.invoke(Native method:0)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:971)

Yavaş iş yanıtı

Uygulamanın yanıt vermesi çok uzun sürdüğünde, yavaş iş yanıtı ANR'si oluşur JobService.onStartJob() veya JobService.onStopJob() ya da çok uzun sürüyor JobService.setNotification() kullanarak bir bildirim sağlar. Bu durum, uygulamanın ana ileti dizisinin başka bir işlem yapması engellendi.

Sorun JobService.onStartJob() veya JobService.onStopJob() ile ilgiliyse ana ileti dizisinde neler olduğuna bakın. Projenizle ilgili bir sorun JobService.setNotification(), çağrıyı en kısa sürede yapmaya dikkat edin. Bildirimi sağlamadan önce çok fazla işlem yapmayın.

Gizemli ANR'ler

Bazen ANR'nin neden oluştuğu anlaşılmaz veya her zaman hata ayıklama bilgileri yer alır. Böyle durumlarda ANR'nin hâlâ sorunlu olup olmadığını belirlemek için atabileceğiniz eyleme dökülebilir.

İleti sırası boşta veya yerelPollOnce

android.os.MessageQueue.nativePollOnce çerçevesini yığınlar görüyorsanız bu genellikle, yanıt vermeyen ileti dizisinden şüphelenilen boşta ve döngüleyici mesajları bekliyor. Google Play Console'da ANR ayrıntıları aşağıdaki gibi görünür:

Native method - android.os.MessageQueue.nativePollOnce
Executing service com.example.app/com.example.app.MyService

Örneğin, ana iş parçacığı boştaysa gruplar şu şekilde görünür:

"main" tid=1 NativeMain threadIdle

#00  pc 0x00000000000d8b38  /apex/com.android.runtime/lib64/bionic/libc.so (__epoll_pwait+8)
#01  pc 0x0000000000019d88  /system/lib64/libutils.so (android::Looper::pollInner(int)+184)
#02  pc 0x0000000000019c68  /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+112)
#03  pc 0x000000000011409c  /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
at android.os.MessageQueue.nativePollOnce (Native method)
at android.os.MessageQueue.next (MessageQueue.java:339)  at android.os.Looper.loop (Looper.java:208)
at android.app.ActivityThread.main (ActivityThread.java:8192)
at java.lang.reflect.Method.invoke (Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:626)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1015)

Yanıt vermeyen şüpheli ileti dizisinin boşta olmasının birkaç nedeni vardır:

• Geç yığın dökümü. İleti dizisi, ANR tetiklenmesi ve yığınların dökümü. Android'deki Piksellerdeki gecikme 13, yaklaşık 100 ms'dir ancak 1 saniyeyi aşabilir. Android 14'te Pixel'lerdeki gecikme genelde 10 ms'nin altında.
• İleti dizisinin yanlış ilişkilendirmesi. ANR imzası oluşturmak için kullanılan ileti dizisi şu değil: ANR'ye neden olan yanıt vermeyen ileti dizisini kontrol edin. Bu durumda, aşağıdaki türlerden biri olup olmadığını belirleyebilirsiniz:
  • Yayın alıcı zaman aşımı
  • İçerik sağlayıcı yanıt vermiyor
  • Odaklanılan pencere yok
• Sistem genelinde sorun. İşlem, yoğun sistem yükü nedeniyle planlanmadı veya sistem sunucusunda bir sorun var.

Yığın çerçevesi yok

Bazı ANR raporları ANR'yi içeren yığınları içermez. Bu durum, ANR raporu oluşturulurken yığın dökümü başarısız oldu. Paydaşlarla toplantı yaparken yığın çerçevelerinin eksik olmasının olası nedenleri:

• Yığını almak çok uzun sürer ve zaman aşımına uğrar.
• İşlem, yığınlar çekilmeden önce ölmüş veya sonlandırıldı.

[...]

--- CriticalEventLog ---
capacity: 20
timestamp_ms: 1666030897753
window_ms: 300000

libdebuggerd_client: failed to read status response from tombstoned: timeout reached?

----- Waiting Channels: pid 7068 at 2022-10-18 02:21:37.<US_SOCIAL_SECURITY_NUMBER>+0800 -----

[...]

Yığın çerçeveleri olmayan ANR'ler, küme imzası veya ANR üzerinden işleme koyulamaz rapordur. Sorun büyükse hata ayıklamak için uygulamanın diğer kümelerine bakın genellikle yığın çerçevelerinin bulunduğu kendi kümesine sahip olur. Diğer bir seçenek de Perfetto izlerine bakmaktır.

Bilinen sorunlar

Sonlandırma amacıyla uygulamanızın sürecinde bir zamanlayıcı tutma nedeniyle ANR tetiklenmeden önce yayın işlemenin düzgün sistemin ANR'leri eşzamansız olarak izleme şekli.