تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

تحديد المشاكل وحلّها في Crashlytics والأسئلة الشائعة بشأنها

تقدّم هذه الصفحة مساعدة في تحديد المشاكل وحلّها وإجابات عن الأسئلة الشائعة حول استخدام Crashlytics. إذا لم تتمكّن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية، يُرجى التواصل مع فريق دعم Firebase.

تحديد المشاكل وحلّها/الأسئلة الشائعة

ظهور تنسيقات مختلفة (وأحيانًا "خيارات") لبعض المشاكل في جدول المشاكل

قد تلاحظ تنسيقَين مختلفَين للمشاكل المُدرَجة في جدول المشاكل في وحدة تحكّم Firebase. وقد تلاحظ أيضًا ميزة تُسمى "المتغيرات" ضمن بعض المشاكل. إليك السبب:

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

تُحلّل Crashlytics جميع الأحداث من تطبيقك (مثل الأعطال والأخطاء غير الفادحة وأخطاء ANR) وتنشئ مجموعات من الأحداث تُسمّى المشاكل، إذ تشترك جميع الأحداث في إحدى المشاكل في نقطة تعذُّر مشتركة.

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

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

في ما يلي التغييرات التي ستلاحظها بعد تطبيق هذه التحسينات:

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

إليك طريقة طرح هذه التحسينات:

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

هذا هو التعديل الكبير الأول الذي نجريه على تجميع الأحداث. إذا كان لديك ملاحظات أو واجهت أي مشاكل، يُرجى إعلامنا بذلك من خلال تقديم بلاغ.

عدم ظهور سجلّات شريط التنقل

إذا لم تظهر لك سجلّات مسار التنفيذ (iOS+‎ أو Android أو Flutter أو Unity)، ننصحك بالتحقّق من إعدادات تطبيقك بحثًا عن Google Analytics. يُرجى التأكّد من استيفاء المتطلبات التالية:

لقد فعّلت Google Analytics في مشروعك على Firebase.
لقد فعّلت مشاركة البيانات في Google Analytics. يمكنك الاطّلاع على مزيد من المعلومات عن هذا الإعداد في مقالة إدارة إعدادات مشاركة البيانات في "إحصاءات Google".
أضفت إلى تطبيقك حزمة تطوير البرامج (SDK) لمنصة Firebase لنظام التشغيل Google Analytics: iOS+ | Android | Flutter | Unity.
يجب إضافة حزمة SDK هذه بالإضافة إلى حزمة SDK Crashlytics.
تستخدِم أحدث إصدارات حزمة تطوير البرامج (SDK) من Firebase لجميع المنتجات التي تستخدمها في تطبيقك (iOS+ | Android | Flutter | Unity).

بالنسبة إلى تطبيقات Apple وAndroid، احرص بشكل خاص على استخدام الإصدار التالي على الأقل من حزمة تطوير البرامج (SDK) لمنصة Firebase في Google Analytics: iOS+: الإصدار 6.3.1 أو إصدار أحدث (الإصدار 8.9.0 أو إصدار أحدث لنظامَي التشغيل macOS وtvOS) | Android: الإصدار 17.2.3 أو إصدار أحدث (BoM الإصدار 24.7.1 أو إصدار أحدث).

عدم ظهور تنبيهات السرعة

إذا لم تظهر لك تنبيهات السرعة، تأكَّد من أنّك تستخدم

عدم ظهور مقاييس عدم حدوث أعطال (أو ظهور مقاييس غير موثوقة)

إذا لم تظهر لك مقاييس خالية من الأعطال (مثل المستخدمين والجلسات الخالية من الأعطال) أو ظهرت لك مقاييس غير موثوقة، تحقَّق مما يلي:

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

كيف يتم احتساب عدد المستخدمين الذين لم يواجهوا أي تعطُّل؟

اطّلِع على فهم مقاييس عدم حدوث الأعطال.

مَن يمكنه الاطّلاع على الملاحظات وكتابتها وحذفها في إحدى المشاكل؟

