قراءة تقارير الأخطاء

الأخطاء جزء لا يتجزأ من أي عملية تطوير، كما أنّ تقارير الأخطاء ضرورية لتحديد المشاكل وحلّها. تتيح جميع إصدارات Android تسجيل تقارير الأخطاء باستخدام Android Debug Bridge (adb)، وتتيح إصدارات Android 4.2 والإصدارات الأحدث خيار المطوّرين لإنشاء تقارير الأخطاء ومشاركتها عبر البريد الإلكتروني أو Drive أو غير ذلك.

تحتوي تقارير أخطاء Android على بيانات dumpsys وdumpstate وlogcat بتنسيق نصي (txt.)، ما يتيح لك البحث بسهولة عن محتوى معيّن. توضّح الأقسام التالية بالتفصيل مكوّنات تقرير الأخطاء، وتصف المشاكل الشائعة، وتقدّم نصائح مفيدة وأوامر grep للعثور على السجلات المرتبطة بهذه الأخطاء. تتضمّن معظم الأقسام أيضًا أمثلة للأمر grep والناتج و/أو dumpsys الناتج.

أداة Logcat

سجلّ logcat هو عبارة عن تفريغ مستند إلى سلسلة لجميع معلومات logcat. يتم حجز جزء النظام للإطار وله سجلّ أطول من الرئيسي الذي يحتوي على كل شيء آخر. يبدأ كل سطر عادةً بـ timestamp UID PID TID log-level، مع أنّ UID قد لا يكون مُدرَجًا في إصدارات Android القديمة.

عرض سجلّ الأحداث

يحتوي هذا السجلّ على تمثيلات سلسلة لرسائل السجلّ المنسّقة بتنسيق ثنائي. وهي أقل تشويشًا من سجل logcat، ولكنها أيضًا أصعب قليلاً في القراءة. عند عرض سجلّات الأحداث، يمكنك البحث في هذا القسم عن معرّف عملية معيّن (PID) للاطّلاع على الإجراءات التي اتّخذتها العملية. التنسيق الأساسي هو: timestamp PID TID log-level log-tag tag-values.

تشمل مستويات السجلّ ما يلي:

  • V: مطوّل
  • D: تصحيح الأخطاء
  • I: معلومات
  • W: تحذير
  • E: خطأ

 

للاطّلاع على علامات سجلّ الأحداث المفيدة الأخرى، يُرجى الرجوع إلى /services/core/java/com/android/server/EventLogTags.logtags.

أخطاء ANR وحالات الجمود

يمكن أن تساعدك تقارير الأخطاء في تحديد سبب حدوث أخطاء التطبيق لا يستجيب (ANR) وأحداث التعطّل.

تحديد التطبيقات التي لا تستجيب

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

يمكنك أيضًا البحث عن ANR in في سجلّ logcat، الذي يحتوي على مزيد من المعلومات حول ما كان يستخدم وحدة المعالجة المركزية في وقت حدوث خطأ ANR.

العثور على تتبُّع تسلسل استدعاء الدوال البرمجية

يمكنك غالبًا العثور على عمليات تتبُّع تسلسل استدعاء الدوال البرمجية التي تتوافق مع خطأ ANR. تأكَّد من تطابق الطابع الزمني ومعرّف العملية (PID) في عمليات تتبُّع الجهاز الافتراضي مع خطأ ANR الذي تبحث عنه، ثم تحقَّق من سلسلة التعليمات الرئيسية للعملية. تنبيه:

  • لا تخبرك سلسلة التعليمات الرئيسية إلا بما كانت تفعله عند حدوث خطأ ANR، وقد يكون ذلك مرتبطًا بالسبب الحقيقي لخطأ ANR أو لا يكون. (قد يكون تسلسل استدعاء الدوال البرمجية في تقرير الخطأ غير ذي صلة، فقد يكون هناك شيء آخر عالقًا لفترة طويلة، ولكن ليس طويلاً بما يكفي لحدوث خطأ ANR، قبل أن يتم إصلاحه).
  • قد تتوفّر أكثر من مجموعة واحدة من بيانات تتبُّع تسلسل استدعاء الدوال البرمجية (VM TRACES JUST NOW وVM TRACES AT LAST ANR). تأكَّد من أنّك تعرض القسم الصحيح.

