تحديد المشاكل وحلّها في Crashlytics والأسئلة الشائعة بشأنها
تقدّم هذه الصفحة مساعدة في تحديد المشاكل وحلّها وإجابات عن الأسئلة الشائعة حول استخدام Crashlytics. إذا لم تتمكّن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية، يُرجى التواصل مع فريق دعم Firebase.
تحديد المشاكل وحلّها بشكل عام/الأسئلة الشائعة
ظهور تنسيقات مختلفة (وأحيانًا "صيغ") لبعض المشاكل في جدول المشاكل
قد تلاحظ تنسيقَين مختلفَين للمشاكل المُدرَجة في جدول المشاكل
في Firebase Console. وقد تلاحظ أيضًا ميزة تُسمى "المتغيرات" ضمن بعض المشاكل. إليك السبب:
في أوائل عام 2023، طرحنا محرّك تحليل محسّنًا لتجميع الأحداث، بالإضافة إلى تصميم معدَّل وبعض الميزات المتقدّمة للمشاكل الجديدة (مثل المشاكل المتشابهة). يمكنك الاطّلاع على مشاركة المدونة الأخيرة للحصول على جميع التفاصيل، أو قراءة النقاط البارزة أدناه.
تحلّل Crashlytics جميع الأحداث من تطبيقك (مثل الأعطال والأخطاء غير الفادحة وأخطاء ANR) وتنشئ مجموعات من الأحداث تُسمّى المشاكل، إذ تشترك جميع الأحداث في إحدى المشاكل في نقطة تعذُّر مشتركة.
لتجميع الأحداث في هذه المشاكل، يبحث محرّك التحليل المحسّن الآن في العديد من جوانب الحدث، بما في ذلك اللقطات في تتبُّع تسلسل استدعاء الدوال البرمجية ورسالة الاستثناء ورمز الخطأ وخصائص أخرى للنظام الأساسي أو نوع الخطأ.
ومع ذلك، ضمن مجموعة الأحداث هذه، قد تختلف عمليات تتبُّع تسلسل استدعاء الدوال البرمجية التي تؤدي إلى حدوث الخطأ. وقد يشير تتبُّع تسلسل استدعاء الدوال البرمجية المختلف إلى سبب جذري مختلف.
لتمثيل هذا الاختلاف المحتمل ضمن إحدى المشاكل، ننشئ الآن خيارات ضمن المشاكل، وكل خيار هو مجموعة فرعية من الأحداث في إحدى المشاكل التي تتضمّن نقطة تعذُّر وتتبُّع تسلسل استدعاء الدوال البرمجية مشابهًا. باستخدام المتغيرات،
يمكنك تصحيح الأخطاء في تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن إحدى المشاكل وتحديد ما إذا كانت
الأسباب الجذرية المختلفة تؤدي إلى حدوث الخطأ.
في ما يلي التغييرات التي ستلاحظها بعد تطبيق هذه التحسينات:
تجديد البيانات الوصفية المعروضة ضمن صف المشكلة أصبح من الأسهل الآن فهم المشاكل في تطبيقك وتصنيفها.
عدد أقل من المشاكل المكرّرة لا يؤدي تغيير رقم السطر إلى ظهور مشكلة جديدة.
تسهيل تصحيح الأخطاء المعقّدة التي لها أسباب جذرية مختلفة استخدِم الصيغ لتصحيح أخطاء تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن إحدى المشاكل.
تنبيهات وإشارات أكثر فائدة تمثّل المشكلة الجديدة خطأً جديدًا.
بحث أكثر فعالية تحتوي كل مشكلة على بيانات وصفية قابلة للبحث،
مثل نوع الاستثناء واسم الحزمة.
إليك طريقة طرح هذه التحسينات:
عندما نتلقّى أحداثًا جديدة من تطبيقك، سنتحقّق مما إذا كانت تتطابق مع مشكلة حالية.
في حال عدم العثور على تطابق، سنطبّق تلقائيًا خوارزمية أكثر ذكاءً لتجميع الأحداث، وسننشئ مشكلة جديدة باستخدام تصميم معدَّل للبيانات الوصفية.
هذا هو التعديل الكبير الأول الذي نجريه على عملية تجميع الأحداث. إذا كانت لديك ملاحظات أو واجهت أي مشاكل، يُرجى إعلامنا بذلك من خلال
إرسال تقرير.
عدم ظهور سجلّات شريط التنقّل
إذا لم تظهر لك سجلات مسار التنقل، ننصحك بالتحقّق من إعدادات تطبيقك بحثًا عن Google Analytics.
يجب استيفاء المتطلبات التالية:
لقد
تطبيقك. يجب إضافة حزمة تطوير البرامج (SDK) هذه بالإضافة إلى حزمة تطوير البرامج (SDK) Crashlytics.
استخدام
لجميع المنتجات التي تستخدمها في تطبيقك
عدم ظهور تنبيهات السرعة
إذا لم تظهر لك تنبيهات السرعة، تأكَّد من أنّك تستخدم
عدم ظهور مقاييس خالية من الأعطال (أو ظهور مقاييس غير موثوق بها)
إذا لم تظهر لك مقاييس خالية من الأعطال (مثل المستخدمين والجلسات الخالية من الأعطال) أو ظهرت لك مقاييس غير موثوقة، تحقَّق مما يلي:
تأكَّد من استخدام
تأكَّد من أنّ إعدادات جمع البيانات لا تؤثّر في جودة مقاييسك الخالية من الأعطال:
في حال
تفعيل ميزة إعداد التقارير عند الموافقة
من خلال إيقاف ميزة إعداد تقارير الأعطال التلقائي، لا يمكن إرسال معلومات الأعطال
إلى Crashlytics إلا من المستخدمين الذين وافقوا صراحةً على جمع البيانات. وبالتالي، ستتأثر دقة مقاييس عدم حدوث الأعطال لأنّ Crashlytics لا يتضمّن سوى معلومات الأعطال من هؤلاء المستخدمين الذين وافقوا على مشاركة البيانات (بدلاً من جميع المستخدمين). وهذا يعني أنّ مقاييسك الخاصة بعدم حدوث أعطال قد تكون أقل موثوقية وأقل تعبيرًا عن الثبات العام لتطبيقك.
إذا كانت ميزة جمع البيانات تلقائيًا غير مفعّلة، يمكنك استخدام
sendUnsentReports لإرسال التقارير المخزّنة مؤقتًا على الجهاز إلى Crashlytics.
سيؤدي استخدام هذه الطريقة إلى إرسال بيانات الأعطال إلى Crashlytics، ولكن ليس بيانات الجلسات، ما يؤدي إلى عرض قيم منخفضة أو صفرية في رسومات وحدة التحكّم البيانية لمقاييس "خالٍ من الأعطال".
كيف يتم احتساب عدد المستخدمين الذين لم يواجهوا أي تعطُّل؟
مَن يمكنه عرض الملاحظات وكتابتها وحذفها في إحدى المشاكل؟
تتيح الملاحظات لأعضاء المشروع التعليق على مشاكل معيّنة من خلال طرح أسئلة أو تقديم معلومات عن الحالة أو غير ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها باستخدام البريد الإلكتروني لحسابه على Google. يظهر عنوان البريد الإلكتروني هذا، بالإضافة إلى الملاحظة، لجميع أعضاء المشروع الذين لديهم إذن بالاطّلاع على الملاحظة.
في ما يلي وصف لأذونات الوصول المطلوبة لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات الحالية وحذفها وكتابة ملاحظات جديدة بشأن مشكلة.
يستخدم التطبيق أيضًا حزمة تطوير البرامج (SDK) الخاصة بـ "Google Mobile Ads"، ولكن لا تحدث أعطال
إذا كان مشروعك يستخدم Crashlytics إلى جانب حزمة تطوير البرامج (SDK) الخاصة بـ Google Mobile Ads، من المحتمل أن تتداخل أدوات تسجيل الأعطال عند تسجيل معالجات الاستثناءات. لحلّ المشكلة، أوقِف ميزة "إعداد تقارير الأعطال" في حزمة تطوير البرامج (SDK) الخاصة بـ Mobile Ads من خلال استدعاء disableSDKCrashReporting.
أين تقع مجموعة بيانات BigQuery؟
بعد ربط Crashlytics بخدمة BigQuery، يتم تلقائيًا تحديد موقع مجموعات البيانات الجديدة التي تنشئها في الولايات المتحدة، بغض النظر عن موقع مشروعك على Firebase.
الأنظمة الأساسية المتوافقة
المشاكل التي تكرّرت
ما هي المشكلة التي تم التراجع عنها؟
تحدث مشكلة متكررة عندما تكون قد أغلقت المشكلة سابقًا ولكن
Crashlytics تتلقّى بلاغًا جديدًا بأنّ المشكلة قد تكررت.
تعيد Crashlytics تلقائيًا فتح هذه المشاكل التي تم حلّها سابقًا حتى تتمكّن من معالجتها بما يتناسب مع تطبيقك.
في ما يلي مثال على سيناريو يوضّح كيف تصنّف Crashlytics مشكلة على أنّها تراجع:
لأول مرة على الإطلاق، يتلقّى Crashlytics تقرير عُطل بشأن العُطل
"أ". يؤدي Crashlytics إلى فتح مشكلة ذات صلة بهذا التعطُّل (المشكلة "أ").
يمكنك إصلاح هذا الخطأ بسرعة وإغلاق المشكلة "أ"، ثم طرح إصدار جديد من تطبيقك.
تتلقّى Crashlytics تقريرًا آخر بشأن المشكلة "أ" بعد إغلاقك لها.
إذا كان التقرير من إصدار تطبيق Crashlyticsعلى علم به عند إغلاق المشكلة (ما يعني أنّ الإصدار أرسل تقريرًا عن تعطُّل أي تعطُّل على الإطلاق)، لن تعتبر Crashlytics المشكلة متكرّرة. سيظل الطلب مغلقًا.
إذا كان التقرير من إصدار تطبيق Crashlyticsلم يكن
على علم به عند إغلاق المشكلة (ما يعني أنّ الإصدار لم يرسل أي تقرير تعطل لأي تعطل على الإطلاق)، ستعتبر Crashlytics المشكلة قد تكرّرت وسيتم إعادة فتحها.
عندما تتكرّر مشكلة، نرسل تنبيهًا بشأن رصد تكرار المشكلة ونضيف إشارة تكرار إلى المشكلة لإعلامك بأنّ Crashlytics قد أعاد فتح المشكلة. إذا كنت لا تريد إعادة فتح مشكلة بسبب خوارزمية التراجع، يمكنك "كتم" المشكلة بدلاً من إغلاقها.
لماذا تظهر لي مشاكل متكرّرة في الإصدارات القديمة من التطبيق؟
إذا كان التقرير من إصدار قديم من التطبيق لم يسبق له إرسال أي تقارير أعطال على الإطلاق عند إغلاق المشكلة، ستعتبر Crashlytics المشكلة متكررة وستعيد فتحها.
يمكن أن يحدث ذلك في الحالات التالية: لقد أصلحت خطأ وأصدرت إصدارًا جديدًا من تطبيقك، ولكن لا يزال لديك مستخدمون يستخدمون إصدارات قديمة لم يتم إصلاح الخطأ فيها. إذا حدث أنّه لم يتم إرسال أي تقارير أعطال أبدًا من خلال إحدى الإصدارات القديمة عند إغلاق المشكلة، وبدأ المستخدمون يواجهون الخطأ، ستؤدي تقارير الأعطال هذه إلى حدوث مشكلة متكررة.
إذا كنت لا تريد إعادة فتح مشكلة بسبب خوارزمية التراجع، يمكنك "كتم" المشكلة بدلاً من إغلاقها.
