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

iOS والإصدارات الأحدث Android Flutter Unity

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

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

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

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

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

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

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

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

في ما يلي الميزات التي ستستفيد منها من خلال هذه التحسينات:

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

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

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

• تنبيهات وإشارات أكثر وضوحًا
  تشير المشكلة الجديدة إلى خطأ جديد.

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

في ما يلي كيفية طرح هذه التحسينات:

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

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

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

عدم ظهور مقاييس عدم حدوث الأعطال و/أو تنبيهات السرعة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تمثّل قيمة "خالٍ من الأعطال" النسبة المئوية للمستخدمين الذين تفاعلوا مع تطبيقك ولكنّه لم يواجه أيّ عطل خلال فترة زمنية معيّنة.

في ما يلي الصيغة لاحتساب النسبة المئوية للمستخدمين الذين لم يواجههم أي تعطُّل. يتم توفير قيم الإدخال من قِبل Google Analytics.

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

• عند حدوث تعذّر، يُرسِل Google Analytics نوع حدث app_exception، ويمثّل CRASHED_USERS عدد المستخدِمين المرتبطين بنوع الحدث هذا.

• يمثّل ALL_USERS إجمالي عدد المستخدمين الذين تفاعلوا مع تطبيقك خلال الفترة الزمنية التي اخترتها من القائمة المنسدلة في أعلى يسار لوحة بيانات Crashlytics.

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

إنّ النسبة المئوية للمستخدمين الذين لم يواجههم أي تعطُّل هي تجميع على مدار الوقت، وليس متوسطًا.

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

	الاثنين	الثلاثاء	الأربعاء
المستخدِمون الذين تفاعلوا مع تطبيقك	أ، ب، ج	أ، ب، ج	أ، ب
المستخدم الذي واجه عطلاً	ج	أزرق	أ

• في يوم الأربعاء، بلغت النسبة المئوية للمستخدمين الذين لم يواجههم أي تعطُّل %50 (لم يواجه مستخدم واحد من بين مستخدمَين تعطُّلاً).
  تفاعل مستخدمان من المستخدمين مع تطبيقك يوم الأربعاء، ولكن لم يواجه سوى أحدهما (المستخدم "ب") أي أعطال.

• خلال اليومَين الماضيَين، بلغت النسبة المئوية للمستخدمين الذين لم يواجههم أي تعطُّل ‎33.3% (لم يواجه أي تعطُّل مستخدم واحد من بين 3 مستخدمين).
  تفاعل ثلاثة من المستخدمين مع تطبيقك خلال اليومَين الماضيَين، ولكن لم يواجه سوى أحدهم (المستخدم "ج") أي أعطال.

• خلال آخر 3 أيام، كانت النسبة المئوية للمستخدمين الذين لم يواجههم أي تعطُّل هي 0% (لم يواجه أي تعطُّل 0 من بين 3 مستخدمين).
  تفاعل ثلاثة من المستخدمين مع تطبيقك خلال آخر ثلاثة أيام، ولكن لم يواجه أيّ منهم أي أعطال.

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

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

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

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

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

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

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

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

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

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

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

اطّلِع على فهم المقاييس الخالية من الأعطال.

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

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

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

لماذا يجب أن يُبلغ التطبيق عن الاستثناءات غير التي تمّ رصدها كأخطاء قاتلة؟

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

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

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

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

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

• أثناء الإعداد في تطبيقك، يجب ضبط القيمة ReportUncaughtExceptionsAsFatal على true.

• يُلقي تطبيقك (أو مكتبة مضمّنة) استثناءً لم يتمّ رصده. إنّ عدم رمي أحد الاستثناءات التي تم إنشاؤها لا يعني أنّه لم يتم اعتراضه.

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

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

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

اكتشاف الاستثناءات التي يتم طرحها ومعالجتها

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

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

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

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

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

عند استخدام 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
    //
}