العثور على حالات توقّف تام

غالبًا ما تظهر حالات الانسداد أولاً على شكل أخطاء ANR لأنّ سلاسل المحادثات تتعطّل. إذا حدثت حالة توقّف تام في خادم النظام، سيوقفها برنامج مراقبة النظام في النهاية، ما يؤدي إلى ظهور إدخال في السجلّ مشابه لما يلي: WATCHDOG KILLING SYSTEM PROCESS. من منظور المستخدم، تتم إعادة تشغيل الجهاز، ولكن من الناحية الفنية، هذه إعادة تشغيل لوقت التشغيل وليس إعادة تشغيل كاملة.

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

للعثور على حالات توقّف تام، راجِع أقسام عمليات تتبُّع الجهاز الافتراضي بحثًا عن نمط يشير إلى أنّ السلسلة A تنتظر شيئًا تحتفظ به السلسلة B، والتي بدورها تنتظر شيئًا تحتفظ به السلسلة A.

الأنشطة

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

عرض الأنشطة المركّزة

للاطّلاع على سجلّ الأنشطة المركّزة، ابحث عن am_focused_activity.

بدء عملية العرض

للاطّلاع على سجلّ عمليات البدء، ابحث عن Start proc.

تحديد ما إذا كان الجهاز يعاني من مشكلة التبديل السريع

لتحديد ما إذا كان الجهاز يُفرط في استخدام الذاكرة، ابحث عن زيادة غير طبيعية في النشاط حول am_proc_died وam_proc_start خلال فترة زمنية قصيرة.

الذاكرة

نظرًا لأنّ أجهزة Android غالبًا ما تكون ذاكرتها الفعلية محدودة، فإنّ إدارة ذاكرة الوصول العشوائي (RAM) أمر بالغ الأهمية. تحتوي تقارير الأخطاء على عدة مؤشرات تدل على انخفاض الذاكرة، بالإضافة إلى dumpstate الذي يوفّر لقطة للذاكرة.

تحديد مشكلة نقص الذاكرة

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

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

عرض المؤشرات السابقة

يشير الإدخال am_low_memory في سجلّ أحداث النظام الثنائي إلى أنّ آخر عملية مخزّنة مؤقتًا قد توقّفت. بعد ذلك، يبدأ النظام في إيقاف الخدمات.

عرض مؤشرات التقطيع

تشمل المؤشرات الأخرى على حدوث تعارض في النظام (مثل التقسيم إلى صفحات والاسترداد المباشر وما إلى ذلك) استهلاك الدورات kswapd وkworker وmmcqd. (يُرجى العِلم أنّ تقرير الأخطاء الذي يتم جمعه يمكن أن يؤثّر في مؤشرات التبديل السريع بين التطبيقات.)

يمكن أن توفّر سجلّات أخطاء ANR نبذة مشابهة عن الذاكرة.

الحصول على لقطة من الذكريات

لقطة الذاكرة هي dumpstate تسرد عمليات Java والأصلية قيد التشغيل (للاطّلاع على التفاصيل، يُرجى الرجوع إلى عرض عمليات تخصيص الذاكرة الإجمالية). يُرجى العِلم أنّ اللقطة تقدّم الحالة فقط في لحظة معيّنة، وقد يكون النظام في حالة أفضل (أو أسوأ) قبل اللقطة.

عمليات البث

تنشئ التطبيقات عمليات بث لإرسال الأحداث داخل التطبيق الحالي أو إلى تطبيق آخر. تُسجِّل أدوات معالجة الرسائل المعلَنة اشتراكها في رسائل محدّدة (عبر الفلاتر)، ما يتيح لها الاستماع إلى الرسالة المعلَنة والردّ عليها. تحتوي تقارير الأخطاء على معلومات حول الرسائل الإذاعية المرسَلة وغير المرسَلة، بالإضافة إلى dumpsys لجميع أجهزة الاستقبال التي تستمع إلى رسالة إذاعية معيّنة.