تتيح الملاحظات لأعضاء المشروع التعليق على مشاكل معيّنة من خلال طرح أسئلة أو تقديم معلومات عن الحالة أو غير ذلك.

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

في ما يلي وصف لأذونات الوصول المطلوبة لعرض الملاحظات وكتابتها وحذفها:

يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات الحالية وحذفها وكتابة ملاحظات جديدة بشأن مشكلة.
- المالك أو المحرِّر للمشروع، مشرف Firebase، مشرف الجودة، أو مشرف Crashlytics
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات المنشورة بشأن إحدى المشاكل، ولكن لا يمكنهم حذف ملاحظة أو كتابتها.
- مُشاهد المشروع أو مُشاهد Firebase أو مُشاهد الجودة أو مُشاهد Crashlytics

ما هي المشكلة التي تراجعت جودتها؟

تحدث مشكلة متكررة عندما تكون قد أغلقت المشكلة سابقًا ولكن Crashlytics تتلقّى بلاغًا جديدًا يفيد بأنّ المشكلة قد تكررت. تعيد Crashlytics تلقائيًا فتح هذه المشاكل التي تم حلّها سابقًا حتى تتمكّن من معالجتها بما يتناسب مع تطبيقك.

في ما يلي مثال على سيناريو يوضّح كيف تصنّف Crashlytics مشكلة على أنّها تراجع:

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

عندما تتكرّر مشكلة، نرسل تنبيهًا بشأن رصد تكرار المشكلة ونضيف إشارة تكرار إلى المشكلة لإعلامك بأنّ Crashlytics قد أعاد فتح المشكلة. إذا كنت لا تريد إعادة فتح مشكلة بسبب خوارزمية الانحدار، يمكنك "كتم" المشكلة بدلاً من إغلاقها.

لماذا تظهر لي مشاكل متكرّرة في الإصدارات القديمة من التطبيق؟

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

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

إذا كنت لا تريد إعادة فتح مشكلة بسبب خوارزمية التراجع، يمكنك "كتم" المشكلة بدلاً من إغلاقها.

يستخدم التطبيق أيضًا حزمة تطوير البرامج (SDK) الخاصة بـ "Google Mobile Ads"، ولكن لا تحدث أعطال

إذا كان مشروعك يستخدم Crashlytics إلى جانب حزمة SDK الخاصة بـ Google Mobile Ads، من المحتمل أن تتداخل أدوات تسجيل الأعطال عند تسجيل معالجات الاستثناءات. لحلّ المشكلة، أوقِف ميزة "إعداد تقارير الأعطال" في حزمة تطوير البرامج (SDK) الخاصة بـ Mobile Ads من خلال استدعاء disableSDKCrashReporting.

أين تقع مجموعة بيانات BigQuery؟

بعد ربط Crashlytics بحساب BigQuery، سيتم تلقائيًا تخزين مجموعات البيانات الجديدة التي تنشئها في الولايات المتحدة، بغض النظر عن موقع مشروعك على Firebase.

الدعم الخاص بالمنصة

توفّر الأقسام التالية الدعم لتحديد المشاكل وحلّها على مستوى النظام الأساسي والأسئلة الشائعة: iOS+ | Android | Unity.

الأنظمة الأساسية المتوافقة مع Apple

ملفات dSYM غير متوفّرة أو لا يتم تحميلها

لتحميل ملفات dSYM الخاصة بمشروعك والحصول على ناتج تفصيلي، تحقَّق ممّا يلي:

تأكَّد من أنّ مرحلة إنشاء مشروعك تتضمّن Crashlytics run script، ما يتيح لـ Xcode تحميل ملفات dSYM الخاصة بمشروعك في وقت الإنشاء (اطّلِع على بدء Crashlytics للحصول على تعليمات حول إضافة النص البرمجي). بعد تعديل مشروعك، أجبِر التطبيق على التعطُّل وتأكَّد من ظهور العطل في لوحة بيانات Crashlytics.
إذا ظهر لك تنبيه "ملف dSYM غير متوفّر" في وحدة تحكّم Firebase، راجِع Xcode للتأكّد من أنّه ينتج ملفات dSYM بشكل صحيح للإصدار.
إذا كان Xcode ينتج ملفات dSYM بشكل صحيح، ولكن لا يزال يتعذّر عليك العثور على ملفات dSYM، من المحتمل أن تكون أداة "نص البرمجة" معلّقة أثناء تحميل ملفات dSYM. في هذه الحالة، جرِّب أيًّا مما يلي:
- تأكَّد من استخدام أحدث إصدار من Crashlytics.
- حمِّل ملفات dSYM غير المضمّنة يدويًا باتّباع الخطوات التالية:
  - الخيار 1: استخدِم الخيار "السحب والإفلات" المستند إلى وحدة التحكّم في علامة التبويب ملفات dSYM لتحميل أرشيف zip يحتوي على ملفات dSYM الناقصة.
  - الخيار 2: استخدِم برنامج نصي upload-symbols لتحميل ملفات dSYM الناقصة، وذلك لمعرّفات UUID المتوفّرة في علامة التبويب ملفات dSYM.
إذا استمر ظهور ملفات dSYM ناقصة أو لم تنجح عمليات التحميل، يُرجى التواصل مع فريق دعم Firebase وتضمين سجلّاتك.

ترميز عمليات تتبُّع تسلسل استدعاء الدوال البرمجية للأعطال رديء

إذا بدا أنّ رموز تتبُّع تسلسل استدعاء الدوال البرمجية غير متطابقة بشكل جيد، تحقَّق مما يلي:

إذا كانت اللقطات من مكتبة تطبيقك لا تتضمّن مراجع إلى رمز تطبيقك، تأكَّد من عدم ضبط -fomit-frame-pointer كعلامة تجميع.
إذا ظهرت لك عدّة إطارات (Missing) لمكتبة تطبيقك، تحقَّق مما إذا كانت هناك ملفات dSYM اختيارية مُدرَجة على أنّها مفقودة (لإصدار التطبيق المتأثّر) في علامة التبويب Crashlytics ملفات dSYM في Firebase Console. في حال حدوث ذلك، اتّبِع خطوة تحديد المشاكل وحلّها الواردة في قسم "تنبيه بشأن عدم توفّر ملف dSYM" ضمن الأسئلة الشائعة حول عدم توفّر ملفات dSYM أو عدم تحميلها في هذه الصفحة. يُرجى العِلم أنّ تحميل ملفات dSYM هذه لن يؤدي إلى تحويل الأعطال التي حدثت بالفعل إلى رموز، ولكنّه سيساعد في ضمان تحويل الأعطال المستقبلية إلى رموز.

هل يمكنني استخدام Crashlytics لنظام التشغيل macOS أو tvOS؟

نعم، يمكنك تنفيذ Crashlytics في مشاريع macOS وtvOS. احرص على تضمين الإصدار 8.9.0 أو إصدار أحدث من حزمة Firebase SDK الخاصة بـ Google Analytics لكي تتمكّن الأعطال من الوصول إلى المقاييس التي تجمعها Google Analytics (المستخدمون الذين لم يواجهوا أي أعطال، وأحدث إصدار، وتنبيهات السرعة، وسجلات مسار التنفيذ).

هل يمكنني استخدام Crashlytics في مشروع على Firebase يتضمّن عدة تطبيقات على منصات Apple المختلفة؟

يمكنك الآن الإبلاغ عن الأعطال في تطبيقات متعددة ضمن مشروع واحد على Firebase، حتى إذا كانت التطبيقات مصمَّمة لمنصات Apple مختلفة (مثل iOS وtvOS وMac Catalyst). في السابق، كان عليك فصل التطبيقات إلى مشاريع Firebase فردية إذا كانت تحتوي على رقم تعريف الحزمة نفسه.

التوافق مع Android

لماذا يتم تسجيل أخطاء ANR على الإصدار 11 من نظام التشغيل Android والإصدارات الأحدث فقط؟

