توفر هذه الصفحة مساعدة في استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول استخدام 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 تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة.
يمكن أن يحدث هذا الموقف في الموقف التالي: لقد قمت بإصلاح الخلل وإصدار إصدار جديد من تطبيقك، ولكن لا يزال لديك مستخدمين على الإصدارات الأقدم دون إصلاح الخلل. إذا، عن طريق الصدفة، لم يرسل أحد هذه الإصدارات الأقدم أي تقارير أعطال على الإطلاق عندما أغلقت المشكلة، وبدأ هؤلاء المستخدمون في مواجهة الخطأ، فإن تقارير الأعطال هذه ستؤدي إلى حدوث مشكلة تراجعية.
إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا، فقم "بتجاهل" المشكلة بدلاً من إغلاقها.
,توفر هذه الصفحة مساعدة في استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول استخدام 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.
النسبة المئوية للمستخدمين الخالية من الانهيارات هي عبارة عن تجميع مع مرور الوقت ، وليس متوسطًا.
على سبيل المثال ، تخيل أن تطبيقك يحتوي على ثلاثة مستخدمين ؛ سنطلق عليهم المستخدم A ، والمستخدم B ، والمستخدم C. يوضح الجدول التالي المستخدمين الذين يشاركون في تطبيقك كل يوم وأي من هؤلاء المستخدمين تعطل في ذلك اليوم:
| الاثنين | يوم الثلاثاء | الأربعاء | |
|---|---|---|---|
| المستخدمين الذين شاركوا في تطبيقك | أ، ب، ج | أ، ب، ج | أ، ب |
| المستخدم الذي تعطل | ج | ب | أ |
يوم الأربعاء ، تبلغ نسبة مستخدميك الخالية من الانهيار 50 ٪ (1 من أصل 2 مستخدمين كانت خالية من الانهيار).
شارك اثنان من المستخدمين في تطبيقك يوم الأربعاء ، ولكن واحد منهم فقط (المستخدم ب) لم يكن لديه أي حوادث.على مدار اليومين الماضيين ، تبلغ نسبة المستخدمين الخالية من الانهيار 33.3 ٪ (1 من أصل 3 مستخدمين كانت خالية من الانهيار).
ثلاثة من المستخدمين يعملون مع تطبيقك على مدار اليومين الماضيين ، ولكن واحد منهم فقط (المستخدم C) لم يكن لديه أي تعطل.خلال الأيام الثلاثة الماضية ، تكون نسبة المستخدمين الخالية من الانهيار 0 ٪ (0 من أصل 3 مستخدمين كانوا خالية من الانهيار).
ثلاثة من المستخدمين يعملون مع تطبيقك على مدار الأيام الثلاثة الماضية ، لكن الصفر منهم لم يكن لديهم أي حوادث.
لا ينبغي مقارنة قيمة المستخدمين الخالية من الانهيار على مدار فترات زمنية مختلفة. إن احتمال وجود مستخدم واحد يعاني من حادث ينمو كلما زاد عدد مرات استخدام التطبيق الخاص بك ، وبالتالي من المحتمل أن تكون قيمة المستخدمين الخالية من الانهيار أصغر لفترات زمنية أطول.
تسمح ملاحظات أعضاء المشروع بالتعليق على مشكلات محددة مع الأسئلة ، تحديثات الحالة ، إلخ.
عندما ينشر أحد أعضاء المشروع ملاحظة ، يتم تصنيفها على البريد الإلكتروني لحساب Google الخاص بهم. عنوان البريد الإلكتروني هذا مرئي ، إلى جانب الملاحظة ، لجميع أعضاء المشروع مع الوصول لعرض الملاحظة.
يصف ما يلي الوصول المطلوب لعرض الملاحظات والكتابة وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض وحذف الملاحظات الحالية وكتابة ملاحظات جديدة حول مشكلة.
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات المنشورة حول مشكلة ، لكن لا يمكنهم حذف أو كتابة ملاحظة.
- عارض المشروع أو عارض Firebase أو عارض الجودة أو عارض CrashlyTics
التكامل
إذا كان مشروعك يستخدم CrashlyTics إلى جانب إعلانات Google Mobile SDK ، فمن المحتمل أن يتدخل مراسلو الأعطال عند تسجيل معالجات الاستثناء. لإصلاح المشكلة ، قم بإيقاف تشغيل تقارير التصادم في إعلانات Mobile SDK عن طريق الاتصال disableSDKCrashReporting .
بعد ربط CrashlyTics إلى BigQuery ، توجد مجموعات بيانات جديدة تنشئها تلقائيًا في الولايات المتحدة ، بغض النظر عن موقع مشروع Firebase الخاص بك.
دعم المنصة
القضايا المتنازع عليها
لقد كان هناك مشكلة في الانحدار عندما تكون قد أغلقت القضية من قبل ، لكن Crashlytics تحصل على تقرير جديد بأن القضية قد أعيد تدريبها. يعيد Crashlytics تلقائيًا فتح هذه المشكلات المتراجع حتى تتمكن من معالجتها حسب الاقتضاء لتطبيقك.
إليك سيناريو مثال يشرح كيف تصنف Crashlytics مشكلة كانحدار:
- لأول مرة على الإطلاق ، يحصل Crashlytics على تقرير تحطم عن تصادم "A". يفتح Crashlytics مشكلة مقابلة لهذا التعطل (القضية "A").
- يمكنك إصلاح هذا الخطأ بسرعة ، وإغلاق المشكلة "A" ، ثم إصدار إصدار جديد من تطبيقك.
- يحصل Crashlytics على تقرير آخر حول القضية "A" بعد إغلاق المشكلة.
- إذا كان التقرير من إصدار تطبيق عرفه Crashlytics عندما أغلقت المشكلة (وهذا يعني أن الإصدار قد أرسل تقريرًا عن التعطل لأي حادث على الإطلاق) ، فلن يعتبر Crashlytics المشكلة على أنها تراجعت. ستبقى القضية مغلقة.
- إذا كان التقرير من إصدار تطبيق لم يعرفه Crashlytics عندما أغلقت المشكلة (وهذا يعني أن الإصدار لم يرسل أي تقرير تصادم لأي حادث على الإطلاق) ، فإن Crashlytics تعتبر المشكلة تراجعت وسوف يعيد فتح المشكلة .
عندما تنحسر مشكلة ما ، نرسل تنبيهًا لاكتشاف الانحدار وإضافة إشارة انحدار إلى القضية لإعلامك بأن Crashlytics قد أعيد فتح المشكلة. إذا كنت لا تريد إعادة فتح مشكلة بسبب خوارزمية الانحدار لدينا ، "كتم" المشكلة بدلاً من إغلاقها.
إذا كان هناك تقرير من إصدار تطبيق قديم لم يرسل أي تقارير تصادم على الإطلاق عند إغلاق المشكلة ، فإن Crashlytics يعتبر أن المشكلة تراجعت وستقوم بإعادة فتح المشكلة.
يمكن أن يحدث هذا الموقف في الموقف التالي: لقد قمت بإصلاح خطأ وأصدرت إصدارًا جديدًا من تطبيقك ، ولكن لا يزال لديك مستخدمون في الإصدارات القديمة دون إصلاح الأخطاء. إذا لم ترسل أحد هذه الإصدارات القديمة ، عن طريق الصدفة ، أي تقارير تحطم على الإطلاق عند إغلاق المشكلة ، ويبدأ هؤلاء المستخدمون في مواجهة الخلل ، فإن تقارير التعطل هذه ستؤدي إلى مشكلة تراجعت.
إذا كنت لا تريد إعادة فتح مشكلة بسبب خوارزمية الانحدار لدينا ، "كتم" المشكلة بدلاً من إغلاقها.
،توفر هذه الصفحة مساعدة استكشاف الأخطاء وإصلاحها وإجابات على الأسئلة التي يتم التنقل فيها بشكل متكرر حول استخدام CrashlyTics. إذا لم تتمكن من العثور على ما تبحث عنه أو تحتاج إلى مساعدة إضافية ، فاتصل بدعم Firebase .
استكشاف الأخطاء وإصلاحها العامة/الأسئلة الشائعة
إذا كنت لا ترى مستخدمين خالين من الانهيار وسجلات الخبز و/أو تنبيهات السرعة ، فإننا نوصي بالتحقق من تكوين التطبيق الخاص بك لتحليلات Google.
تأكد من تمكين Google Analytics في مشروع Firebase الخاص بك.
تأكد من تمكين مشاركة البيانات لـ Google Analytics في صفحة التكامل > Google Analytics من وحدة التحكم في Firebase. لاحظ أن إعدادات مشاركة البيانات يتم عرضها في وحدة التحكم في Firebase ولكن يتم إدارتها في وحدة التحكم في Google Analytics.
بالإضافة إلى Firebase Crashlytics SDK ، تأكد من إضافة Firebase SDK لـ Google Analytics إلى تطبيقك ( iOS+ | Android ).
تأكد من أنك تستخدم أحدث الإصدارات لجميع Firebase SDKs ( iOS+ | Android ).
تحقق بشكل خاص من أنك تستخدم على الأقل الإصدارات التالية من Firebase SDK لتحليلات Google:iOS+ - v6.3.1+ (v8.9.0+ لـ macos و tvos) | Android - v17.2.3+ (BOM V24.7.1+) .
قد تلاحظ تنسيقين مختلفين للمشكلات المدرجة في جدول المشكلات في وحدة التحكم في Firebase. وقد تلاحظ أيضًا ميزة تسمى "المتغيرات" ضمن بعض مشكلاتك. هذا هو السبب!
في أوائل عام 2023 ، قدمنا محرك تحليل محسّن لتجميع الأحداث بالإضافة إلى تصميم محدث وبعض الميزات المتقدمة للمشكلات الجديدة (مثل المتغيرات!). تحقق من منشور المدونة الأخير للحصول على جميع التفاصيل ، ولكن يمكنك القراءة أدناه للحصول على أبرز.
يحلل Crashlytics جميع الأحداث من تطبيقك (مثل الحوادث ، غير المميتة ، و ANRS) وإنشاء مجموعات من الأحداث التي تسمى القضايا -جميع الأحداث في القضية لها نقطة فشل مشتركة.
لتجميع الأحداث في هذه المشكلات ، يبحث محرك التحليل المحسن الآن في العديد من جوانب الحدث ، بما في ذلك الإطارات في تتبع المكدس ، ورسالة الاستثناء ، ورمز الخطأ ، وخصائص النظام الأساسي أو نوع الخطأ الآخر.
ومع ذلك ، ضمن هذه المجموعة من الأحداث ، قد تكون آثار المكدس تؤدي إلى الفشل مختلفة. يمكن أن يعني تتبع مكدس مختلف سببًا جذريًا مختلفًا. لتمثيل هذا الاختلاف المحتمل في مشكلة ما ، نقوم الآن بإنشاء متغيرات ضمن القضايا - كل متغير هو مجموعة فرعية من الأحداث في مشكلة لها نفس نقطة الفشل وتتبع مكدس مماثل. مع المتغيرات ، يمكنك تصحيح آثار المكدس الأكثر شيوعًا ضمن مشكلة ما وتحديد ما إذا كانت الأسباب الجذرية المختلفة تؤدي إلى الفشل.
إليك ما ستختبره مع هذه التحسينات:
البيانات الوصفية التي تم تجديدها معروضة ضمن صف العدد
أصبح من الأسهل الآن فهم مشكلات الفهم والفرز في تطبيقك.عدد أقل من القضايا المكررة
تغيير رقم الخط لا يؤدي إلى مشكلة جديدة.أسهل تصحيح القضايا المعقدة مع الأسباب الجذرية المختلفة
استخدم المتغيرات لتصحيح آثار المكدس الأكثر شيوعًا ضمن مشكلة ما.تنبيهات وإشارات أكثر جدوى
تمثل قضية جديدة في الواقع خطأ جديد.بحث أكثر قوة
تحتوي كل مشكلة على بيانات تعريف أكثر قابلية للبحث ، مثل نوع الاستثناء واسم الحزمة.
إليكم كيفية طرح هذه التحسينات:
عندما نحصل على أحداث جديدة من تطبيقك ، سنتحقق مما إذا كانت تتطابق مع مشكلة موجودة.
إذا لم يكن هناك تطابق ، فسوف نقوم تلقائيًا بتطبيق خوارزمية تجميع الأحداث الأكثر ذكاءً على الحدث وننشئ مشكلة جديدة مع تصميم البيانات الوصفية التي تم تجديدها.
هذا هو أول تحديث كبير نقوم به لتجميع الأحداث لدينا. إذا كان لديك ملاحظات أو واجهت أي مشكلات ، فيرجى إخبارنا بتقديم تقرير.
The crash-free value represents the percentage of users who engaged with your app but did not have a crash over a specific time period.
Here is the formula for calculating the crash-free users percentage. Its input values are provided by Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
When a crash happens, Google Analytics sends an
app_exceptionevent type, and CRASHED_USERS represents the number of users associated with that event type.ALL_USERS represents the total number of users who engaged with your app over the time period that you've selected from the drop-down menu in the upper-right of the Crashlytics dashboard.
The crash-free users percentage is an aggregation over time , not an average.
For example, imagine your app has three users; we'll call them User A, User B, and User C. The following table shows which users engaged with your app each day and which of those users had a crash that day:
| الاثنين | يوم الثلاثاء | الأربعاء | |
|---|---|---|---|
| Users who engaged with your app | أ، ب، ج | أ، ب، ج | أ، ب |
| User that had a crash | ج | ب | أ |
On Wednesday, your crash-free users percentage is 50% (1 out of 2 users was crash-free).
Two of your users engaged with your app on Wednesday, but only one of them (User B) had no crashes.For the past 2 days, your crash-free users percentage is 33.3% (1 out of 3 users was crash-free).
Three of your users engaged with your app over the past two days, but only one of them (User C) had no crashes.For the past 3 days, your crash-free users percentage is 0% (0 out of 3 users were crash-free).
Three of your users engaged with your app over the past three days, but zero of them had no crashes.
The crash-free users value shouldn't be compared over different time periods. The probability of a single user experiencing a crash grows the more times they use your app, so the crash-free users value is likely to be smaller for longer time periods.
Notes allow project members to comment on specific issues with questions, status updates, etc.
When a project member posts a note, it's labeled with the email of their Google account. This email address is visible, along with the note, to all project members with access to view the note.
The following describes the access required to view, write, and delete notes:
Project members with any of the following roles can view and delete existing notes and write new notes on an issue.
- Project Owner or Editor , Firebase Admin , Quality Admin , or Crashlytics Admin
Project members with any of the following roles can view the notes posted on an issue, but they cannot delete or write a note.
- Project Viewer , Firebase Viewer , Quality Viewer , or Crashlytics Viewer
التكامل
If your project uses Crashlytics alongside the Google Mobile Ads SDK, it's likely that the crash reporters are interfering when registering exception handlers. To fix the issue, turn off crash reporting in the Mobile Ads SDK by calling disableSDKCrashReporting .
After you link Crashlytics to BigQuery, new datasets you create are automatically located in the United States, regardless of the location of your Firebase project.
Platform support
Regressed issues
An issue has had a regression when you've previously closed the issue but Crashlytics gets a new report that the issue has re-occurred. Crashlytics automatically re-opens these regressed issues so that you can address them as appropriate for your app.
Here's an example scenario that explains how Crashlytics categorizes an issue as a regression:
- For the first time ever, Crashlytics gets a crash report about Crash "A". Crashlytics opens a corresponding issue for that crash (Issue "A").
- You fix this bug quickly, close Issue "A", and then release a new version of your app.
- Crashlytics gets another report about Issue "A" after you've closed the issue.
- If the report is from an app version that Crashlytics knew about when you closed the issue (meaning that the version had sent a crash report for any crash at all), then Crashlytics won't consider the issue as regressed. The issue will remain closed.
- If the report is from an app version that Crashlytics did not know about when you closed the issue (meaning that the version had never sent any crash report for any crash at all), then Crashlytics considers the issue regressed and will re-open the issue .
When an issue regresses, we send a regression detection alert and add a regression signal to the issue to let you know that Crashlytics has re-opened the issue. If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.
If a report is from an old app version that had never sent any crash reports at all when you closed the issue, then Crashlytics considers the issue regressed and will re-open the issue.
This situation can happen in the following situation: You've fixed a bug and released a new version of your app, but you still have users on older versions without the bug fix. If, by chance, one of those older versions had never sent any crash reports at all when you closed the issue, and those users start encountering the bug, then those crash reports would trigger a regressed issue.
If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.