تشخيص أخطاء ANR وإصلاحها

عند حظر سلسلة واجهة المستخدم في تطبيق Android لفترة طويلة جدًا، يرسل النظام رسالة "التطبيق لا يستجيب" (ANR). تصف هذه الصفحة الأنواع المختلفة أنواع أخطاء ANR وكيفية تشخيصها واقتراحات لإصلاحها. جميع النطاقات الزمنية التلقائية للمهلة المحدّدة هي تلك الخاصة بأجهزة AOSP وPixel. هذه الأوقات قد تختلف حسب المصنّع الأصلي للجهاز.

وتجدر الإشارة إلى أنه عند تحديد سبب أخطاء ANR، من المفيد التمييز بين مشاكل النظام والتطبيق.

عندما يكون النظام في حالة سيئة، يمكن أن تؤدي المشاكل التالية إلى حدوث أخطاء ANR:

• تؤدي المشكلات المؤقتة في خادم النظام عادةً إلى حدوث اتصالات سريعة بطيء.
• إنّ المشاكل المتعلّقة بخادم النظام والحِمل الزائد على الجهاز تؤدي إلى عدم تنفيذ سلاسل محادثات التطبيق. مجدول.

من الطرق الجيدة للتمييز بين مشاكل النظام والتطبيق، إذا كانت متاحة لك لاستخدام تتبُّعات Perfetto:

• يمكنك معرفة ما إذا تمت جدولة سلسلة المحادثات الرئيسية في التطبيق من خلال الاطّلاع على حالة سلسلة المحادثات. في Perfetto لمعرفة ما إذا كان قيد التشغيل أو قابلاً للتشغيل.
• راجِع سلاسل محادثات system_server بحثًا عن مشاكل مثل التعارض مع قفل الشاشة.
• عند تلقّي طلبات الحافظات البطيئة، يُرجى الاطّلاع على سلسلة محادثات الرد، في حال توفّرها، لمعرفة سبب ذلك. بطيء.

مهلة إرسال الإدخال

تحدث أخطاء ANR في إرسال الإدخال عندما لا تستجيب سلسلة التعليمات الرئيسية في التطبيق لأحد الإدخالات. حدث، مثل التمرير السريع أو الضغط على المفتاح في الوقت المناسب. بما أنّ التطبيق يعمل في المقدّمة عند حدوث مهلات إرسال الإدخال، تكون غالبًا مرئية للمستخدم ومن المهم جدًا للتخفيف من حدتها.

فترة المهلة التلقائية: 5 ثوانٍ.

تحدث أخطاء ANR في إرسال الإدخال عادةً بسبب مشاكل في سلسلة التعليمات الرئيسية. إذا تم تحديد إذا تم حظر سلسلة التعليمات في انتظار الحصول على قفل، فيمكن أيضًا حظر سلسلة التعليمات المشاركة.

لتجنُّب أخطاء ANR في إرسال الإدخالات، اتّبِع أفضل الممارسات التالية:

• عدم تنفيذ عمليات حظر أو عمليات طويلة الأمد في سلسلة التعليمات الرئيسية ضع في اعتبارك استخدام StrictMode لرصد الأخطاء غير المقصودة النشاط في سلسلة التعليمات الرئيسية
• يمكنك تقليل التضارب بين سلسلة التعليمات الرئيسية وسلاسل المحادثات الأخرى.
• تقليل العمل غير المستند إلى واجهة المستخدم في سلسلة التعليمات الرئيسية، على سبيل المثال عند التعامل مع عمليات البث أو تشغيل الخدمات.

الأسباب الشائعة

في ما يلي بعض الأسباب الشائعة والإصلاحات المقترحة لأخطاء ANR في إرسال الإدخالات.

كيفية تصحيح الأخطاء

يمكنك بدء تصحيح الأخطاء من خلال الاطّلاع على توقيع مجموعة أخطاء ANR في Google Play Console أو Firebase Crashlytics. تحتوي المجموعة العنقودية عادةً على الجزء العلوي الإطارات التي يُشتبه في تسببها في حدوث خطأ ANR.

يعرض الرسم البياني التالي طريقة تحديد سبب انتهاء مهلة الإدخال. إرسال ANR.

