توفر هذه الصفحة مساعدة في استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول استخدام 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+ — الإصدار 6.3.1+ (الإصدار 8.9.0+ لنظامي التشغيل macOS وtvOS) | أندرويد - الإصدار 17.2.3+ (BoM الإصدار 24.7.1+) .
قد تلاحظ تنسيقين مختلفين للمشكلات المدرجة في جدول المشكلات في وحدة تحكم Firebase. وقد تلاحظ أيضًا ميزة تسمى "المتغيرات" في بعض مشكلاتك. هذا هو السبب!
في أوائل عام 2023، طرحنا محرك تحليل محسّنًا لتجميع الأحداث بالإضافة إلى تصميم محدث وبعض الميزات المتقدمة للمشاكل الجديدة (مثل المتغيرات!). قم بمراجعة منشور مدونتنا الأخير للحصول على كافة التفاصيل، ولكن يمكنك القراءة أدناه للحصول على النقاط البارزة.
يقوم Crashlytics بتحليل جميع الأحداث من تطبيقك (مثل الأعطال، والحالات غير المميتة، وأخطاء ANR) وإنشاء مجموعات من الأحداث تسمى المشكلات - جميع الأحداث في مشكلة ما لها نقطة فشل مشتركة.
لتجميع الأحداث في هذه المشكلات، يبحث محرك التحليل المحسّن الآن في العديد من جوانب الحدث، بما في ذلك الإطارات الموجودة في تتبع المكدس، ورسالة الاستثناء، ورمز الخطأ، وخصائص النظام الأساسي أو نوع الخطأ الأخرى.
ومع ذلك، ضمن هذه المجموعة من الأحداث، قد تكون تتبعات المكدس التي تؤدي إلى الفشل مختلفة. قد يعني تتبع المكدس المختلف سببًا جذريًا مختلفًا. لتمثيل هذا الاختلاف المحتمل داخل مشكلة ما، نقوم الآن بإنشاء متغيرات داخل المشكلات - كل متغير عبارة عن مجموعة فرعية من الأحداث في مشكلة لها نفس نقطة الفشل وتتبع مكدس مماثل. باستخدام المتغيرات، يمكنك تصحيح أخطاء تتبعات المكدس الأكثر شيوعًا داخل المشكلة وتحديد ما إذا كانت الأسباب الجذرية المختلفة هي التي تؤدي إلى الفشل.
إليك ما ستختبره مع هذه التحسينات:
يتم عرض البيانات التعريفية المجددة داخل صف المشكلة
أصبح من السهل الآن فهم المشكلات وفرزها في تطبيقك.عدد أقل من القضايا المكررة
لا يؤدي تغيير رقم السطر إلى مشكلة جديدة.تصحيح أسهل للمشكلات المعقدة ذات الأسباب الجذرية المختلفة
استخدم المتغيرات لتصحيح أخطاء تتبعات المكدس الأكثر شيوعًا داخل المشكلة.المزيد من التنبيهات والإشارات ذات مغزى
تمثل المشكلة الجديدة في الواقع خطأً جديدًا.بحث أكثر قوة
تحتوي كل مشكلة على المزيد من البيانات التعريفية القابلة للبحث، مثل نوع الاستثناء واسم الحزمة.
وإليك كيفية نشر هذه التحسينات:
عندما نحصل على أحداث جديدة من تطبيقك، سنتحقق مما إذا كانت تتطابق مع مشكلة موجودة أم لا.
إذا لم يكن هناك تطابق، فسنطبق تلقائيًا خوارزمية تجميع الأحداث الأكثر ذكاءً على الحدث وننشئ مشكلة جديدة من خلال تصميم البيانات التعريفية المتجدد.
هذا هو أول تحديث كبير نجريه على مجموعة الأحداث الخاصة بنا. إذا كانت لديك تعليقات أو واجهت أي مشكلات، فيرجى إبلاغنا بذلك عن طريق تقديم تقرير.
تمثل القيمة الخالية من الأعطال النسبة المئوية للمستخدمين الذين تفاعلوا مع تطبيقك ولكن لم يتعرضوا لأي عطل خلال فترة زمنية محددة.
فيما يلي صيغة حساب النسبة المئوية للمستخدمين الخاليين من الأعطال. يتم توفير قيم الإدخال الخاصة به بواسطة Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
عند حدوث عطل، يرسل Google Analytics نوع حدث
app_exception، ويمثل CRASHED_USERS عدد المستخدمين المرتبطين بنوع الحدث هذا.يمثل ALL_USERS إجمالي عدد المستخدمين الذين تفاعلوا مع تطبيقك خلال الفترة الزمنية التي حددتها من القائمة المنسدلة في الجزء العلوي الأيسر من لوحة معلومات Crashlytics.
النسبة المئوية للمستخدمين الخاليين من الأعطال هي عبارة عن تجميع بمرور الوقت ، وليست متوسطًا.
على سبيل المثال، تخيل أن تطبيقك لديه ثلاثة مستخدمين؛ سنسميهم المستخدم أ، والمستخدم ب، والمستخدم ج. ويوضح الجدول التالي المستخدمين الذين تفاعلوا مع تطبيقك كل يوم وأي من هؤلاء المستخدمين تعرض لعطل في ذلك اليوم:
| الاثنين | يوم الثلاثاء | الأربعاء | |
|---|---|---|---|
| المستخدمون الذين تفاعلوا مع تطبيقك | أ، ب، ج | أ، ب، ج | أ، ب |
| المستخدم الذي تعرض لحادث | ج | ب | أ |
في يوم الأربعاء، بلغت نسبة المستخدمين الذين لم يتعرضوا لأي أعطال إلى 50% (كان مستخدم واحد من أصل مستخدمين خاليًا من الأعطال).
تفاعل اثنان من المستخدمين مع تطبيقك يوم الأربعاء، ولكن واحدًا منهم فقط (المستخدم ب) لم يتعرض لأي أعطال.خلال اليومين الماضيين، بلغت نسبة المستخدمين الذين لم يتعرضوا لأي أعطال 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 على تقرير عطل حول Crash "A". يفتح Crashlytics مشكلة مقابلة لهذا العطل (الإصدار "أ").
- يمكنك إصلاح هذا الخطأ بسرعة، وإغلاق المشكلة "أ"، ثم إصدار إصدار جديد من تطبيقك.
- تحصل Crashlytics على تقرير آخر حول المشكلة "أ" بعد إغلاق المشكلة.
- إذا كان التقرير من إصدار تطبيق عرفته Crashlytics عندما أغلقت المشكلة (بمعنى أن الإصدار قد أرسل تقرير تعطل عن أي عطل على الإطلاق)، فلن تعتبر Crashlytics أن المشكلة تراجعت. ستبقى القضية مغلقة.
- إذا كان التقرير من إصدار تطبيق لم تكن Crashlytics على علم به عندما أغلقت المشكلة (بمعنى أن الإصدار لم يرسل أبدًا أي تقرير تعطل عن أي عطل على الإطلاق)، فإن Crashlytics تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة .
عندما تتراجع مشكلة ما، نرسل تنبيهًا للكشف عن الانحدار ونضيف إشارة تراجع إلى المشكلة لإعلامك بأن Crashlytics أعادت فتح المشكلة. إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا، فقم "بتجاهل" المشكلة بدلاً من إغلاقها.
إذا كان التقرير من إصدار تطبيق قديم لم يرسل مطلقًا أي تقارير أعطال على الإطلاق عندما أغلقت المشكلة، فإن Crashlytics تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة.
يمكن أن يحدث هذا الموقف في الموقف التالي: لقد قمت بإصلاح الخلل وإصدار إصدار جديد من تطبيقك، ولكن لا يزال لديك مستخدمين على الإصدارات الأقدم دون إصلاح الخلل. إذا، عن طريق الصدفة، لم يرسل أحد هذه الإصدارات الأقدم أي تقارير أعطال على الإطلاق عندما أغلقت المشكلة، وبدأ هؤلاء المستخدمون في مواجهة الخطأ، فإن تقارير الأعطال هذه ستؤدي إلى حدوث مشكلة تراجعية.
إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا، فقم "بتجاهل" المشكلة بدلاً من إغلاقها.