توفر هذه الصفحة تعليمات حول استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول استخدام Crashlytics. إذا لم تتمكن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية ، فاتصل بدعم Firebase .
استكشاف الأخطاء وإصلاحها / الأسئلة الشائعة العامة
إذا كنت لا ترى مستخدمين خالين من الأعطال و / أو سجلات مسارات التنقل و / أو تنبيهات السرعة ، فإننا نوصي بالتحقق من تكوين تطبيقك لـ Google Analytics.
تأكد من تمكين Google Analytics في مشروع Firebase.
تأكد من تمكين مشاركة البيانات لـ Google Analytics في صفحة التكامل > صفحة Google Analytics بوحدة تحكم Firebase. لاحظ أنه يتم عرض إعدادات مشاركة البيانات في وحدة تحكم Firebase ولكن تتم إدارتها في وحدة تحكم Google Analytics.
بالإضافة إلى Firebase Crashlytics SDK ، تأكد من إضافة Firebase SDK لـ Google Analytics إلى تطبيقك ( iOS + | Android ).
تأكد من أنك تستخدم أحدث الإصدارات لجميع حزم Firebase SDK ( iOS + | Android ).
تحقق بشكل خاص من أنك تستخدم على الأقل الإصدارات التالية من Firebase SDK لـ Google Analytics: iOS + - v6.3.1 + (v8.9.0 + لنظام macOS و tvOS) | Android - v17.2.3 +(BoM v24.7.1 +) .
قد تلاحظ تنسيقين مختلفين للمشكلات المدرجة في جدول المشكلات في وحدة تحكم Firebase. وقد تلاحظ أيضًا ميزة تسمى "المتغيرات" في بعض مشكلاتك. إليكم السبب!
في أوائل عام 2023 ، طرحنا محرك تحليل محسّنًا لتجميع الأحداث بالإضافة إلى تصميم محدث وبعض الميزات المتقدمة للمشكلات الجديدة (مثل المتغيرات!). تحقق من منشور المدونة الأخير الخاص بنا للحصول على جميع التفاصيل ، ولكن يمكنك القراءة أدناه للحصول على النقاط البارزة.
تحلل Crashlytics جميع الأحداث من تطبيقك (مثل الأعطال ، والأحداث غير المميتة ، و ANRs) وتنشئ مجموعات من الأحداث تسمى المشكلات - كل الأحداث في مشكلة لها نقطة فشل مشتركة.
لتجميع الأحداث في هذه المشكلات ، يبحث محرك التحليل المحسّن الآن في العديد من جوانب الحدث ، بما في ذلك الإطارات في تتبع المكدس ورسالة الاستثناء ورمز الخطأ وخصائص نوع الخطأ والنظام الأساسي الأخرى.
ومع ذلك ، ضمن هذه المجموعة من الأحداث ، قد تكون آثار المكدس التي تؤدي إلى الفشل مختلفة. قد يعني تتبع المكدس المختلف سببًا جذريًا مختلفًا. لتمثيل هذا الاختلاف المحتمل في إحدى المشكلات ، نقوم الآن بإنشاء متغيرات داخل المشكلات - كل متغير عبارة عن مجموعة فرعية من الأحداث في مشكلة لها نفس نقطة الفشل وتتبع مكدس مماثل. باستخدام المتغيرات ، يمكنك تصحيح أخطاء تتبعات المكدس الأكثر شيوعًا داخل المشكلة وتحديد ما إذا كانت الأسباب الجذرية المختلفة تؤدي إلى الفشل.
إليك ما ستختبره بهذه التحسينات:
عرض البيانات الوصفية المُجدَّدة في صف الإصدار
أصبح الآن من السهل فهم المشكلات وترتيبها في تطبيقك.عدد أقل من المشكلات المكررة
لا ينتج عن تغيير رقم السطر مشكلة جديدة.تصحيح أسهل للمشكلات المعقدة ذات الأسباب الجذرية المختلفة
استخدم المتغيرات لتصحيح أخطاء تتبع المكدس الأكثر شيوعًا داخل المشكلة.المزيد من التنبيهات والإشارات ذات مغزى
يمثل الإصدار الجديد خطأً جديدًا في الواقع.بحث أكثر قوة
تحتوي كل مشكلة على المزيد من البيانات الوصفية القابلة للبحث ، مثل نوع الاستثناء واسم الحزمة.
إليك كيفية طرح هذه التحسينات:
عندما نحصل على أحداث جديدة من تطبيقك ، سنتحقق مما إذا كانت تتطابق مع مشكلة حالية.
إذا لم يكن هناك تطابق ، فسنطبق تلقائيًا خوارزمية تجميع الأحداث الأكثر ذكاءً على الحدث وننشئ مشكلة جديدة مع تصميم البيانات الوصفية الذي تم تجديده.
هذا هو أول تحديث كبير نجريه لمجموعات الأحداث لدينا. إذا كانت لديك ملاحظات أو واجهت أي مشاكل ، فيرجى إخبارنا عن طريق تقديم تقرير.
تمثل القيمة الخالية من الأعطال النسبة المئوية للمستخدمين الذين تفاعلوا مع تطبيقك ولكن لم يتعرضوا لأي عطل خلال فترة زمنية محددة.
هذه هي الصيغة لحساب نسبة المستخدمين الخالية من الأعطال. يتم توفير قيم الإدخال الخاصة به بواسطة Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
عند حدوث عطل ، يرسل Google Analytics نوع حدث
app_exception، ويمثل CRASHED_USERS عدد المستخدمين المرتبطين بهذا النوع من الأحداث.يمثل ALL_USERS إجمالي عدد المستخدمين الذين تفاعلوا مع تطبيقك خلال الفترة الزمنية التي حددتها من القائمة المنسدلة في الجزء العلوي الأيسر من لوحة تحكم Crashlytics.
تعتبر النسبة المئوية للمستخدمين الذين لا يعانون من الأعطال تجميعًا بمرور الوقت ، وليست متوسطًا.
على سبيل المثال ، تخيل أن لتطبيقك ثلاثة مستخدمين ؛ سنطلق عليهم اسم المستخدم أ والمستخدم ب والمستخدم ج. يوضح الجدول التالي المستخدمين الذين تفاعلوا مع تطبيقك كل يوم وأي من هؤلاء المستخدمين تعرض لعطل في ذلك اليوم:
| الاثنين | يوم الثلاثاء | الأربعاء | |
|---|---|---|---|
| المستخدمون الذين تفاعلوا مع تطبيقك | أ ، ب ، ج | أ ، ب ، ج | أ ، ب |
| المستخدم الذي تعرض لانهيار | ج | ب | أ |
يوم الأربعاء ، تبلغ نسبة المستخدمين الذين لا يعانون من الأعطال 50٪ (1 من 2 مستخدم خالٍ من الأعطال).
تفاعل اثنان من المستخدمين لديك مع تطبيقك يوم الأربعاء ، لكن واحدًا منهم فقط (المستخدم ب) لم يتعرض لأي أعطال.خلال اليومين الماضيين ، كانت نسبة المستخدمين الذين لم يتعرضوا للأعطال 33.3٪ (1 من 3 مستخدمين خالٍ من الأعطال).
تفاعل ثلاثة من مستخدميك مع تطبيقك خلال اليومين الماضيين ، لكن واحدًا منهم فقط (المستخدم ج) لم يتعرض لأي أعطال.خلال الأيام الثلاثة الماضية ، كانت نسبة المستخدمين الذين لم يتعرضوا لأي أعطال 0٪ (0 من أصل 3 مستخدمين كانوا خاليين من الأعطال).
تفاعل ثلاثة من مستخدميك مع تطبيقك على مدار الأيام الثلاثة الماضية ، ولكن لم يتعرض أي منهم لأي أعطال.
تسمح الملاحظات لأعضاء المشروع بالتعليق على قضايا محددة تتعلق بالأسئلة وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة ، يتم تصنيفها بالبريد الإلكتروني لحساب Google الخاص به. يكون عنوان البريد الإلكتروني هذا مرئيًا مع الملاحظة لجميع أعضاء المشروع الذين لديهم حق الوصول لعرض الملاحظة.
فيما يلي وصف للوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات المنشورة حول مشكلة ، لكن لا يمكنهم حذف ملاحظة أو كتابتها.
- عارض المشروع أو عارض Firebase أو عارض الجودة أو عارض Crashlytics
تكاملات
إذا كان مشروعك يستخدم Crashlytics جنبًا إلى جنب مع Google Mobile Ads SDK ، فمن المحتمل أن يتدخل المراسلون المعنيون بالأعطال عند تسجيل معالجات الاستثناءات. لإصلاح المشكلة ، قم بإيقاف تشغيل إعداد التقارير عن الأعطال في SDK لإعلانات الجوال من خلال استدعاء disableSDKCrashReporting .
بعد ربط Crashlytics بـ BigQuery ، توجد مجموعات البيانات الجديدة التي تنشئها تلقائيًا في الولايات المتحدة ، بغض النظر عن موقع مشروع Firebase.
دعم المنصة
القضايا المتراجعة
حدث تراجع في إحدى المشكلات عندما أغلقت المشكلة مسبقًا ولكن Crashlytics تحصل على تقرير جديد يفيد بأن المشكلة قد حدثت مرة أخرى. تعيد Crashlytics فتح هذه المشكلات المتراجعة تلقائيًا بحيث يمكنك معالجتها بما يتناسب مع تطبيقك.
فيما يلي مثال على سيناريو يشرح كيف تصنف Crashlytics مشكلة على أنها انحدار:
- لأول مرة على الإطلاق ، تحصل Crashlytics على تقرير عن حادث تحطم "أ". يفتح Crashlytics مشكلة مقابلة لذلك التعطل (المشكلة "أ").
- يمكنك إصلاح هذا الخطأ بسرعة ، وإغلاق المشكلة "أ" ، ثم إطلاق إصدار جديد من تطبيقك.
- يحصل موقع Crashlytics على تقرير آخر حول المشكلة "أ" بعد إغلاق المشكلة.
- إذا كان التقرير من إصدار تطبيق كان Crashlytics على علم به عندما أغلقت المشكلة (بمعنى أن الإصدار أرسل تقرير تعطل لأي عطل على الإطلاق) ، فلن تعتبر Crashlytics المشكلة على أنها تراجعت. ستبقى القضية مغلقة.
- إذا كان التقرير من إصدار تطبيق لم يكن Crashlytics على علم به عندما أغلقت المشكلة (مما يعني أن الإصدار لم يرسل أي تقرير تعطل مطلقًا عن أي عطل على الإطلاق) ، فإن Crashlytics تعتبر أن المشكلة تراجعت وستعيد فتح المشكلة .
عندما تتراجع إحدى المشكلات ، نرسل تنبيهًا لاكتشاف الانحدار ونضيف إشارة تراجع إلى المشكلة لإعلامك بأن Crashlytics أعادت فتح المشكلة. إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا ، فقم بكتم المشكلة بدلاً من إغلاقها.
إذا كان أحد التقارير من إصدار تطبيق قديم لم يرسل مطلقًا أي تقارير أعطال على الإطلاق عند إغلاق المشكلة ، فإن Crashlytics تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة.
يمكن أن يحدث هذا الموقف في الموقف التالي: لقد أصلحت خطأ وأصدرت إصدارًا جديدًا من تطبيقك ، ولكن لا يزال لديك مستخدمون على إصدارات أقدم بدون إصلاح الخطأ. إذا لم يرسل أحد هذه الإصدارات القديمة ، عن طريق الصدفة ، أي تقارير أعطال على الإطلاق عند إغلاق المشكلة ، وبدأ هؤلاء المستخدمون في مواجهة الخطأ ، فإن تقارير الأعطال هذه ستطلق مشكلة تراجع.
إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا ، فقم بكتم المشكلة بدلاً من إغلاقها.