توفّر هذه الصفحة مساعدة في تحديد المشاكل وحلّها وإجابات عن الأسئلة الشائعة حول استخدام تطبيق Crashlytics. إذا لم تتمكّن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية، يُرجى التواصل مع فريق دعم Firebase.
الإجراءات العامّة لتحديد المشاكل وحلّها/الأسئلة الشائعة
عرض تنسيقات مختلفة
(وأحيانًا "خيارات مختلفة") لبعض المشاكل في جدول المشاكل
قد تلاحظ تنسيقَين مختلفَين للمشاكل المُدرَجة في جدول المشاكل ضمن "وحدة تحكُّم Firebase". وقد تلاحظ أيضًا ميزة تسمى
"المتغيرات" داخل بعض مشكلاتك. هذا هو السبب!
في أوائل عام 2023، طرحنا محرّك تحليل محسّنًا لتجميع الأحداث،
بالإضافة إلى تصميم معدَّل وبعض الميزات المتقدّمة للمشاكل الجديدة (مثل
الصيغ المختلفة). يمكنك الاطّلاع على مشاركة المدونة الأخيرة لمعرفة كل التفاصيل، ولكن يمكنك الاطّلاع أدناه على أهم التفاصيل.
يحلِّل Crashlytics جميع الأحداث الواردة في تطبيقك (مثل الأعطال وغير الفادحة وأخطاء ANR) وينشئ مجموعات من الأحداث تُسمى المشاكل. جميع الأحداث في إحدى المشاكل لديها نقطة عطل شائعة.
لتجميع الأحداث في هذه المشاكل، يفحص محرّك التحليل المحسَّن الآن العديد من جوانب الحدث، بما في ذلك الإطارات في تتبُّع تسلسل استدعاء الدوال البرمجية ورسالة الاستثناء ورمز الخطأ وخصائص النظام الأساسي أو نوع الخطأ الأخرى.
ومع ذلك، ضمن هذه المجموعة من الأحداث، قد تختلف عمليات تتبُّع تسلسل استدعاء الدوال البرمجية
التي تؤدي إلى الفشل. قد يؤدي تتبُّع تسلسل استدعاء الدوال البرمجية المختلف إلى سبب جذري مختلف.
لتمثيل هذا الاختلاف المحتمل ضمن مشكلة معيّنة، ننشئ الآن صيغًا مختلفة ضمن المشاكل، حيث يكون كل صيغة عبارة عن مجموعة فرعية من الأحداث في مشكلة لها نقطة الفشل نفسها وتتبُّع تسلسل استدعاء الدوال البرمجية مشابهًا. باستخدام الصيغ، يمكنك تصحيح الأخطاء في عمليات تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن المشكلة وتحديد ما إذا كانت الأسباب الأساسية المختلفة هي التي تؤدي إلى حدوث العطل.
إليك ما ستختبره مع هذه التحسينات:
تعديل البيانات الوصفية المعروضة في صف المشكلة أصبح من السهل الآن فهم المشاكل وتصنيفها في تطبيقك.
مشاكل أقل تكرارًا لا يؤدي تغيير رقم الأسطر إلى مشكلة جديدة.
تصحيح الأخطاء بسهولة أكبر للمشاكل المعقّدة ذات الأسباب الأساسية المختلفة استخدِم الصيغ لتصحيح الأخطاء في عمليات تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن المشكلة.
تنبيهات وإشارات أكثر فائدة تمثّل المشكلة الجديدة خطأً جديدًا.
ميزات بحث أكثر فعالية تحتوي كل مشكلة على بيانات وصفية أكثر قابلية للبحث،
مثل نوع الاستثناء واسم الحزمة.
في ما يلي طريقة طرح هذه التحسينات:
عندما نتلقّى أحداثًا جديدة من تطبيقك، سنتحقّق مما إذا كانت تتطابق مع مشكلة حالية.
وإذا لم يكن هناك أي تطابق، سنطبق تلقائيًا خوارزمية تجميع الأحداث
الأكثر ذكاءً على الحدث وننشئ مشكلة جديدة مع تصميم
بيانات التعريف المجدَّد.
وهذا هو التعديل الكبير الأول الذي نُجريه على تصنيف الأحداث في مجموعاتنا. إذا كانت لديك
ملاحظات أو واجهت أي مشاكل، يُرجى إعلامنا بها من خلال
تقديم بلاغ.
عدم ظهور
مقاييس خالية من الأعطال و/أو تنبيهات السرعة
إذا لم تظهر لك مقاييس خالية من الأعطال (مثل الجلسات والمستخدمين الذين لم تحدث أعطال لهم)
و/أو تنبيهات السرعة، تأكَّد من استخدام
الإصدار 18.6.0 SDK من Crashlytics أو الإصدارات الأحدث (أو الإصدارات الأحدث من Firebase BoM v32.6.0)
عدم ظهور سجلات شريط التنقُّل
إذا لم تظهر لك سجلّات شريط التنقّل، ننصحك بالتحقق من إعدادات تطبيقك لخدمة "إحصاءات Google".
يجب الحرص على استيفاء المتطلبات التالية:
تأكَّد بشكل خاص من أنّك تستخدم على الأقل الإصدار التالي من
حزمة تطوير البرامج (SDK) لمنصة Firebase لبرنامج "إحصاءات Google": Android: الإصدار 17.2.3 والإصدارات الأحدث(BoM v24.7.1 والإصدارات الأحدث)
لماذا يتم الإبلاغ عن أخطاء ANR
فقط للإصدار 11 من نظام التشغيل Android والإصدارات الأحدث؟
يتوافق تطبيق Crashlytics مع تقارير أخطاء ANR لتطبيقات Android على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android والإصدارات الأحدث. إنّ واجهة برمجة التطبيقات الأساسية التي نستخدمها لجمع أخطاء ANR
(getختارProcessExitDurations)
أكثر موثوقية من الأساليب المستندة إلى SIGQUIT أو أسلوب المراقبة. تتوفّر واجهة برمجة التطبيقات هذه
فقط على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android والإصدارات الأحدث.
لماذا لا تحتوي بعض أخطاء ANR
على أخطاء BuildId الخاصة بها؟
إذا كانت بعض أخطاء ANR لا تتضمّن أخطاء BuildId، يمكنك تحديد المشاكل وحلّها على النحو التالي:
تأكَّد من أنّك تستخدم إصدارًا محدّثًا من المكوّن الإضافي Crashlytics لنظام التشغيل Android SDK ومكوّن Crashlytics Gradle.
إذا لم تتوفّر BuildIds في نظام التشغيل Android 11 وبعض أخطاء ANR التي تحدث في Android 12،
من المرجّح أنّك تستخدم إصدارًا قديمًا من حزمة تطوير البرامج (SDK) أو مكوّن Gradle الإضافي أو كليهما.
لجمع أخطاء BuildId بشكل صحيح لأخطاء ANR هذه، عليك استخدام الإصدارات التالية:
الإصدار 18.3.5 أو الإصدارات الأحدث من حزمة تطوير البرامج (SDK) لنظام التشغيل Android من Crashlytics (الإصدار 31.2.2 أو الإصدارات الأحدث من Firebase BoM)
الإصدار 2.9.4 أو الأحدث من المكوّن الإضافي Crashlytics Gradle
التحقّق مما إذا كنت تستخدم موقعًا جغرافيًا غير عادي للمكتبات المشتركة
إذا كنت تفتقد فقط BuildId للمكتبات المشتركة في تطبيقك، من المحتمل أنّك لا تستخدم الموقع التلقائي العادي للمكتبات المشتركة. وفي هذه الحالة، قد لا يتمكن تطبيق Crashlytics من تحديد موقع رموز BuildId المرتبطة. نقترح أن تفكر في استخدام الموقع
القياسي للمكتبات المشتركة.
تأكَّد من عدم إزالة BuildId أثناء عملية التصميم.
يُرجى العلم أنّ النصائح التالية لتحديد المشاكل وحلّها تنطبق على كلٍّ من أخطاء ANR والأعطال الأصلية.
تحقق من وجود BuildId عن طريق تشغيل readelf -n على برامجك الثنائية. إذا لم يتم توفير BuildId، أضِف السمة -Wl,--build-id إلى العلامات في نظام الإنشاء.
تأكد من عدم إزالة BuildId عن غير قصد في محاولة لخفض حجم APK.
إذا احتفظت بإصدارات مكتبة لم تتم إزالتها أو إزالتها، تأكد من
الإشارة إلى الإصدار الصحيح في التعليمات البرمجية.
الاختلافات بين تقارير أخطاء ANR في لوحة بيانات Crashlytics وGoogle Play Console
قد يكون هناك عدم تطابق بين عدد أخطاء ANR بين Google Play وCrashlytics. وهذا أمرٌ متوقّع بسبب الاختلاف في آلية جمع بيانات ANR والإبلاغ عنها. يبلغ Crashlytics عن أخطاء ANR عند بدء تشغيل التطبيق
في المرة التالية، فيما ترسل "مؤشرات Android الحيوية" بيانات ANR بعد حدوث خطأ ANR.
بالإضافة إلى ذلك، لا يعرض تطبيق Crashlytics سوى أخطاء ANR التي تحدث على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android أو الإصدارات الأحدث، وذلك مقارنةً بمنصّة Google Play التي تعرض أخطاء ANR من الأجهزة التي تم قبول
"خدمات Google Play" وموافقتها على جمع البيانات.
الاختلافات بين عمليات تتبُّع تسلسُل استدعاء الدوال البرمجية لـ NDK في لوحة بيانات Crashlytics وأداة Logcat
إنّ سلاسل أدوات LLVM وGNU لها قيم تلقائية وأساليب معالجة مختلفة لشريحة القراءة فقط الخاصة بالبرامج الثنائية في تطبيقك، ما قد يؤدي إلى إنشاء عمليات تتبُّع تسلسل استدعاء الدوال البرمجية غير متّسقة في "وحدة تحكُّم Firebase". للتخفيف من ذلك، أضف علامات الرابط التالية
إلى عملية التصميم:
إذا كنت تستخدم رابط lld من سلسلة أدوات LLVM، أضِف ما يلي:
-Wl,--no-rosegment
إذا كنت تستخدم رابط ld.gold من سلسلة أدوات GNU، أضِف:
-Wl,--rosegment
إذا كنت لا تزال ترى تناقضات في تتبع تسلسل استدعاء الدوال البرمجية (أو إذا لم تكن أي من العلامتين ملائمتين لسلسلة الأدوات)، جرِّب إضافة ما يلي إلى عملية التصميم بدلاً من ذلك:
-fno-omit-frame-pointer
كيف يمكنني استخدام البرنامج الثنائي الخاص بمنشئ ملف رموز Breakpad لـ NDK؟
يضمّ المكوّن الإضافي Crashlytics أداة إنشاء ملفات رموز Breakpad المخصّصة.
إذا كنت تفضّل استخدام البرنامج الثنائي لإنشاء ملفات رموز Breakpad (على سبيل المثال، إذا كنت تفضّل إنشاء جميع الملفات القابلة للتنفيذ الأصلية في سلسلة الإصدار من المصدر)، استخدِم سمة الإضافة symbolGeneratorBinary الاختيارية لتحديد
المسار إلى الملف التنفيذي.
لماذا تظهر لي أعطال في ملفات .kt المصنّفة على أنّها مشاكل .java؟
عند استخدام أحد التطبيقات أداة تشويش لا يعرض امتداد الملف،
ينشئ Crashlytics كل مشكلة بامتداد الملف .java تلقائيًا.
حتى يتمكن Crashlytics من حدوث مشاكل باستخدام امتداد الملف الصحيح،
تأكد من أن تطبيقك يستخدم الإعداد التالي:
يستخدم Android Gradle 4.2.0 أو الإصدارات الأحدث
يتم استخدام R8 مع تفعيل ميزة التشويش. لتحديث تطبيقك إلى الإصدار R8، يُرجى اتّباع هذه
المستندات.
تجدر الإشارة إلى أنّه بعد التعديل إلى الإعداد الموضّح أعلاه، قد تبدأ في ظهور مشاكل جديدة في .kt هي نُسخ طبق الأصل من مشاكل .java الحالية. راجِع الأسئلة الشائعة لمعرفة المزيد عن هذه الحالة.
لماذا تظهر لي
مشاكل .kt مكرّرة من مشاكل
.java الحالية؟
اعتبارًا من منتصف شهر كانون الأول (ديسمبر) 2021، حسّنت خدمة Crashlytics توافق التطبيقات
التي تستخدم لغة Kotlin.
حتى وقت قريب، لم تعرض برامج التشويش المتاحة امتداد الملف، لذلك
أنشأ Crashlytics كل مشكلة تلقائيًا بامتداد الملف .java.
ومع ذلك، فاعتبارًا من الإصدار 4.2.0 من Android Gradle 4.2.0، ستدعم R8 امتدادات الملفات.
بفضل هذا التحديث، أصبح بإمكان Crashlytics الآن تحديد ما إذا كانت كل فئة مستخدَمة داخل التطبيق مكتوبة بلغة Kotlin وتضمين اسم الملف الصحيح في توقيع المشكلة. يتم الآن نسب الأعطال بشكل صحيح إلى ملفات .kt (حسب الاقتضاء)
إذا كان تطبيقك يتضمن الإعداد التالي:
يستخدم تطبيقك الإصدار 4.2.0 من نظام Gradle المتوافق مع Android أو الإصدارات الأحدث.
يستخدم تطبيقك الإصدار R8 مع تفعيل ميزة التشويش.
بما أنّ الأعطال الجديدة تتضمّن الآن امتداد الملف الصحيح في توقيعات المشاكل،
قد تظهر لك مشاكل .kt جديدة هي في الواقع نسخة مكرّرة من
مشاكل حالية من تصنيف .java. من خلال "وحدة تحكُّم Firebase"، سنحاول تحديد
ما إذا كانت مشكلة .kt جديدة هي تكرار محتمل لمشكلة حالية من تصنيف .java.
مَن يمكنه الاطّلاع على الملاحظات المتعلقة بالمشكلة وكتابتها وحذفها؟
تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات محددة بشأن الأسئلة
وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها بعنوان البريد الإلكتروني لحسابه على Google. يكون عنوان البريد الإلكتروني هذا مرئيًا مع الملاحظة لجميع أعضاء
المشروع الذين لديهم إمكانية الوصول لعرض الملاحظة.
يوضّح ما يلي إذن الوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات
الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
مَن يمكنه الاطّلاع على الملاحظات المتعلقة بالمشكلة وكتابتها وحذفها؟
تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات محددة بشأن الأسئلة
وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها بعنوان البريد الإلكتروني لحسابه على Google. يكون عنوان البريد الإلكتروني هذا مرئيًا مع الملاحظة لجميع أعضاء
المشروع الذين لديهم إمكانية الوصول لعرض الملاحظة.
يوضّح ما يلي إذن الوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات
الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
يستخدم التطبيق أيضًا
"SDK لإعلانات Google على الأجهزة الجوّالة" ولكن لا يواجه أعطالاً
إذا كان مشروعك يستخدم Crashlytics مع "حزمة تطوير البرامج (SDK) لإعلانات Google على الأجهزة الجوّالة"،
من المحتمل أن يتداخل معلّوو الأعطال عند تسجيل معالِجات الاستثناء. لإصلاح المشكلة، يمكنك إيقاف إعداد تقارير الأعطال في "حزمة SDK لإعلانات الأجهزة الجوّالة" من خلال طلب الرقم disableSDKCrashReporting.
أين توجد مجموعة بيانات BigQuery؟
بعد ربط Crashlytics بأداة BigQuery، يتم تلقائيًا وضع مجموعات البيانات الجديدة التي تنشئها في الولايات المتحدة، بغض النظر عن موقع مشروع Firebase.
دعم النظام الأساسي
هل يتوافق تطبيق Crashlytics مع لعبة armeabi؟
لا يتوافق ملف Firebase Crashlytics NDK مع تقنية ARMv5 (armeabi).
تمت إزالة واجهة التطبيق الثنائية (ABI) هذه اعتبارًا من NDK r17.
المشاكل المتراجعة
ما المشكلة المتراجعة؟
حدث تراجع في حجم المشكلة بعد أن أغلقتها سابقًا،
ولكن تلقّى Crashlytics تقريرًا جديدًا يفيد بأنّ المشكلة قد تكرّرت.
يعيد Crashlytics تلقائيًا فتح هذه المشاكل التي تراجعت حتى تتمكن من
معالجتها بما يناسب تطبيقك.
إليك مثال على سيناريو يشرح كيفية تصنيف Crashlytics لمشكلة على أنّها انحدار:
ولأول مرة على الإطلاق، يحصل Crashlytics على تقرير أعطال حول Crash
"A". يفتح Crashlytics مشكلة مقابلة لذلك العُطل (المشكلة "أ").
يمكنك إصلاح هذا الخطأ بسرعة، وإغلاق المشكلة "أ"، ثم طرح إصدار جديد
من تطبيقك.
يتلقّى Crashlytics تقريرًا آخر حول المشكلة "أ" بعد إغلاقها.
إذا كان التقرير صادرًا عن إصدار تطبيق عرفه تطبيق Crashlytics عند إغلاق المشكلة (ما يعني أنّ الإصدار أرسل تقرير أعطال لأي تعطُّل على الإطلاق)، لن يعتبر Crashlytics المشكلة على أنّها تراجعت. ستبقى المشكلة مغلقة.
إذا كان التقرير صادرًا من إصدار تطبيق لم
يلم تطبيق Crashlytics عند إغلاق المشكلة (ما يعني أنّ الإصدار
لم يرسل أي تقرير أعطال بسبب أي تعطُّل على الإطلاق)، يعتبر Crashlytics أنّ المشكلة انحدارت وستتم إعادة فتح المشكلة.
عند انحدار مشكلة، نرسل تنبيه رصد تراجع ونضيف إشارة انحدار إلى المشكلة لإعلامك بأنّ Crashlytics
قد أعادت فتح المشكلة. إذا كنت لا تريد إعادة فتح مشكلة ما بسبب
خوارزمية الانحدار، يمكنك "كتم صوت" المشكلة بدلاً من إغلاقها.
لماذا ألاحظ مشاكل تراجعية
في إصدارات التطبيق القديمة؟
إذا كان التقرير من إصدار قديم من التطبيق لم يرسل أي تقارير أعطال مطلقًا
عند إغلاق المشكلة، يعتبر Crashlytics أنّ المشكلة تراجعت وستُعيد فتحها.
يمكن أن يحدث هذا الموقف في الحالات التالية: بعد أن أصلحت خطأً وأصدرت إصدارًا جديدًا من تطبيقك، لا يزال لديك مستخدمون لإصدارات قديمة من تطبيقك بدون إصلاح الخطأ. إذا تم، مصادفة، أن أحد هذه الإصدارات القديمة لم يرسل أي تقارير أعطال على الإطلاق عند إغلاق المشكلة، وبدأ هؤلاء المستخدمون في مواجهة الخطأ، فستؤدي تقارير الأعطال هذه إلى حدوث مشكلة تراجُع.
إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار، فيمكنك "كتم صوت" المشكلة بدلاً من إغلاقها.