عرض البث المباشر السابق

عمليات البث السابقة هي تلك التي تم إرسالها من قبل، وهي مُدرَجة بترتيب زمني عكسي.

يتضمّن قسم الملخّص نظرة عامة على آخر 300 عملية بث في المقدّمة وآخر 300 عملية بث في الخلفية.

يحتوي قسم التفاصيل على معلومات كاملة عن آخر 50 عملية بث في المقدّمة وآخر 50 عملية بث في الخلفية، بالإضافة إلى أجهزة الاستقبال لكل عملية بث. أجهزة الاستقبال التي تتضمّن ما يلي:

  • يتم تسجيل إدخال BroadcastFilter في وقت التشغيل ويتم إرساله فقط إلى العمليات التي يتم تشغيلها حاليًا.
  • يتم تسجيل إدخال ResolveInfo من خلال إدخالات البيان. يبدأ ActivityManager عملية كل ResolveInfo إذا لم تكن قيد التشغيل.

عرض البث المباشر النشط

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

عرض أدوات معالجة الأحداث في البث

للاطّلاع على قائمة بأجهزة الاستقبال التي تستمع إلى بث، راجِع جدول محلّل أجهزة الاستقبال في dumpsys activity broadcasts. يعرض المثال التالي جميع أجهزة الاستقبال التي تستمع إلى USER_PRESENT.

تزايد الطلب على دالة الاستبعاد المتبادل

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

في سجلّ النظام:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

في سجلّ الأحداث:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

التجميع في الخلفية

يمكن أن تكون عملية التجميع مكلفة وتؤدي إلى إبطاء الجهاز.

قد تتم عملية التجميع في الخلفية أثناء تنزيل تحديثات "متجر Google Play". في هذه الحالة، تظهر الرسائل من تطبيق "متجر Google Play" (finsky) والرسائل installd قبل الرسائل dex2oat.

قد يحدث التجميع أيضًا في الخلفية عند تحميل تطبيق لملف dex لم يتم تجميعه بعد. في هذه الحالة، لن يظهر لك تسجيل finsky أو installd.

السرد

يتطلّب تحديد تسلسل الأحداث المتعلقة بمشكلة معيّنة (كيف بدأت، وماذا حدث، وكيف تفاعل النظام) توفّر جدول زمني دقيق للأحداث. يمكنك استخدام المعلومات الواردة في تقرير الخطأ لمزامنة المخططات الزمنية في سجلات متعددة وتحديد الطابع الزمني الدقيق لتقرير الخطأ.

مزامنة المخططات الزمنية

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

تكون الطوابع الزمنية لسجلّ النظام والأحداث في المنطقة الزمنية نفسها التي يستخدمها المستخدم (كما هو الحال مع معظم الطوابع الزمنية الأخرى). على سبيل المثال، عندما ينقر المستخدم على زر الشاشة الرئيسية، يسجّل سجلّ النظام ما يلي:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

بالنسبة إلى الإجراء نفسه، يسجّل سجلّ الأحداث ما يلي:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

تستخدم سجلات النواة (dmesg) أساسًا زمنيًا مختلفًا، حيث يتم وضع علامة على عناصر السجلّات بالثواني منذ اكتمال برنامج التشغيل. لتسجيل هذا المقياس الزمني في مقاييس زمنية أخرى، ابحث عن الرسالتَين تعليق الخروج وتعليق الدخول:

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

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

تحديد وقت إنشاء تقرير الخطأ

لتحديد وقت إنشاء تقرير الأخطاء، تحقَّق أولاً من سجلّ النظام (Logcat) بحثًا عن dumpstate: begin:

10-03 17:19:54.322 19398 19398 I dumpstate: begin

بعد ذلك، تحقَّق من الطوابع الزمنية لسجلّ النواة (dmesg) للرسالة Starting service 'bugreport':

