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

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

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

أداة Logcat

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

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

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

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

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

 

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

أخطاء ANR والحالات المتأثّرة بالانقطاعات

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

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

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

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

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

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

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

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

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

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

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

الأنشطة

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

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

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

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

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

تحديد ما إذا كان الجهاز يواجه تعذُّرًا في معالجة البيانات

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

الذاكرة

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

تحديد سعة الذاكرة المنخفضة

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

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

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

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

عرض مؤشرات التوقّف المؤقت

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

يمكن أن تقدّم سجلات ANR لمحة مشابهة عن الذاكرة.

الحصول على لقطة ذاكرة

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

عمليات البث

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

عرض البثّات السابقة

البثّات السابقة هي تلك التي تم إرسالها، ويتم عرضها في الترتيب الزمني العكسي.

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

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

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

عرض البثّات النشطة

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

عرض مستمعي البث

لعرض قائمة بالمستلمين الذين يستمعون إلى بثّ، اطّلِع على جدول Receiver Resolver في 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.

السرد

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

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

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

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

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

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

تحديد وقت إعداد تقرير الخطأ

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

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

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

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

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

الطاقة

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

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

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

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

إدارة الحِزم

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

العمليات

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

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

يحتوي قسم procstats على إحصاءات كاملة عن مدّة تنفيذ العمليات والخدمات المرتبطة بها. للحصول على ملخّص سريع وسهل القراءة، ابحث عن AGGREGATED OVER لعرض البيانات من آخر ثلاث ساعات أو 24 ساعة، ثم ابحث عن Summary: لعرض قائمة بالعمليات ومدة تنفيذ هذه العمليات بأولويات مختلفة واستخدامهم لذاكرة الوصول العشوائي بالتنسيق min-average-max PSS/min-average-max 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" و "24851" هما معرّف العملية (PID) ومعرّف السلسلة (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، يجمع النظام بيانات عمليات البحث عن الأجهزة التي تتضمّن بلوتوث منخفض الطاقة ويربط هذه الأنشطة بالتطبيق الذي بدأ عملية البحث. لمعرفة التفاصيل، يُرجى الاطّلاع على مقالة عمليات البحث في Bluetooth وتقنية Bluetooth Low Energy (LE).