يمكن أن ترصد ميزة "مؤشرات Play الحيوية" بعض أسباب أخطاء ANR الشائعة وتساعد في تصحيحها. بالنسبة مثلاً، إذا اكتشفت المؤشرات الحيوية حدوث خطأ ANR بسبب تزايد الطلب على القفل، فإنها تلخيص المشكلة والحلّ المقترَح في قسم إحصاءات أخطاء ANR.

لم يتم التركيز على أي نافذة.

بينما يتم إرسال أحداث مثل اللمس مباشرةً إلى النافذة ذات الصلة بناءً على النتيجة للاختبار، تحتاج أحداث مثل المفاتيح إلى هدف. ويُشار إلى هذا الهدف باسم نافذة يتم التركيز عليها. هناك نافذة واحدة فقط مركّزة لكل شاشة، وعادةً ما النافذة التي يتفاعل معها المستخدم حاليًا. إذا كانت النافذة التي يتم التركيز عليها النتيجة، يتسبب الإدخال في ظهور خطأ ANR للنافذة التي يتم التركيز عليها. خطأ ANR لا يتم التركيز عليه هو نوع من أخطاء ANR لإرسال الإدخال.

فترة المهلة التلقائية: 5 ثوانٍ.

الأسباب الشائعة

تحدث أخطاء ANR التي لا يتم التركيز عليها عادةً بسبب أي من المشاكل التالية:

• يؤدي التطبيق الكثير من العمل وبطء للغاية لرسم الإطار الأول.
• لا يمكن التركيز على النافذة الرئيسية. إذا تم وضع علامة على نافذة تفيد بأنها FLAG_NOT_FOCUSABLE، لا يمكن للمستخدم إرسال أحداث رئيسية أو أزرار إليه.

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

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

مهلة مستقبِل البث

يحدث خطأ ANR لمستقبِل البث عندما لا يتعامل مستقبل البث مع البث في الوقت المناسب. لأجهزة الاستقبال المتزامنة أو المستقبِلات التي لا تتصل goAsync()، تعني المهلة الزمنية أن onReceive() لم تكتمل خلال الوقت. بالنسبة إلى أجهزة الاستقبال غير المتزامنة أو المستلِمين الذين يتصلون بـ goAsync()، يعني انتهاء المهلة الذي لم يتم استدعاء PendingResult.finish() فيه في الوقت المناسب.

غالبًا ما تحدث أخطاء ANR لمستقبِل البث في سلاسل المحادثات التالية:

• سلسلة التعليمات الرئيسية إذا كانت المشكلة تؤدي إلى بطء بدء تشغيل التطبيق
• تعمل سلسلة المحادثات على تشغيل مستقبل البث، إذا كانت المشكلة بطيئة في رمز onReceive().
• سلاسل المحادثات الخاصة بعاملي البث، إذا كانت المشكلة بطيئة في رمز البث goAsync()

لتجنُّب أخطاء ANR لمستقبِل البث، اتّبِع أفضل الممارسات التالية:

• عليك التأكّد من أنّ بدء تشغيل التطبيق سريع، لأنّه يتم احتسابه ضمن مهلة خطأ ANR إذا بدء التطبيق بمعالجة البث.
• في حال استخدام goAsync()، تأكَّد من طلب الرقم PendingResult.finish() بسرعة. يخضع ذلك لمهلة خطأ ANR نفسها التي تخضع لها أجهزة استقبال البث المتزامنة.
• في حال استخدام goAsync()، تأكّد من عدم مشاركة سلاسل محادثات العامل مع. عمليات أخرى طويلة الأمد أو عمليات حظر.
• يمكنك استخدام registerReceiver() لتشغيل أجهزة استقبال البث في سلسلة غير رئيسية، لتجنُّب حظر رمز واجهة المستخدم الذي يعمل في سلسلة التعليمات الرئيسية.

فترات المهلة

تعتمد فترات مهلة تلقّي البث على ما إذا كانت العلامة التي تعمل في المقدّمة وإصدار النظام الأساسي.

لمعرفة ما إذا تم ضبط العلامة FLAG_RECEIVER_FOREGROUND، ابحث عن "flg=" في حدث خطأ ANR وتحقَّق من توفُّر 0x10000000. إذا تم تعيين هذا البت، تم ضبط FLAG_RECEIVER_FOREGROUND في الغرض، وبالتالي تكون المهلة أقصر.

مثال على موضوع ANR مع المهلة القصيرة للبث (من 10 إلى 20 ثانية):

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