تتيح Crashlytics إمكانية تسجيل أحداث ANR لتطبيقات Android من الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android والإصدارات الأحدث. إنّ واجهة برمجة التطبيقات الأساسية التي نستخدمها لجمع أخطاء ANR (getHistoricalProcessExitReasons) أكثر موثوقية من الأساليب المستندة إلى SIGQUIT أو مراقبة الأداء. لا تتوفّر واجهة برمجة التطبيقات هذه إلا على أجهزة Android 11 والإصدارات الأحدث.

لماذا لا تتضمّن بعض أخطاء ANR أرقام `BuildId`؟

إذا كانت بعض أخطاء ANR لا تتضمّن BuildId، اتّبِع الخطوات التالية لتحديد المشاكل وحلّها:

تأكَّد من أنّك تستخدم إصدارًا حديثًا من حزمة تطوير البرامج (SDK) لنظام التشغيل Android Crashlytics والمكوّن الإضافي لنظام Gradle.Crashlytics

إذا لم تظهر لك أخطاء BuildId في الإصدار 11 من نظام التشغيل Android وبعض أخطاء ANR في الإصدار 12 من نظام التشغيل Android، من المحتمل أنّك تستخدم حزمة تطوير برامج (SDK) أو مكوّنًا إضافيًا لنظام Gradle أو كليهما قديمَين. لجمع BuildId بشكل صحيح لأخطاء ANR هذه، عليك استخدام الإصدارات التالية:
- ‫Crashlytics Android SDK الإصدار 18.3.5 أو الإصدارات الأحدث (Firebase BoM الإصدار 31.2.2 أو الإصدارات الأحدث)
- Crashlytics الإصدار 2.9.4 أو إصدار أحدث من المكوّن الإضافي لنظام Gradle
تحقَّق مما إذا كنت تستخدم موقعًا جغرافيًا غير عادي لمكتباتك المشتركة.

إذا كانتBuildId فقط هي المفقودة في المكتبات المشتركة لتطبيقك، من المحتمل أنّك لا تستخدم الموقع الجغرافي التلقائي العادي للمكتبات المشتركة. في هذه الحالة، قد لا يتمكّن Crashlytics من تحديد موقع BuildId المرتبط. ننصحك باستخدام الموقع الجغرافي العادي للمكتبات المشتركة.
تأكَّد من عدم إزالة BuildIds أثناء عملية الإنشاء.

يُرجى العِلم أنّ نصائح تحديد المشاكل وحلّها التالية تنطبق على أخطاء ANR والأعطال الأصلية.
- تحقَّق مما إذا كانت BuildId موجودة من خلال تنفيذ readelf -n على الملفات الثنائية. إذا لم تكن BuildId متوفّرة، أضِف -Wl,--build-id إلى العلامات لنظام الإنشاء.
- تأكَّد من أنّك لا تحذف علامات BuildId عن غير قصد في محاولة لتقليل حجم حزمة APK.
- إذا كنت تحتفظ بنسختَين من إحدى المكتبات، إحداهما مضغوطة والأخرى غير مضغوطة، احرص على الإشارة إلى النسخة الصحيحة في الرمز.

الاختلافات بين تقارير أخطاء ANR في لوحة بيانات Crashlytics وGoogle Play Console

قد يحدث عدم تطابق بين عدد أخطاء ANR في Google Play وCrashlytics. وهذا أمر متوقّع بسبب الاختلاف في آلية جمع بيانات ANR والإبلاغ عنها. تسجّل Crashlytics أخطاء ANR عند بدء تشغيل التطبيق في المرة التالية، بينما ترسل "مؤشرات Android الحيوية" بيانات أخطاء ANR بعد حدوثها.

بالإضافة إلى ذلك، لا تعرض Crashlytics إلا أخطاء ANR التي تحدث على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android أو الإصدارات الأحدث، مقارنةً بـ Google Play الذي يعرض أخطاء ANR من الأجهزة التي تتضمّن "خدمات Google Play" وتم قبول الموافقة على جمع البيانات.

لماذا تظهر الأعطال من ملفات `.kt` على أنّها مشاكل `.java`؟

