توفّر هذه الصفحة مساعدة في تحديد المشاكل وحلّها وإجابات عن الأسئلة الشائعة حول استخدام تطبيق Crashlytics. إذا لم تتمكّن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية، يُرجى التواصل مع فريق دعم Firebase.
الإجراءات العامّة لتحديد المشاكل وحلّها/الأسئلة الشائعة
عرض تنسيقات مختلفة
(وأحيانًا "خيارات مختلفة") لبعض المشاكل في جدول المشاكل
قد تلاحظ تنسيقَين مختلفَين للمشاكل المُدرَجة في جدول المشاكل ضمن "وحدة تحكُّم Firebase". وقد تلاحظ أيضًا ميزة تسمى
"المتغيرات" داخل بعض مشكلاتك. هذا هو السبب!
في أوائل عام 2023، طرحنا محرّك تحليل محسّنًا لتجميع الأحداث،
بالإضافة إلى تصميم معدَّل وبعض الميزات المتقدّمة للمشاكل الجديدة (مثل
الصيغ المختلفة). يمكنك الاطّلاع على مشاركة المدونة الأخيرة لمعرفة كل التفاصيل، ولكن يمكنك الاطّلاع أدناه على أهم التفاصيل.
يحلِّل Crashlytics جميع الأحداث الواردة في تطبيقك (مثل الأعطال وغير الفادحة وأخطاء ANR) وينشئ مجموعات من الأحداث تُسمى المشاكل. جميع الأحداث في إحدى المشاكل لديها نقطة عطل شائعة.
لتجميع الأحداث في هذه المشاكل، يفحص محرّك التحليل المحسَّن الآن العديد من جوانب الحدث، بما في ذلك الإطارات في تتبُّع تسلسل استدعاء الدوال البرمجية ورسالة الاستثناء ورمز الخطأ وخصائص النظام الأساسي أو نوع الخطأ الأخرى.
ومع ذلك، ضمن هذه المجموعة من الأحداث، قد تختلف عمليات تتبُّع تسلسل استدعاء الدوال البرمجية
التي تؤدي إلى الفشل. قد يؤدي تتبُّع تسلسل استدعاء الدوال البرمجية المختلف إلى سبب جذري مختلف.
لتمثيل هذا الاختلاف المحتمل ضمن مشكلة معيّنة، ننشئ الآن صيغًا مختلفة ضمن المشاكل، حيث يكون كل صيغة عبارة عن مجموعة فرعية من الأحداث في مشكلة لها نقطة الفشل نفسها وتتبُّع تسلسل استدعاء الدوال البرمجية مشابهًا. باستخدام الصيغ، يمكنك تصحيح الأخطاء في عمليات تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن المشكلة وتحديد ما إذا كانت الأسباب الأساسية المختلفة هي التي تؤدي إلى حدوث العطل.
إليك ما ستختبره مع هذه التحسينات:
تعديل البيانات الوصفية المعروضة في صف المشكلة أصبح من السهل الآن فهم المشاكل وتصنيفها في تطبيقك.
مشاكل أقل تكرارًا لا يؤدي تغيير رقم الأسطر إلى مشكلة جديدة.
تصحيح الأخطاء بسهولة أكبر للمشاكل المعقّدة ذات الأسباب الأساسية المختلفة استخدِم الصيغ لتصحيح الأخطاء في عمليات تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن المشكلة.
تنبيهات وإشارات أكثر فائدة تمثّل المشكلة الجديدة خطأً جديدًا.
ميزات بحث أكثر فعالية تحتوي كل مشكلة على بيانات وصفية أكثر قابلية للبحث،
مثل نوع الاستثناء واسم الحزمة.
في ما يلي طريقة طرح هذه التحسينات:
عندما نتلقّى أحداثًا جديدة من تطبيقك، سنتحقّق مما إذا كانت تتطابق مع مشكلة حالية.
وإذا لم يكن هناك أي تطابق، سنطبق تلقائيًا خوارزمية تجميع الأحداث
الأكثر ذكاءً على الحدث وننشئ مشكلة جديدة مع تصميم
بيانات التعريف المجدَّد.
وهذا هو التعديل الكبير الأول الذي نُجريه على تصنيف الأحداث في مجموعاتنا. إذا كانت لديك
ملاحظات أو واجهت أي مشاكل، يُرجى إعلامنا بها من خلال
تقديم بلاغ.
عدم ظهور
مقاييس خالية من الأعطال و/أو تنبيهات السرعة
إذا لم تظهر لك مقاييس خالية من الأعطال (مثل الجلسات والمستخدمين الذين لم تحدث أعطال لهم)
و/أو تنبيهات السرعة، تأكَّد من استخدام
Crashlytics. +3.+7
عدم ظهور سجلات شريط التنقُّل
إذا لم تظهر لك سجلّات شريط التنقّل، ننصحك بالتحقق من إعدادات تطبيقك لخدمة "إحصاءات Google".
يجب الحرص على استيفاء المتطلبات التالية:
الاطّلاع على عمليات تتبُّع تسلسل استدعاء الدوال البرمجية
غير الرمزية لتطبيقات Android في لوحة بيانات Crashlytics
إذا كنت تستخدم Unity IL2CPP
وتظهر عمليات تتبُّع تسلسُل استدعاء الدوال البرمجية غير رمزية، جرِّب ما يلي:
احرص على استخدام الإصدار 8.6.1 أو إصدار أحدث من حزمة تطوير البرامج (SDK) الخاصة بإصدار Crashlytics Unity.
احرص على إعداد وتشغيل الأمر crashlytics:symbols:uploadCLI في Firebase لإنشاء ملف الرموز وتحميله.
عليك تشغيل أمر واجهة سطر الأوامر هذا في كل مرة تنشئ فيها إصدار
أو أي إصدار تريد رؤية عمليات تتبع تسلسل استدعاء الدوال البرمجية التي تتضمّن رموزًا في
وحدة تحكُّم Firebase. تعرَّف على مزيد من المعلومات في صفحة
الحصول على تقارير الأعطال القابلة للقراءة.
هل يمكن استخدام Crashlytics
مع التطبيقات التي تستخدم بروتوكول IL2CPP؟
نعم، يمكن لتطبيق Crashlytics عرض عمليات تتبُّع تسلسل استدعاء الدوال البرمجية المرمزة لتطبيقاتك التي تستخدم IL2CPP. وتتوفّر هذه الإمكانية للتطبيقات التي تم إصدارها على أنظمة التشغيل Android أو Apple الأساسية. إليك ما يجب فعله:
احرص على استخدام الإصدار 8.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) الخاصة بإصدار Crashlytics Unity.
أكمِل المهام اللازمة للنظام الأساسي الذي تستخدمه:
بالنسبة إلى تطبيقات نظام التشغيل Apple الأساسي: ليست هناك حاجة إلى اتخاذ أي إجراء خاص. بالنسبة إلى تطبيقات نظام التشغيل Apple، يعمل المكوّن الإضافي لمحرّر Firebase Unity على تهيئة مشروع Xcode تلقائيًا لتحميل الرموز.
بالنسبة إلى تطبيقات Android: احرص على إعداد وتشغيل أمر Firebase CLI crashlytics:symbols:upload لإنشاء ملف الرموز وتحميله.
عليك تشغيل أمر واجهة سطر الأوامر هذا في كل مرة تنشئ فيها إصدار
أو أي إصدار تريد رؤية عمليات تتبع تسلسل استدعاء الدوال البرمجية التي تتضمّن رموزًا في
وحدة تحكُّم Firebase. تعرَّف على مزيد من المعلومات في صفحة
الحصول على تقارير الأعطال القابلة للقراءة.
كيف يتم احتساب المستخدمين الذين لم يواجههم أي تعطُّل؟
تمثّل القيمة الخالية من الأعطال النسبة المئوية للمستخدمين الذين تفاعلوا مع تطبيقك لم يواجهوا عطلاً خلال فترة زمنية محدّدة.
في ما يلي صيغة احتساب النسبة المئوية للمستخدمين الذين لم يواجههم أي تعطُّل. توفر "إحصاءات Google" قيم الإدخال
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
عند حدوث عطل، تُرسِل "إحصاءات Google" نوع الحدث app_exception، ويمثّل CRASHED_USERS عدد المستخدمين المرتبطين بنوع الحدث هذا.
تمثّل القيمة ALL_USERS إجمالي عدد المستخدمين الذين تفاعلوا مع تطبيقك خلال الفترة الزمنية التي اخترتها من القائمة المنسدلة في أعلى يسار لوحة بيانات Crashlytics.
النسبة المئوية للمستخدمين الذين لم يواجههم أي تعطُّل هي تجميع بمرور الوقت، وليست متوسطًا.
على سبيل المثال، تخيل أن تطبيقك لديه ثلاثة مستخدمين؛ سنسميهم المستخدم أ، والمستخدم ب،
والمستخدم ج. يوضِّح الجدول التالي المستخدمِين الذين تفاعلوا مع تطبيقك يوميًا
وأيّ من هؤلاء المستخدِمين تعطّل في ذلك اليوم:
الاثنين
الثلاثاء
الأربعاء
المستخدمون الذين تفاعلوا مع تطبيقك
أ، ب، ج
أ، ب، ج
أ، ب
المستخدم الذي واجه حادث سير
ج
B
أ
في يوم الأربعاء، تبلغ النسبة المئوية للمستخدمين الذين لم يواجههم أي أعطال 50% (كان مستخدم واحد من كل مستخدمَين
خالٍ من الأعطال). تفاعل اثنان من المستخدمين مع تطبيقك يوم الأربعاء، ولكن لم يواجه أحدهما فقط (المستخدم ب) أي أعطال.
خلال اليومين الماضيين، بلغت النسبة المئوية للمستخدمين الذين لم يواجههم أي أعطال 33.3% (مستخدم واحد من أصل 3 مستخدمين لم يواجه أعطالاً). تفاعل ثلاثة من المستخدمين مع تطبيقك خلال اليومين الماضيين، ولكن لم يواجه أحدهم فقط (المستخدم ج) أي أعطال.
خلال آخر 3 أيام، كانت النسبة المئوية للمستخدمين الذين لم يواجههم أي أعطال 0% (لم يكُن 0 من إجمالي 3 مستخدمين لم يواجههم أي تعطُّل). تفاعل ثلاثة من المستخدمين مع تطبيقك خلال الأيام الثلاثة الماضية، ولكن لم يواجه أي منهم أي أعطال.
ويجب عدم مقارنة قيمة المستخدمين الذين لم يواجههم أي تعطُّل خلال فترات زمنية مختلفة.
يزداد احتمال تعرّض مستخدم واحد لتعطُّل التطبيق كلما زاد عدد مرات استخدامه لتطبيقك، لذا من المرجَّح أن تنخفض قيمة المستخدمين الذين لم يواجههم أي تعطُّل خلال فترات زمنية أطول.
مَن يمكنه الاطّلاع على الملاحظات المتعلقة بالمشكلة وكتابتها وحذفها؟
تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات محددة بشأن الأسئلة
وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها بعنوان البريد الإلكتروني لحسابه على Google. يكون عنوان البريد الإلكتروني هذا مرئيًا مع الملاحظة لجميع أعضاء
المشروع الذين لديهم إمكانية الوصول لعرض الملاحظة.
يوضّح ما يلي إذن الوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات
الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
مَن يمكنه الاطّلاع على الملاحظات المتعلقة بالمشكلة وكتابتها وحذفها؟
تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات محددة بشأن الأسئلة
وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها بعنوان البريد الإلكتروني لحسابه على Google. يكون عنوان البريد الإلكتروني هذا مرئيًا مع الملاحظة لجميع أعضاء
المشروع الذين لديهم إمكانية الوصول لعرض الملاحظة.
يوضّح ما يلي إذن الوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات
الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
يستخدم التطبيق أيضًا
"SDK لإعلانات Google على الأجهزة الجوّالة" ولكن لا يواجه أعطالاً
إذا كان مشروعك يستخدم Crashlytics مع "حزمة تطوير البرامج (SDK) لإعلانات Google على الأجهزة الجوّالة"،
من المحتمل أن يتداخل معلّوو الأعطال عند تسجيل معالِجات الاستثناء. لإصلاح المشكلة، يمكنك إيقاف إعداد تقارير الأعطال في "حزمة SDK لإعلانات الأجهزة الجوّالة" من خلال طلب الرقم disableSDKCrashReporting.
أين توجد مجموعة بيانات BigQuery؟
بعد ربط Crashlytics بأداة BigQuery، يتم تلقائيًا وضع مجموعات البيانات الجديدة التي تنشئها في الولايات المتحدة، بغض النظر عن موقع مشروع Firebase.
المشاكل المتراجعة
ما المشكلة المتراجعة؟
حدث تراجع في حجم المشكلة بعد أن أغلقتها سابقًا،
ولكن تلقّى Crashlytics تقريرًا جديدًا يفيد بأنّ المشكلة قد تكرّرت.
يعيد Crashlytics تلقائيًا فتح هذه المشاكل التي تراجعت حتى تتمكن من
معالجتها بما يناسب تطبيقك.
إليك مثال على سيناريو يشرح كيفية تصنيف Crashlytics لمشكلة على أنّها انحدار:
ولأول مرة على الإطلاق، يحصل Crashlytics على تقرير أعطال حول Crash
"A". يفتح Crashlytics مشكلة مقابلة لذلك العُطل (المشكلة "أ").
يمكنك إصلاح هذا الخطأ بسرعة، وإغلاق المشكلة "أ"، ثم طرح إصدار جديد
من تطبيقك.
يتلقّى Crashlytics تقريرًا آخر حول المشكلة "أ" بعد إغلاقها.
إذا كان التقرير صادرًا عن إصدار تطبيق عرفه تطبيق Crashlytics عند إغلاق المشكلة (ما يعني أنّ الإصدار أرسل تقرير أعطال لأي تعطُّل على الإطلاق)، لن يعتبر Crashlytics المشكلة على أنّها تراجعت. ستبقى المشكلة مغلقة.
إذا كان التقرير صادرًا من إصدار تطبيق لم
يلم تطبيق Crashlytics عند إغلاق المشكلة (ما يعني أنّ الإصدار
لم يرسل أي تقرير أعطال بسبب أي تعطُّل على الإطلاق)، يعتبر Crashlytics أنّ المشكلة انحدارت وستتم إعادة فتح المشكلة.
عند انحدار مشكلة، نرسل تنبيه رصد تراجع ونضيف إشارة انحدار إلى المشكلة لإعلامك بأنّ Crashlytics
قد أعادت فتح المشكلة. إذا كنت لا تريد إعادة فتح مشكلة ما بسبب
خوارزمية الانحدار، يمكنك "كتم صوت" المشكلة بدلاً من إغلاقها.
لماذا ألاحظ مشاكل تراجعية
في إصدارات التطبيق القديمة؟
إذا كان التقرير من إصدار قديم من التطبيق لم يرسل أي تقارير أعطال مطلقًا
عند إغلاق المشكلة، يعتبر Crashlytics أنّ المشكلة تراجعت وستُعيد فتحها.
يمكن أن يحدث هذا الموقف في الحالات التالية: بعد أن أصلحت خطأً وأصدرت إصدارًا جديدًا من تطبيقك، لا يزال لديك مستخدمون لإصدارات قديمة من تطبيقك بدون إصلاح الخطأ. إذا تم، مصادفة، أن أحد هذه الإصدارات القديمة لم يرسل أي تقارير أعطال على الإطلاق عند إغلاق المشكلة، وبدأ هؤلاء المستخدمون في مواجهة الخطأ، فستؤدي تقارير الأعطال هذه إلى حدوث مشكلة تراجُع.
إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار، فيمكنك "كتم صوت" المشكلة بدلاً من إغلاقها.
الإبلاغ عن الاستثناءات غير المرصودة على أنّها بالغة الوفاة
يمكن لتطبيق Crashlytics الإبلاغ عن الاستثناءات غير المرصودة كحالات وحشية (بدءًا من
الإصدار 10.4.0
من حزمة Unity SDK). تساعد الأسئلة الشائعة التالية في شرح الأساس المنطقي
وأفضل الممارسات لاستخدام هذه الميزة.
لماذا يجب أن يبلِّغ أحد التطبيقات عن الاستثناءات غير المرصودة على أنّها حالات وفاة؟
من خلال الإبلاغ عن الاستثناءات غير المرصودة على أنّها حالات وفاة، ستحصل على مؤشر أكثر واقعية حول الاستثناءات التي قد تؤدي إلى عدم إمكانية تشغيل اللعبة، حتى مع استمرار تشغيل التطبيق.
يُرجى العلم أنّه في حال بدء الإبلاغ عن حالات وفاة، من المحتمل أن تنخفض نسبة المستخدمين الذين لم يواجههم أي تعطُّل،
ولكن مقياس CFU سيكون أكثر تمثيلاً لتجارب المستخدمين النهائيين مع تطبيقك.
ما الاستثناءات التي سيتم
الإبلاغ عنها على أنها فادحة؟
لكي يتم الإبلاغ عن استثناء غير مرصود في Crashlytics، يجب استيفاء كلا الشرطين التاليين:
من أفضل الممارسات رصد جميع الاستثناءات المتوقعة والتعامل معها ما لم تكن
يمكن إعادة البرنامج إلى حالة معروفة.
للتحكّم في أنواع الاستثناءات التي يتم تسجيلها ومعالجتها حسب الرمز،
يجب إحاطة الرمز الذي قد ينشئ استثناءً في مجموعة try-catch.
تأكَّد من أنّ الشروط الواردة في عبارات catch محدودة قدر الإمكان للتعامل بشكل مناسب مع الاستثناءات المحدّدة.
تسجيل الاستثناءات في Unity أو Crashlytics
هناك عدة طرق لتسجيل الاستثناءات في Unity أو Crashlytics للمساعدة في
تصحيح المشكلة.
عند استخدام Crashlytics، إليك الخياران الأكثر شيوعًا والمقترَحة:
الخيار الأول: الطباعة في وحدة تحكُّم 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
//
}