مثال على موضوع ANR مع المهلة الطويلة للبث (من 60 إلى 120 ثانية):

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

كيفية قياس أوقات البث

يبدأ قياس مدة البث عندما يتم إرسال البث من system_server إلى التطبيق، وينتهي عند انتهاء التطبيق من معالجة البث. إذا لم تكن عملية التطبيق قيد التشغيل بالفعل، فستحتاج أيضًا إلى إجراء اختبار البدء خلال مهلة خطأ ANR. وبالتالي، يمكن أن يؤدي بطء بدء التطبيق إلى أخطاء ANR لمستقبِل البث

يوضح الشكل التالي أن المخطط الزمني لأخطاء ANR لمستقبِل البث يتوافق مع عمليات تطبيق معينة.

ينتهي قياس مهلة خطأ ANR عند انتهاء المُستلِم من معالجة البث: يعتمد الوقت الذي يحدث فيه هذا بالضبط على ما إذا كانت مزامنة مستلم غير متزامن.

• بالنسبة إلى أجهزة الاستقبال المتزامنة، يتوقف القياس عند رجوع onReceive().
• بالنسبة إلى أجهزة الاستقبال غير المتزامنة، يتوقف القياس عندما تم الاتصال بـ "PendingResult.finish()".

الأسباب الشائعة

في ما يلي بعض الأسباب الشائعة والإصلاحات المقترَحة لمشاكل ANR لمستقبِل البث.

كيفية تصحيح الأخطاء

استنادًا إلى توقيع المجموعة وتقرير ANR، يمكنك تحديد موقع سلسلة المحادثات التي تشغيل جهاز الاستقبال، ثم الرمز المحدد المفقود أو قيد التشغيل ببطء.

يعرض الرسم البياني التالي كيفية تحديد سبب البث. خطأ ANR للمستلم.

البحث عن رمز جهاز الاستقبال

تعرض أداة Google Play Console فئة المستلِم ونية البث في خطأ ANR. التوقيع. ابحث عما يلي:

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

في ما يلي مثال على توقيع ANR لمتلقي البث:

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

البحث عن سلسلة المحادثات التي تستخدم طريقة onReceive()

إذا كنت تستخدم Context.registerReceiver لتحديد معالج مخصّص، إنه سلسلة التعليمات التي تشغّل هذا المعالج. وبخلاف ذلك، تكون سلسلة المحادثات الرئيسية.

مثال: مهام المُستلِم غير المتزامنة التي لم تتم جدولتها

يعرض هذا القسم مثالاً على كيفية تصحيح أخطاء ANR لمستقبِل البث.

لنفترض أنّ توقيع ANR يبدو كما يلي:

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

استنادًا إلى التوقيع، يبدو أنّ الهدف من البث هو android.accounts.LOG_ACCOUNTS_CHANGED وفئة المستلِم هي com.example.app.MyReceiver

من رمز المستلِم، يمكنك تحديد أنّ مجموعة سلاسل المحادثات "BG Thread [0,1,2,3]" يقوم بالعمل الرئيسي لمعالجة هذا البث. الاطّلاع على الحزمة ، يمكنك رؤية أن سلاسل الخلفية (BG) الأربع لها النمط ذاته: طلب حظر "getDataSync" نظرًا لأن جميع سلاسل محادثات BG كانت مشغولة، فإن تعذّرت معالجة البث في الوقت المناسب، ما أدّى إلى حدوث خطأ ANR.

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.

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.

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)
   

   إذا لم تتمكن من رؤية أي من استدعاءات الدوال المهمة، فهناك سببان آخران الاحتمالات:

   • فالخدمة قيد التشغيل أو يتم إيقافها، مما يعني أن الحزم متوقفة يستغرق ظهورها وقت متأخر. في هذه الحالة، يمكنك تجاهل خطأ ANR باعتباره موجبًا خاطئًا.
   • هناك مكوِّن تطبيق آخر قيد التشغيل، مثل جهاز استقبال البث. في هذه الدورة، إذا كان من المحتمل أن تكون سلسلة التعليمات الرئيسية محظورة في هذا المكوِّن، ما يمنع الخدمة منذ بدء تشغيلها.

3. إذا ظهر لك استدعاء وظيفة رئيسية وكان بإمكانك تحديد مكان خطأ ANR بشكل عام، فتحقق من باقي حزم سلاسل المحادثات الرئيسية للعثور على البيانات البطيئة تشغيله وتحسينه أو نقله خارج المسار الحرج.

