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

الأخطاء هي حقيقة واقعة في أي نوع من التطوير - وتكون تقارير الأخطاء بالغ الأهمية لتحديد المشكلات وحلها. دعم جميع إصدارات Android تسجيل تقارير الأخطاء باستخدام Android Debug Bridge (adb); يدعم الإصدار 4.2 من نظام التشغيل Android والإصدارات الأحدث المطوّر خيار لتسجيل تقارير الأخطاء ومشاركتها عبر البريد الإلكتروني و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: تصحيح الأخطاء
  • ط: المعلومات
  • W: تحذير
  • E: خطأ

 

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

أخطاء ANR وحالات التوقف المؤقت

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

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

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

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

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

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

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

العثور على الأقفال وإصلاحها

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

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

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

الأنشطة

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

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

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

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

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

تحديد ما إذا كان الجهاز يتعطل

لتحديد ما إذا كان الجهاز thrashing، تحقّق من الزيادة غير الطبيعية في النشاط عند الساعة 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]

تستخدم سجلّات النواة (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

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

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

لتحديد وقت تسجيل تقرير الأخطاء، تحقَّق أولاً من سجلّ النظام (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 مخصص لقفل المفاتيح.

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

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

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

الطرود

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

العمليات

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

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

يحتوي القسم "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
    
  • تحديد موقع PID في رسائل السجل في هذا المثال، "24840" أو "24851" هما PID (معرّف العملية) وTID (رقم تعريف سلسلة التعليمات).
  • حدِّد موقع التطبيق المرتبط بمعرّف PID:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

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

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

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