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

iOS+‎ Android Flutter Unity

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

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

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

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

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

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

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

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

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

• تجديد البيانات الوصفية المعروضة ضمن صف المشكلة
  أصبح من الأسهل الآن فهم المشاكل في تطبيقك وتصنيفها.

• عدد أقل من المشاكل المكرّرة
  لا يؤدي تغيير رقم السطر إلى ظهور مشكلة جديدة.

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

• تنبيهات وإشارات أكثر فائدة
  تمثّل المشكلة الجديدة خطأً جديدًا.

• بحث أكثر فعالية
  تحتوي كل مشكلة على بيانات وصفية قابلة للبحث، مثل نوع الاستثناء واسم الحزمة.

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

• عندما نتلقّى أحداثًا جديدة من تطبيقك، سنتحقّق مما إذا كانت تتطابق مع مشكلة حالية.

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

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

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

إذا لم تظهر لك سجلات مسار التنقل، ننصحك بالتحقّق من إعدادات تطبيقك بحثًا عن Google Analytics. يجب استيفاء المتطلبات التالية:

• لقد فعّلت Google Analytics في مشروعك على Firebase.

• لقد فعّلت مشاركة البيانات في Google Analytics. يمكنك الاطّلاع على مزيد من المعلومات حول هذا الإعداد في مقالة إدارة إعدادات مشاركة البيانات في "إحصاءات Google".

• لقد أضفت حزمة تطوير البرامج (SDK) لمنصة Firebase إلى Google Analytics تطبيقك. يجب إضافة حزمة تطوير البرامج (SDK) هذه بالإضافة إلى حزمة تطوير البرامج (SDK) Crashlytics.

• استخدام أحدث إصدارات حزمة تطوير البرامج (SDK) من Firebase لجميع المنتجات التي تستخدمها في تطبيقك

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

إذا لم تظهر لك تنبيهات السرعة، تأكَّد من أنّك تستخدم الإصدار 11.7.0 أو إصدارًا أحدث من حزمة تطوير البرامج (SDK) في Crashlytics.

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

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

• تأكَّد من استخدام الإصدار 11.7.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) في Crashlytics.

• تأكَّد من أنّ إعدادات جمع البيانات لا تؤثّر في جودة مقاييسك الخالية من الأعطال:

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

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

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

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

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

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

1. تأكَّد من استخدام الإصدار 8.6.1 أو إصدار أحدث من حزمة تطوير البرامج (SDK) الخاصة بـ Crashlytics Unity.

2. تأكَّد من إعداد وتنفيذ الأمر Firebase CLI crashlytics:symbols:upload لإنشاء ملف الرموز وتحميله.

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

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

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

1. تأكَّد من استخدام الإصدار 8.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) الخاصة بمنصة Crashlytics Unity.

2. أكمِل المهام اللازمة للنظام الأساسي الذي تستخدمه:

   • بالنسبة إلى التطبيقات على منصة Apple: ليس عليك اتّخاذ أي إجراءات خاصة. بالنسبة إلى تطبيقات منصة Apple، يضبط المكوّن الإضافي Firebase Unity Editor مشروع Xcode تلقائيًا لتحميل الرموز.

   • بالنسبة إلى تطبيقات Android: تأكَّد من أنّك أعددت الأمر Firebase CLI crashlytics:symbols:upload ونفّذته لإنشاء ملف الرموز وتحميله.

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

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

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

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

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

• يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات الحالية وحذفها وكتابة ملاحظات جديدة بشأن مشكلة.

  • المالك أو المحرِّر للمشروع، مشرف Firebase، مشرف الجودة، أو مشرف Crashlytics

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

  • مُشاهد المشروع أو مُشاهد Firebase أو مُشاهد الجودة أو مُشاهد Crashlytics

عمليات الدمج

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

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

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

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

المشاكل التي تكرّرت

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

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

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

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

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

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

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

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

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

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

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

إذا لاحظت عددًا كبيرًا من حالات الانحدار التي تم تحديدها بشكل خاطئ قبل شباط (فبراير) 2022، يمكنك إعادة إغلاقها لمنع إعادة فتحها.

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

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

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

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

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

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

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

لكي يتمكّن 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 لاحق، استخدِم Crashlytics.Log(exception.ToString()).
  • إذا كان يجب مواصلة إرسال تقرير عن استثناء إلى 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
    //
}