لمزيد من المعلومات عن الخدمات، يُرجى الاطّلاع على الصفحات التالية:

• نظرة عامة على الخدمات
• الخدمات التي تعمل في المقدّمة
• Service

موفّر المحتوى لا يستجيب

يحدث خطأ ANR لموفّر المحتوى عندما يستغرق موفّر المحتوى البعيد وقتًا أطول من المهلة للرد على استعلام، ويتم إنهاؤها.

فترة المهلة التلقائية: يحددها موفّر المحتوى باستخدام ContentProviderClient.setDetectNotResponding فترة مهلة خطأ ANR الوقت الإجمالي اللازم لتشغيل استعلام موفر المحتوى البعيد، تشغيل التطبيق البعيد على البارد إذا لم يكن قيد التشغيل بالفعل.

لتجنُّب أخطاء ANR التي يوفّرها موفّر المحتوى، اتّبِع أفضل الممارسات التالية:

• عليك التأكّد من أنّ بدء تشغيل التطبيق سريع، لأنّه يتم احتسابه ضمن مهلة خطأ ANR إذا بدء التطبيق بتشغيل موفّر المحتوى
• تأكَّد من أنّ طلبات بحث موفّر المحتوى سريعة.
• لا تُجرِ الكثير من طلبات الربط المتزامنة التي قد تؤدي إلى حظر جميع وسلاسل الربط الخاصة بالتطبيق.

الأسباب الشائعة

يعرض الجدول التالي الأسباب الشائعة لمشاكل ANR وموفّر المحتوى المقترَحة إصلاحات الأخطاء.

السبب	ماذا يحدث؟	الإشارة	الحل المقترَح
طلب بحث من مقدِّم محتوى بطيء	يستغرق موفّر المحتوى وقتًا طويلاً جدًا لتنفيذه أو تم حظره.	إطار android.content.ContentProvider$Transport.query في سلسلة الربط.	تحسين طلب بحث موفّر المحتوى التعرّف على سبب حجب مادة الحافظ .
مشكلة بطء التطبيق عند بدء تشغيله	يستغرق تطبيق موفّر المحتوى وقتًا طويلاً للبدء.	يقع إطار ActivityThread.handleBindApplication في السلسلة الرئيسية.	تحسين بدء تشغيل التطبيق:
استنفاد سلسلة التعليمات: جميع سلاسل مجلد الربط مشغولة.	جميع سلاسل المرابط مشغولة بخدمة طلبات متزامنة أخرى، وبالتالي يتعذر تشغيل طلب binder موفّر المحتوى.	التطبيق لا يبدأ، وجميع سلاسل المجلدات مشغولة، والمحتوى مقدم الخدمة لا يعمل.	تقليل الحمل على سلاسل الربط. أي تقليل عدد الرسائل الصادرة المتزامنة بيندر أو تنجز عملاً أقل عند التعامل مع المكالمات الواردة.

كيفية تصحيح الأخطاء

لتصحيح أخطاء ANR لموفّر المحتوى باستخدام توقيع المجموعة وتقرير ANR في Google Play Console أو Firebase Crashlytics، فابحث عن موضوع تقوم بها سلسلة(سلاسل) البيندر.

يوضِّح رسم التدفّق البياني التالي كيفية تصحيح أخطاء ANR لموفّر المحتوى:



يوضح مقتطف الرمز التالي الشكل الذي تبدو عليه سلسلة الربط عند تم الحظر بسبب بطء طلب موفّر المحتوى. في هذه الحالة، يستخدم موفر المحتوى الاستعلام في انتظار القفل عند فتح قاعدة بيانات.

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)

يوضح مقتطف الرمز التالي شكل سلسلة المحادثات الرئيسية تم حظره بسبب بطء بدء تشغيل التطبيق. في هذه الحالة، يكون بدء تشغيل التطبيق بطيئًا بسبب قفل الخلاف أثناء تهيئة الخنجر.

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)

استجابة وظيفية بطيئة

يحدث خطأ ANR للاستجابة البطيئة للوظيفة عندما يستغرق التطبيق وقتًا طويلاً جدًا للاستجابة إلى JobService.onStartJob() أو JobService.onStopJob()، أو يستغرق وقتًا طويلاً جدًا إرسال إشعار باستخدام JobService.setNotification() يشير هذا إلى أن تم حظر سلسلة التعليمات الرئيسية للتطبيق من تنفيذ إجراء آخر.

