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

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

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

لوجكات

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

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

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

تتضمن مستويات السجل ما يلي:

  • الخامس: مطول
  • د: التصحيح
  • انا: معلومات
  • ث: تحذير
  • ه: خطأ

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

ANRs والجمود

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

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

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

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

البحث عن آثار المكدس

يمكنك غالبًا العثور على تتبعات المكدس التي تتوافق مع ANR. تأكد من أن الطابع الزمني ومعرف PID الموجود على تتبعات VM يتطابقان مع ANR الذي تبحث عنه، ثم تحقق من السلسلة الرئيسية للعملية. تذكر:

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

البحث عن الجمود

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

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

للعثور على حالات توقف تام، تحقق من أقسام تتبع VM بحثًا عن نمط من الخيط A ينتظر شيئًا مثبتًا بواسطة الخيط B، والذي بدوره ينتظر شيئًا مثبتًا بواسطة الخيط A.

أنشطة

النشاط هو أحد مكونات التطبيق الذي يوفر للمستخدمين شاشة يتفاعلون معها للقيام بشيء مثل طلب رقم، أو التقاط صورة، أو إرسال بريد إلكتروني، وما إلى ذلك. ومن منظور تقرير الأخطاء، فإن النشاط هو شيء واحد مركّز يمكن للمستخدم القيام به ، مما يجعل تحديد موقع النشاط الذي تم التركيز عليه أثناء التعطل أمرًا مهمًا للغاية. تعمل الأنشطة (عبر 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 إذا لم يكن قيد التشغيل بالفعل.

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

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

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

لعرض قائمة بأجهزة الاستقبال التي تستمع للبث، تحقق من جدول محلل جهاز الاستقبال في 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 .

رواية

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

مزامنة الجداول الزمنية

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

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

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]

تستخدم سجلات Kernel ( 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 المنطقة الزمنية UTC ويجب تعديلها وفقًا للمنطقة الزمنية للمستخدم.

تحديد وقت الإبلاغ عن الأخطاء

لتحديد متى تم التقاط تقرير الأخطاء، تحقق أولاً من سجل النظام (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 واحتفظ بوحدة المعالجة المركزية قيد التشغيل .)

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

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

الحزم

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

العمليات

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

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

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

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

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

المسح

استخدم الخطوات التالية لتحديد التطبيقات التي تقوم بإجراء عمليات فحص زائدة لتقنية Bluetooth منخفضة الطاقة (BLE):

  • ابحث عن رسائل السجل الخاصة بـ BluetoothLeScanner :
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • حدد موقع PID في رسائل السجل. في هذا المثال، "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 .

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