عندما يستخدم تطبيق أداة تشويش لا تعرض امتداد الملف، تنشئ Crashlytics كل مشكلة باستخدام امتداد الملف .java تلقائيًا.

لكي يتمكّن Crashlytics من إنشاء مشاكل باستخدام امتداد الملف الصحيح، تأكَّد من أنّ تطبيقك يستخدم الإعداد التالي:

يستخدم الإصدار 4.2.0 من المكوّن الإضافي لنظام Gradle المتوافق مع Android أو إصدارًا أحدث
يستخدم R8 مع تفعيل التشويش. لتحديث تطبيقك إلى R8، يُرجى الرجوع إلى هذه المستندات.

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

لماذا تظهر لي مشاكل `.kt` مكرّرة من مشاكل `.java` حالية؟

اعتبارًا من منتصف كانون الأول (ديسمبر) 2021، Crashlyticsأصبحنا نوفّر دعمًا محسّنًا للتطبيقات التي تستخدم لغة Kotlin.

حتى وقت قريب، لم تكن أدوات التشويش المتاحة تعرض امتداد الملف، لذا كانت Crashlytics تنشئ كل مشكلة باستخدام امتداد الملف .java تلقائيًا. ومع ذلك، بدءًا من الإصدار 4.2.0 من Android Gradle، يتيح R8 استخدام امتدادات الملفات.

من خلال هذا التحديث، يمكن لأداة Crashlytics الآن تحديد ما إذا كان كل صف مستخدَم في التطبيق مكتوبًا بلغة Kotlin، كما يمكنها تضمين اسم الملف الصحيح في توقيع المشكلة. يتم الآن تحديد مصدر الأعطال بشكل صحيح على أنّه ملف .kt (حسب الاقتضاء) إذا كان تطبيقك يتضمّن الإعداد التالي:

يستخدم تطبيقك الإصدار 4.2.0 من Android Gradle أو إصدارًا أحدث.
يستخدم تطبيقك أداة R8 مع تفعيل ميزة التشويش.

بما أنّ الأعطال الجديدة تتضمّن الآن امتداد الملف الصحيح في تواقيع المشاكل، قد تظهر لك مشاكل جديدة تحمل التصنيف .kt، وهي في الواقع مجرّد نُسخ مكرّرة من المشاكل الحالية التي تحمل التصنيف .java. في وحدة تحكّم Firebase، نحاول تحديد ما إذا كانت مشكلة .kt جديدة هي نسخة مكرّرة محتملة من مشكلة حالية تحمل التصنيف .java، وإبلاغك بذلك.

عدم حدوث أعطال عند استخدام Dexguard

إذا ظهر لك الاستثناء التالي، من المحتمل أنّك تستخدم إصدارًا من DexGuard غير متوافق مع حزمة تطوير البرامج (SDK) Firebase Crashlytics:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

لا يؤدي هذا الاستثناء إلى تعطُّل تطبيقك، ولكنّه يمنعه من إرسال تقارير الأعطال. لحلّ هذه المشكلة، اتّبِع الخطوات التالية:

تأكَّد من استخدام أحدث إصدار من DexGuard 8.x. يحتوي الإصدار الأخير على قواعد تتطلّبها حزمة تطوير البرامج (SDK) الخاصة بـ "Firebase Crashlytics".
إذا كنت لا تريد تغيير إصدار DexGuard، حاوِل إضافة السطر التالي إلى قواعد التشويش (في ملف إعداد DexGuard):
```
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
```

الدعم الخاص بـ Android-NDK

الاختلافات بين تتبُّع تسلسل استدعاء الدوال البرمجية في 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 لتحديد مسار الملف التنفيذي.

يمكنك تحديد مسار البرنامج الثنائي الخاص بأداة إنشاء ملفات رموز Breakpad بإحدى الطريقتين التاليتين:

الخيار 1: تحديد المسار من خلال إضافة firebaseCrashlytics في ملف build.gradle

أضِف ما يلي إلى ملف build.gradle.kts على مستوى التطبيق:

الإصدار 3.0.0 أو الإصدارات الأحدث من المكوّن الإضافي لنظام Gradle

