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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. يجب التأكّد من إعداد واجهة سطر الأوامر "Firebase" وتشغيله crashlytics:symbols:upload لإنشاء الرمز وتحميله. الملف.

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

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

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

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

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

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

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

     يجب تشغيل أمر CLI هذا في كل مرة تنشئ فيها إصدارًا أو أي إصدار تريد مشاهدة عمليات تتبع تسلسل استدعاء الدوال البرمجية له في رمز وحدة تحكّم 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 قد تختلف أحيانًا عن القيمة التي نستخدمها في احتساب نتائج البحث الخالية من الأعطال نسبة المستخدمين.

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

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

	الاثنين	الثلاثاء	الأربعاء
المستخدمون الذين تفاعلوا مع تطبيقك	أ، ب، ج	أ، ب، ج	أ، ب
المستخدم الذي تعطّل	ج	B	A

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

• خلال آخر يومَين، بلغت النسبة المئوية للمستخدمين الذين لم يواجهوا أي أعطال 33.3% (1 من إجمالي 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 تقرير أعطال بشأن حوادث السير. "A". يفتح Crashlytics مشكلة مقابلة لهذا العُطل (المشكلة "أ").
2. إصلاح هذا الخطأ بسرعة، وإغلاق المشكلة "أ"، ثم طرح إصدار جديد من تطبيقك.
3. تلقّي تقرير آخر بشأن المشكلة "أ" في Crashlytics بعد إغلاق المشكلة.
   • إذا كان التقرير واردًا من إصدار تطبيق كان فريق Crashlytics على دراية به عند إغلاق المشكلة (أي أنّ الإصدار أرسل تقرير تعطُّل لأي تعطُّل على الإطلاق)، لن يعتبر فريق Crashlytics أنّ المشكلة قد عادت للظهور. ستظلّ المشكلة مغلقة.
   • إذا كان التقرير من إصدار تطبيق Crashlytics لم ليس إلى معرفة عند إنهاء المشكلة (أي أنّ الإصدار احتوى على لم يرسل أي تقرير أعطال على الإطلاق)، ثم تعتبر الإضافة "Crashlytics" أنّ المشكلة قد تراجعت، وسيعيد فتح المشكلة.

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

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

لماذا أرى تراجعًا في إصدارات التطبيق القديمة؟

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

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

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

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

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

الإبلاغ عن الاستثناءات غير المرصودة على أنّها حالات وفاة

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

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

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

يُرجى العِلم أنّه إذا بدأت في الإبلاغ عن الأعطال الخطيرة، من المرجّح أن تنخفض النسبة المئوية للمستخدمين الذين لم يواجهوا أيّ أعطال (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 بيانات التشخيص ببيانات الخطأ.

يُرجى العلم أنّه إذا أردت طباعة استثناء تم رصده من وحدة التحكّم في 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
    //
}