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

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

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

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

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

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

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

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

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

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

في ما يلي تجربتك هذه التحسينات:

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

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

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

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

لا أرى مقاييس خالية من الأعطال و/أو تنبيهات السرعة

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

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

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

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

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

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

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

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

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

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

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

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

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

في ما يلي معادلة حساب النسبة المئوية للمستخدمين الذين لم يواجهوا أعطالاً. مدخله يتم تقديم القيم من خلالها بواسطة "إحصاءات Google".

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

عند وقوع حادث سير، تُرسِل "إحصاءات Google" حدث app_exception. النوع، ويمثل CRASHED_USERS عدد المستخدمين المرتبطين مع نوع الحدث هذا
يمثّل ALL_USERS إجمالي عدد المستخدمين الذين تفاعلوا مع تطبيقك خلال الفترة الزمنية التي حددتها من القائمة المنسدلة في في الجانب العلوي الأيسر من لوحة معلومات Crashlytics.

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

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

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

يوم الأربعاء، بلغت النسبة المئوية للمستخدمين الذين لم يواجهوا أعطالاً %50 (كان مستخدم واحد من كل مستخدمَين خالية من الأعطال).
تفاعل اثنان من المستخدمين مع تطبيقك يوم الأربعاء، ولكن أحدهما فقط (المستخدم ب) لم تحدث أي أعطال.
خلال آخر يومَين، بلغت النسبة المئوية للمستخدمين الذين لم يواجهوا أي أعطال 33.3% (1 من إجمالي 3). مستخدميها خالية من الأعطال).
تفاعل ثلاثة من المستخدمين مع تطبيقك خلال اليومين الماضيين، ولكن فقط ولم تحدث أي أعطال في أحدها (المستخدم "ج".
خلال آخر 3 أيام، كانت النسبة المئوية للمستخدمين الذين لم يواجهوا أعطالاً %0 (0 من إجمالي 3) لم يتعرض المستخدمون لأي أعطال).
تفاعل ثلاثة من المستخدمين مع تطبيقك خلال الأيام الثلاثة الماضية، ولكن ولم تتعرض أي من هذه الأعطال لأي أعطال.

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

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

تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات معينة بشأن الأسئلة والحالة والتحديثات وما إلى ذلك.

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

في ما يلي وصف إذن الوصول المطلوب للاطّلاع عليه والكتابة والحذف. ملاحظات:

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

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

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

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

تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات معينة بشأن الأسئلة والحالة والتحديثات وما إلى ذلك.

في ما يلي وصف إذن الوصول المطلوب للاطّلاع عليه والكتابة والحذف. ملاحظات:

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

عمليات الدمج

يستخدم التطبيق أيضًا حزمة "SDK لإعلانات Google على الأجهزة الجوّالة" لا تظهر أعطالاً

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

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

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

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

ما معنى الانحدار المشكلة؟

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

إليك مثال على سيناريو يشرح كيفية تصنيف تطبيق Crashlytics كانحدار:

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

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

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

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

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

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

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

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

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

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

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

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

لكي يبلِّغ تطبيق 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 بيانات التشخيص، يمكنك استخدام 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
    //
}