إذا كانت المشكلة في JobService.onStartJob() أو JobService.onStopJob()، تحقَّق مما يحدث في سلسلة المحادثات الرئيسية إذا كانت المشكلة في JobService.setNotification()، احرص على الاتصال به في أسرع وقت ممكن. ولا تقوم بالكثير من العمل قبل تقديم الإشعار.

أخطاء ANR الغامضة

في بعض الأحيان، يكون سبب حدوث خطأ ANR غير واضح أو قد لا يكون معلومات لتصحيح الأخطاء في توقيع المجموعة وتقرير أخطاء ANR. في هذه الحالات، لا يزال هناك بعض الخطوات التي يمكنك اتخاذها لتحديد ما إذا كان خطأ ANR قابلة للتنفيذ.

قائمة انتظار الرسائل غير نشِطة أو localPollOnce

إذا رأيت الإطار android.os.MessageQueue.nativePollOnce في غالبًا ما يشير ذلك إلى أن سلسلة التعليمات التي يُشتبه بأنّها غير مستجيبة خاملاً وفي انتظار رسائل التكرار. في Google Play Console، ستظهر تفاصيل خطأ ANR تبدو كما يلي:

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

على سبيل المثال، إذا كانت سلسلة المحادثات الرئيسية غير نشطة، ستبدو الحزم على النحو التالي:

"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)

هناك عدة أسباب قد تؤدي إلى عدم نشاط سلسلة المحادثات التي يُشتبه بأنّها غير مستجيبة:

• تفريغ تسلسل استدعاء الدوال البرمجية في وقت متأخر: تم استرداد سلسلة المحادثات خلال الفترة الزمنية القصيرة بين حدث خطأ ANR وتفريغ الحزم وقت الاستجابة في هواتف Pixel على نظام التشغيل Android 13 حوالي 100 ملي ثانية، ولكن يمكن أن تتجاوز ثانية واحدة. وقت الاستجابة في هواتف Pixel على نظام التشغيل Android 14 عادة أقل من 10 ملّي ثانية.
• إساءة تحديد مصدر سلسلة المحادثات: لم تكن سلسلة المحادثات المُستخدَمة لإنشاء توقيع ANR سلسلة التعليمات الفعلية التي لا تستجيب والتي تسببت في حدوث خطأ ANR. في هذه الحالة، حاول عليك تحديد ما إذا كان خطأ ANR أحد الأنواع التالية:
  • مهلة مُستلِم البث
  • موفّر المحتوى لا يستجيب
  • ما مِن نافذة محلّ التركيز
• مشكلة على مستوى النظام لم تتم جدولة العملية بسبب الحِمل الزائد على النظام. أو مشكلة في خادم النظام.

بدون إطارات تكديس

لا تشتمل بعض تقارير أخطاء ANR على حزمتَي خطأ ANR، ما يعني أنّ خطأ تعذَّر تفريغ تسلسل استدعاء الدوال البرمجية عند إنشاء تقرير خطأ ANR. هناك أمران الأسباب المحتملة لفقدان إطارات تسلسل استدعاء الدوال البرمجية:

• يستغرق نقل الحزمة وقتًا طويلاً جدًا وتنتهي المهلة.
• انتهت العملية أو قتلت قبل أخذ المكدسات.

[...]

--- 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 -----

[...]

لا يمكن اتخاذ إجراء بشأن أخطاء ANR بدون إطارات حِزم التكديس من خلال توقيع المجموعة أو خطأ ANR. إبلاغ. لتصحيح الأخطاء، اطّلِع على المجموعات الأخرى الخاصة بالتطبيق، لأنّها إذا كانت المشكلة كبيرة. بالقدر الكافي، فسيكون لها عادةً مجموعتها الخاصة حيث توجد إطارات المكدس. يمكنك أيضًا الاطّلاع على تتبُّعات Perfetto.

المشاكل المعروفة

الاحتفاظ بموقت في عملية التطبيق لغرض إنهاء العملية قد لا تعمل معالجة البث بشكل صحيح قبل تشغيل خطأ ANR بشكل صحيح بسبب الطريقة غير المتزامنة التي يراقب بها النظام أخطاء ANR.