توفر هذه الصفحة تعليمات حول استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول استخدام 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 +) .
تمثل القيمة الخالية من الأعطال النسبة المئوية للمستخدمين الذين تفاعلوا مع تطبيقك ولكن لم يتعرضوا لأي عطل خلال فترة زمنية محددة.
هذه هي الصيغة لحساب نسبة المستخدمين الخالية من الأعطال. يتم توفير قيم الإدخال الخاصة به بواسطة 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
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات المنشورة حول مشكلة ، لكن لا يمكنهم حذف ملاحظة أو كتابتها.
- عارض المشروع أو عارض Firebase أو عارض الجودة أو عارض Crashlytics
تكاملات
إذا كان مشروعك يستخدم Crashlytics جنبًا إلى جنب مع Google Mobile Ads SDK ، فمن المحتمل أن يتدخل المراسلون المعنيون بالأعطال عند تسجيل معالجات الاستثناءات. لإصلاح المشكلة ، قم بإيقاف تشغيل إعداد التقارير عن الأعطال في SDK لإعلانات الجوال من خلال استدعاء disableSDKCrashReporting .
بعد ربط Crashlytics بـ BigQuery ، توجد مجموعات البيانات الجديدة التي تنشئها تلقائيًا في الولايات المتحدة ، بغض النظر عن موقع مشروع Firebase.
دعم المنصة
القضايا المتراجعة
حدث تراجع في إحدى المشكلات عندما أغلقت المشكلة مسبقًا ولكن Crashlytics تحصل على تقرير جديد يفيد بأن المشكلة قد حدثت مرة أخرى. تعيد Crashlytics فتح هذه المشكلات المتراجعة تلقائيًا بحيث يمكنك معالجتها بما يتناسب مع تطبيقك.
فيما يلي مثال على سيناريو يشرح كيف تصنف Crashlytics مشكلة على أنها انحدار:
- لأول مرة على الإطلاق ، تحصل Crashlytics على تقرير عن حادث تحطم "أ". يفتح Crashlytics مشكلة مقابلة لذلك التعطل (المشكلة "أ").
- يمكنك إصلاح هذا الخطأ بسرعة ، وإغلاق المشكلة "أ" ، ثم إطلاق إصدار جديد من تطبيقك.
- يحصل موقع Crashlytics على تقرير آخر حول المشكلة "أ" بعد إغلاق المشكلة.
- إذا كان التقرير من إصدار تطبيق كان Crashlytics على علم به عندما أغلقت المشكلة (بمعنى أن الإصدار أرسل تقرير تعطل لأي عطل على الإطلاق) ، فلن تعتبر Crashlytics المشكلة على أنها تراجعت. ستبقى القضية مغلقة.
- إذا كان التقرير من إصدار تطبيق لم يكن Crashlytics على علم به عندما أغلقت المشكلة (مما يعني أن الإصدار لم يرسل أي تقرير تعطل مطلقًا عن أي عطل على الإطلاق) ، فإن Crashlytics تعتبر أن المشكلة تراجعت وستعيد فتح المشكلة .
عندما تتراجع إحدى المشكلات ، نرسل تنبيهًا لاكتشاف الانحدار ونضيف إشارة تراجع إلى المشكلة لإعلامك بأن Crashlytics أعادت فتح المشكلة. إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا ، فقم بكتم المشكلة بدلاً من إغلاقها.
إذا كان أحد التقارير من إصدار تطبيق قديم لم يرسل مطلقًا أي تقارير أعطال على الإطلاق عند إغلاق المشكلة ، فإن Crashlytics تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة.
يمكن أن يحدث هذا الموقف في الموقف التالي: لقد أصلحت خطأ وأصدرت إصدارًا جديدًا من تطبيقك ، ولكن لا يزال لديك مستخدمون على إصدارات أقدم بدون إصلاح الخطأ. إذا لم يرسل أحد هذه الإصدارات القديمة ، عن طريق الصدفة ، أي تقارير أعطال على الإطلاق عند إغلاق المشكلة ، وبدأ هؤلاء المستخدمون في مواجهة الخطأ ، فإن تقارير الأعطال هذه ستطلق مشكلة تراجع.
إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا ، فقم بكتم المشكلة بدلاً من إغلاقها.