android {
  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        // Add these optional fields to specify the path to the executable
        symbolGeneratorType = "breakpad"
        breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
      }
    }
  }
}

إصدارات المكوّن الإضافي الأقدم

android {
  // ...
  buildTypes {
    // ...
    release {
      // ...
      firebaseCrashlytics {
        // existing; required for either symbol file generator
        nativeSymbolUploadEnabled true
        // Add this optional new block to specify the path to the executable
        symbolGenerator {
          breakpad {
            binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
          }
        }
      }
   }
}

الخيار 2: تحديد المسار من خلال سطر سمة في ملف Gradle properties

يمكنك استخدام السمة com.google.firebase.crashlytics.breakpadBinary لتحديد مسار الملف التنفيذي.

يمكنك تعديل ملف خصائص Gradle يدويًا أو تعديل الملف من خلال سطر الأوامر. على سبيل المثال، لتحديد المسار من خلال سطر الأوامر، استخدِم أمرًا مثل ما يلي:
```
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
  -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
  app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
```

هل تتوافق Crashlytics مع armeabi؟

لا تتوافق حزمة تطوير البرامج (NDK) في Firebase Crashlytics مع ARMv5 (armeabi). تمت إزالة دعم واجهة ABI هذه اعتبارًا من الإصدار 17 من NDK.

دعم Unity

ظهور تتبُّعات تسلسل استدعاء الدوال البرمجية غير المحوَّلة إلى رموز في لوحة بيانات Crashlytics لتطبيقات Android

إذا كنت تستخدم Unity IL2CPP وتظهر لك عمليات تتبُّع تسلسل استدعاء الدوال البرمجية غير مرتبطة برموز، جرِّب ما يلي:

تأكَّد من استخدام الإصدار 8.6.1 أو إصدار أحدث من حزمة تطوير البرامج (SDK) Crashlytics Unity.
تأكَّد من إعداد وتنفيذ الأمر Firebase CLI crashlytics:symbols:upload لإنشاء ملف الرموز وتحميله.

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

هل يمكن استخدام Crashlytics مع التطبيقات التي تستخدم IL2CPP؟

نعم، يمكن Crashlytics عرض عمليات تتبُّع تسلسل استدعاء الدوال البرمجية التي تم تحويلها إلى رموز لتطبيقاتك التي تستخدم IL2CPP. تتوفّر هذه الإمكانية للتطبيقات التي تم إصدارها على نظامَي التشغيل Android أو Apple. في ما يلي الخطوات التي يجب اتّخاذها:

تأكَّد من استخدام الإصدار 8.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) الخاصة بـ Crashlytics Unity.
أكمِل المهام اللازمة لمنصتك:
- بالنسبة إلى تطبيقات منصة Apple: ليس عليك اتّخاذ أي إجراءات خاصة. بالنسبة إلى تطبيقات منصة Apple، يضبط المكوّن الإضافي Firebase Unity Editor مشروع Xcode تلقائيًا لتحميل الرموز.
- بالنسبة إلى تطبيقات Android: تأكَّد من أنّك أعددت الأمر Firebase CLI crashlytics:symbols:upload ونفّذته لإنشاء ملف الرموز وتحميله.
  
  يجب تنفيذ أمر واجهة سطر الأوامر هذا في كل مرة تنشئ فيها إصدارًا أو أي إصدار تريد عرض عمليات تتبُّع تسلسل استدعاء الدوال البرمجية مع رموز في وحدة تحكّم Firebase. يمكنك الاطّلاع على مزيد من المعلومات في مقالة الحصول على تقارير أعطال قابلة للقراءة.

الإبلاغ عن الاستثناءات غير المعالَجة كأخطاء فادحة

يمكن لـ Crashlytics الإبلاغ عن الاستثناءات غير المعالَجة كأخطاء فادحة (بدءًا من الإصدار 10.4.0 من حزمة Unity SDK). تساعد الأسئلة الشائعة التالية في توضيح الأساس المنطقي وأفضل الممارسات لاستخدام هذه الميزة.