<5>[207064.285315] init: Starting service 'bugreport'...

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

الطاقة

يحتوي سجلّ الأحداث على حالة طاقة الشاشة، حيث يشير الرقم 0 إلى إيقاف تشغيل الشاشة، ويشير الرقم 1 إلى تشغيل الشاشة، ويشير الرقم 2 إلى إكمال عملية Keyguard.

تحتوي تقارير الأخطاء أيضًا على إحصاءات حول أقفال التنشيط، وهي آلية يستخدمها مطوّرو التطبيقات للإشارة إلى أنّ تطبيقاتهم تحتاج إلى أن يظل الجهاز نشطًا. (لمزيد من التفاصيل حول عمليات قفل التنشيط، يُرجى الرجوع إلى PowerManager.WakeLock وإبقاء وحدة المعالجة المركزية قيد التشغيل).

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

للحصول على مزيد من المساعدة في عرض حالة الطاقة بشكل مرئي، استخدِم Battery Historian، وهي أداة مفتوحة المصدر من Google لتحليل التطبيقات التي تستهلك البطارية باستخدام ملفات تقارير الأخطاء في Android.

إدارة الحِزم

يحتوي القسم DUMP OF SERVICE package على إصدارات التطبيق (وغيرها من المعلومات المفيدة).

العمليات

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

تحديد مدة تشغيل العملية

يحتوي قسم procstats على إحصاءات كاملة حول مدة تشغيل العمليات والخدمات المرتبطة بها. للحصول على ملخّص سريع وسهل القراءة، ابحث عن AGGREGATED OVER لعرض البيانات من آخر ثلاث ساعات أو 24 ساعة، ثم ابحث عن Summary: لعرض قائمة العمليات ومدة تشغيلها بمستويات أولوية مختلفة ومقدار استخدامها لذاكرة الوصول العشوائي (RAM) بتنسيق الحد الأدنى-المتوسط-الحد الأقصى لـ PSS/الحد الأدنى-المتوسط-الحد الأقصى لـ USS.

أسباب تشغيل عملية

يسرد القسم dumpsys activity processes جميع العمليات الجارية حاليًا مرتّبة حسب نتيجة oom_adj (يشير نظام التشغيل Android إلى أهمية العملية من خلال منحها قيمة oom_adj، ويمكن أن يحدّثها ActivityManager ديناميكيًا). تكون النتيجة مشابهة للقطة ذاكرة ولكنها تتضمّن معلومات إضافية حول سبب تشغيل العملية. في المثال أدناه، تشير الإدخالات المكتوبة بخط غليظ إلى أنّ العملية gms.persistent تعمل بالأولوية vis (مرئية) لأنّ عملية النظام مرتبطة بـ NetworkLocationService.

عمليات الفحص

اتّبِع الخطوات التالية لتحديد التطبيقات التي تجري عمليات فحص مفرطة باستخدام تقنية البلوتوث المنخفض الطاقة (BLE):

  • ابحث عن رسائل السجلّ الخاصة بـ BluetoothLeScanner:
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • ابحث عن معرّف العملية في رسائل السجلّ. في هذا المثال، يشير الرقم "24840" إلى معرّف العملية (PID)، ويشير الرقم "24851" إلى معرّف السلسلة (TID).
  • ابحث عن التطبيق المرتبط بمعرّف العملية (PID):
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    في هذا المثال، اسم الحزمة هو com.badapp.

  • ابحث عن اسم الحزمة على Google Play لتحديد التطبيق المسؤول: https://play.google.com/store/apps/details?id=com.badapp.

ملاحظة: بالنسبة إلى الأجهزة التي تعمل بالإصدار 7.0 من نظام التشغيل Android، يجمع النظام بيانات عمليات البحث عن الأجهزة القريبة عبر البلوتوث المنخفض الطاقة (BLE) ويربط هذه الأنشطة بالتطبيق الذي بدأها. لمزيد من التفاصيل، يُرجى الاطّلاع على مقالة عمليات الفحص باستخدام تقنية Low Energy (LE)‎ وBluetooth.