توفر هذه الصفحة مساعدة لاستكشاف الأخطاء وإصلاحها وإجابات على الأسئلة الشائعة حول استخدام Crashlytics. إذا لم تتمكّن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية، يُرجى التواصل مع فريق دعم Firebase.
الإجراءات العامّة لتحديد المشاكل وحلّها/الأسئلة الشائعة
الاطّلاع على تنسيقات مختلفة
(وأحيانًا "صيغ" لبعض المشاكل في جدول المشاكل)
قد تلاحظ تنسيقين مختلفين للمشكلات مدرجتين في جدول المشاكل ضمن وحدة تحكُّم Firebase. وقد تلاحظ أيضًا ميزة تسمى "المتغيرات"
ضمن بعض مشكلاتك. إليك السبب.
في أوائل العام 2023، طرحنا محرّك تحليل محسّن لتجميع الأحداث، بالإضافة إلى تصميم محدَّث وبعض الميزات المتقدّمة لحلّ المشاكل الجديدة (مثل الخيارات المختلفة). يمكنك مراجعة مشاركة المدونة الحديثة لمعرفة جميع التفاصيل، ولكن يمكنك قراءة النقاط الأساسية أدناه.
ويحلّل تطبيق Crashlytics جميع الأحداث في تطبيقك (مثل الأعطال والأخطاء غير الفادحة وأخطاء ANR) وينشئ مجموعات من الأحداث باسم المشاكل، حيث تتضمّن جميع الأحداث في العدد نقطة مشتركة من الفشل.
ولتجميع الأحداث حسب هذه المشاكل، يفحص محرك التحليل المحسّن الآن العديد من جوانب الفعالية، بما في ذلك الإطارات في تقرير تتبُّع تسلسل استدعاء الدوال البرمجية، ورسالة الاستثناء، ورمز الخطأ، وخصائص النظام الأساسي أو نوع الخطأ الأخرى.
ومع ذلك، داخل هذه المجموعة من الأحداث، قد تختلف عمليات تتبُّع تسلسل استدعاء الدوال البرمجية التي تؤدي إلى الفشل. وقد يؤدي اختلاف عملية تتبُّع تسلسل استدعاء الدوال البرمجية إلى سبب أساسي مختلف.
لتمثيل هذا الاختلاف المحتمل ضمن مشكلة، ننشئ الآن صيغًا مختلفة ضمن المشاكل، فكل صيغة هي مجموعة فرعية من الأحداث ضمن مشكلة لها نقطة العطل نفسها وتتبُّع تسلسل استدعاء الدوال البرمجية مشابهًا. باستخدام الصيغ، يمكنك تصحيح الأخطاء في عمليات تتبُّع تسلسُل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن المشكلة وتحديد ما إذا كانت الأسباب الجذرية المختلفة تؤدي إلى الإخفاق.
في ما يلي تجربتك هذه التحسينات:
البيانات الوصفية المجدَّدة المعروضة ضمن صف المشاكل أصبح من السهل فهم المشاكل وتصنيفها في تطبيقك.
عدد أقل من المشاكل المكرّرة لا يؤدي تغيير رقم السطر إلى حدوث مشكلة جديدة.
تصحيح الأخطاء بسهولة أكبر عند معالجة المشاكل المعقّدة ذات الأسباب الجذرية المختلفة يمكنك استخدام الصيغ لتصحيح أخطاء عمليات تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن المشكلة.
تنبيهات وإشارات أكثر فائدة تشير المشكلة الجديدة إلى خطأ جديد.
بحث أكثر فعالية تحتوي كل مشكلة على بيانات وصفية أكثر قابلية للبحث،
مثل نوع الاستثناء واسم الحزمة.
في ما يلي طريقة طرح هذه التحسينات:
عندما نحصل على أحداث جديدة من تطبيقك، سنتحقق مما إذا كانت تطابق مشكلة حالية أم لا.
وفي حال عدم العثور على نتيجة مطابِقة، سنطبّق تلقائيًا خوارزمية التجميع الأذكى
لتجميع الأحداث على الحدث وننشئ مشكلة جديدة في تصميم البيانات الوصفية
المحسّن.
هذا هو أول تحديث مهم نجريه على تجميع الفعاليات. إذا كانت لديك أي ملاحظات أو واجهت أي مشاكل، يُرجى إعلامنا بها من خلال
تقديم بلاغ
.
عدم ظهور مقاييس خالية من الأعطال و/أو تنبيهات السرعة
إذا لم تظهر لك مقاييس خالية من الأعطال (مثل المستخدمين والجلسات الخالية من الأعطال)
و/أو تنبيهات السرعة،
تأكَّد من استخدام
عدم ظهور سجلّات شريط التنقّل
إذا لم تظهر لك سجلّات شريط التنقّل، ننصحك بالتحقّق من إعدادات تطبيقك في "إحصاءات Google".
احرص على استيفاء المتطلبات التالية:
رؤية عمليات تتبُّع تسلسُل استدعاء الدوال البرمجية غير المشفَّرة لتطبيقات Android في لوحة بيانات Crashlytics
إذا كنت تستخدم Unity IL2CPP
وظهرت لك عمليات تتبُّع تسلسُل استدعاء دوال برمجية غير مشفّرة، يمكنك تجربة ما يلي:
تأكّد من استخدام الإصدار 8.6.1 أو إصدار أحدث من حزمة تطوير البرامج (SDK) في Crashlytics Unity.
تأكَّد من إعداد أمر crashlytics:symbols:upload CLI في Firebase وتشغيله لإنشاء ملف الرموز وتحميله.
وعليك تشغيل أمر CLI هذا في كل مرة تنشئ فيها إصدارًا
أو أي إصدار تريد فيه رؤية عمليات رمزية لتتبُّع تسلسل استدعاء الدوال البرمجية في
وحدة تحكُّم Firebase. تعرَّف على المزيد من المعلومات في صفحة الحصول على تقارير الأعطال القابلة للقراءة.
هل يمكن استخدام Crashlytics مع التطبيقات التي تستخدم IL2CPP؟
نعم، يمكن لتطبيق Crashlytics عرض عمليات تتبُّع تسلسُل استدعاء الدوال البرمجية لتطبيقاتك التي تستخدم IL2CPP. وتتوفر هذه الإمكانية للتطبيقات التي يتم إصدارها على نظامي التشغيل Android أو
Apple الأساسيين. في ما يلي الإجراءات التي عليك اتّخاذها:
تأكّد من استخدام الإصدار 8.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) في Crashlytics Unity.
أكمل المهام الضرورية لنظامك الأساسي:
بالنسبة إلى تطبيقات نظام Apple الأساسي: لا يلزم اتخاذ أي إجراءات خاصة. بالنسبة إلى تطبيقات نظام التشغيل Apple، يعمل المكوّن الإضافي لمنصة Unity Editor من Firebase على إعداد مشروع Xcode تلقائيًا لتحميل الرموز.
بالنسبة إلى تطبيقات Android: تأكَّد من إعداد وتشغيل
أمر Firebase CLI crashlytics:symbols:upload لإنشاء
ملف الرموز وتحميله.
وعليك تشغيل أمر CLI هذا في كل مرة تنشئ فيها إصدارًا
أو أي إصدار تريد فيه رؤية عمليات رمزية لتتبُّع تسلسل استدعاء الدوال البرمجية في
وحدة تحكُّم 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% (كان 1 من كل 3 مستخدمين خالٍ من الأعطال). تفاعل ثلاثة من المستخدمين مع تطبيقك خلال اليومين الماضيين، ولكن
أحدهم فقط (المستخدم ج) لم يحدث أي أعطال فيه.
خلال آخر 3 أيام، كانت النسبة المئوية للمستخدمين الذين لم يواجهوا أعطالاً هي %0 (0 من بين كل 3 مستخدمين لم يواجهوا أي أعطال). تفاعل ثلاثة من المستخدمين مع تطبيقك خلال الأيام الثلاثة الماضية، ولكن لم يحصل أي منهم على أي أعطال.
يجب عدم مقارنة قيمة المستخدمين الذين لم يواجهوا أعطالاً خلال فترات زمنية مختلفة.
تزيد احتمالية تعرض مستخدم واحد للأعطال كلما زاد عدد مرات استخدام التطبيق، وبالتالي فمن المرجح أن تكون قيمة المستخدمين الذين لم يواجهوا أعطالاً أصغر لفترات زمنية أطول.
من يمكنه عرض الملاحظات وكتابتها وحذفها حول مشكلة ما؟
تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات معينة من خلال الأسئلة
وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها بالبريد الإلكتروني لحساب
Google. عنوان البريد الإلكتروني هذا مرئي، إلى جانب الملاحظة، لجميع أعضاء المشروع الذين لديهم إمكانية الوصول لعرض الملاحظة.
في ما يلي وصف للوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات
الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
من يمكنه عرض الملاحظات وكتابتها وحذفها حول مشكلة ما؟
تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات معينة من خلال الأسئلة
وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها بالبريد الإلكتروني لحساب
Google. عنوان البريد الإلكتروني هذا مرئي، إلى جانب الملاحظة، لجميع أعضاء المشروع الذين لديهم إمكانية الوصول لعرض الملاحظة.
في ما يلي وصف للوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات
الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
يستخدم التطبيق أيضًا
حزمة "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). تساعد الأسئلة الشائعة التالية في شرح الأساس المنطقي
وأفضل الممارسات لاستخدام هذه الميزة.
لماذا يجب أن يبلِّغ التطبيق عن الاستثناءات غير المرصودة على أنّها حالات وفاة؟
عند الإبلاغ عن الاستثناءات غير المرصودة باعتبارها أحداثًا فادحة، ستحصل على مؤشر أكثر واقعية
لالاستثناءات التي قد تؤدي إلى تعذُّر تشغيل اللعبة، حتى في حال استمرار
تشغيل التطبيق.
ملاحظة: إذا بدأت الإبلاغ عن البيانات الفادحة، من المرجّح أن تنخفض النسبة المئوية للمستخدمين الذين لم يواجهوا أعطالاً، إلا أنّ مقياس هذا المقياس سيكون أكثر تمثيلاً لتجارب المستخدمين النهائيين مع تطبيقك.
ما الاستثناءات التي سيتم الإبلاغ
عنها على أنها فادحة؟
لكي يبلِّغ تطبيق 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 علاج Migrate.
يُرجى العلم أنّه إذا كنت تريد طباعة استثناء مُستبعَد من وحدة التحكّم 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
//
}