لماذا يجب أن يبلغ التطبيق عن الاستثناءات غير المعالَجة على أنّها أخطاء فادحة؟

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

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

ما هي الاستثناءات التي سيتم الإبلاغ عنها كأخطاء فادحة؟

لكي يتمكّن Crashlytics من تسجيل استثناء لم يتم رصده على أنّه خطأ فادح، يجب استيفاء الشرطين التاليين:

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

بعد تفعيل إعداد التقارير عن الاستثناءات غير المعالَجة كأخطاء فادحة، أصبح لديّ الآن العديد من الأخطاء الفادحة الجديدة. كيف يمكنني التعامل مع هذه الاستثناءات بشكل صحيح؟

عندما تبدأ في تلقّي تقارير عن الأخطاء غير المعالَجة باعتبارها أخطاء فادحة، إليك بعض الخيارات للتعامل مع هذه الأخطاء غير المعالَجة:

فكِّر في كيفية بدء رصد هذه الاستثناءات غير المعالَجة والتعامل معها.
ننصحك بالنظر في خيارات مختلفة لتسجيل الاستثناءات في وحدة تصحيح الأخطاء في Unity وفي Crashlytics.

التقاط الاستثناءات التي تم طرحها والتعامل معها

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

من أفضل الممارسات رصد جميع الاستثناءات المتوقّعة والتعامل معها، ما لم يتعذّر إعادة البرنامج إلى حالة معروفة.

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

تسجيل الاستثناءات في Unity أو Crashlytics

تتوفّر عدة طرق لتسجيل الاستثناءات في Unity أو Crashlytics للمساعدة في تحديد المشكلة وحلّها.

عند استخدام Crashlytics، إليك الخياران الأكثر شيوعًا والموصى بهما:

الخيار 1: الطباعة في وحدة تحكّم Unity، ولكن بدون إرسال تقارير إلى Crashlytics أثناء التطوير أو تحديد المشاكل وحلّها
- يمكنك الطباعة إلى وحدة تحكّم Unity باستخدام Debug.Log(exception) وDebug.LogWarning(exception) وDebug.LogError(exception)، وهي رموز تطبع محتوى الاستثناء إلى وحدة تحكّم Unity ولا تعيد طرح الاستثناء.
الخيار 2: التحميل إلى Crashlytics لإعداد تقارير موحّدة في لوحة بيانات Crashlytics في الحالات التالية:
- إذا كان الاستثناء يستحق التسجيل لتصحيح خطأ محتمل في حدث لاحق، استخدِم Crashlytics.Log(exception.ToString()).Crashlytics
- إذا كان يجب مواصلة إرسال تقرير عن استثناء إلى Crashlytics على الرغم من رصده ومعالجته، استخدِم Crashlytics.LogException(exception) لتسجيله كحدث غير خطير.

ومع ذلك، إذا أردت الإبلاغ يدويًا عن حدث خطير إلى Unity Cloud Diagnostics، يمكنك استخدام Debug.LogException. يطبع هذا الخيار الاستثناء في وحدة تحكّم Unity مثل الخيار 1، ولكنّه يطرح الاستثناء أيضًا (سواء تم طرحه أو رصده بعد). ويتم عرض الخطأ بشكل غير محلي. وهذا يعني أنّه حتى إذا كان هناك Debug.LogException(exception) يحتوي على كتل try-catch، سيظلّ ذلك يؤدي إلى حدوث استثناء غير معالج.

لذلك، اتّصِل بالرقم Debug.LogException إذا كنت تريد تنفيذ كل مما يلي فقط:

لطباعة الاستثناء في وحدة تحكّم Unity.
لتحميل الاستثناء إلى Crashlytics كحدث فادح.
لإظهار الاستثناء، يجب التعامل معه على أنّه استثناء غير مرصود، ويجب إرساله إلى Unity Cloud Diagnostics.

يُرجى العِلم أنّه إذا كنت تريد طباعة استثناء تم رصده في وحدة تحكّم Unity و تحميله إلى Crashlytics كحدث غير مميت، عليك اتّباع الخطوات التالية بدلاً من ذلك:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}