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 planlanmıştı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. n2 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.
Aşağıdaki akış grafiğinde, giriş zaman aşımının nedeninin nasıl belirleneceği gösterilmektedir ANR'yi gönderin.
![](https://developer.android.com/static/topic/performance/images/debug-input-dispatch-anr.png?authuser=5&hl=tr)
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.
![](https://developer.android.com/static/topic/performance/images/play-vitals-anr-detection.png?authuser=5&hl=tr)
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ıyorsaPendingResult.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ı ( |
10 saniye |
İşlemde CPU eksikliği olup olmadığına bağlı olarak 10-20 saniye |
Arka planda öncelik amacı ( |
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.
![](https://developer.android.com/static/topic/performance/images/broadcast-receiver-anr-timeline.png?authuser=5&hl=tr)
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ı.
![](https://developer.android.com/static/topic/performance/images/sync-async-measurement-end.png?authuser=5&hl=tr)
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ş.
Aşağıdaki akış grafiğinde bir yayının nedeninin nasıl belirleneceği gösterilmektedir alıcı ANR'si.
![](https://developer.android.com/static/topic/performance/images/debug-broadcast-receiver-timeout-anr.png?authuser=5&hl=tr)
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()
, andonBind()
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.
The following flow chart describes how to debug an execute service ANR.
![](https://developer.android.com/static/topic/performance/images/debug-execute-service-anr.png?authuser=5&hl=tr)
If you've determined that the execute service ANR is actionable, follow these steps to help resolve the issue:
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
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 theMyService
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.
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.
- 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.
- 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 genellikle 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:
- Sistem genelinde sorun. İşlem, yoğun sistem yükü nedeniyle planlanmadı veya sistem sunucusunda bir sorun var demektir.
- Yığını almak çok uzun sürer ve zaman aşımına uğrar.
- İşlem, yığınlar çekilmeden önce ölmüş veya sonlandırıldı.
Hizmetler hakkında daha fazla bilgi için aşağıdaki sayfalara bakın:
İç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:
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ı iş parçacığındadır. |
İç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
iş parçacığı. |
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:
![](https://developer.android.com/static/topic/performance/images/debug-content-provider-anr.png?authuser=5&hl=tr)
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:
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:
[...]
--- 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.