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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• لقد إلى تطبيقك. يجب إضافة حزمة تطوير البرامج هذه بالإضافة إلى حزمة تطوير البرامج Crashlytics.

• استخدام لجميع المنتجات التي تستخدمها في تطبيقك

عدم ظهور تنبيهات السرعة

إذا لم تظهر لك تنبيهات السرعة، تأكَّد من استخدام:

عدم ظهور مقاييس خالية من الأعطال (أو ظهور مقاييس غير موثوقة)

إذا لم تظهر لك مقاييس خالية من الأعطال (مثل المستخدمين والجلسات الخالية من الأعطال) أو إذا كانت تظهر لك مقاييس غير موثوقة، تحقّق مما يلي:

• تأكَّد من استخدام

• تأكَّد من أنّ إعدادات جمع البيانات لا تؤثّر في جودة مقاييس عدم حدوث الأعطال:

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

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

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

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

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

تتيح الملاحظات لأعضاء المشروع التعليق على مشاكل معيّنة من خلال طرح أسئلة أو إرسال رسائل بشأن الحالة أو غيرها.

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

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

لماذا تظهر لي مشاكل تتعلّق بالأداء المنخفض في الإصدارات القديمة من التطبيق؟

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

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

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