توفر هذه الصفحة تعليمات حول استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول استخدام 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. إليكم السبب!
تحلل Crashlytics جميع الأحداث من تطبيقك - الأعطال ، والأحداث غير المميتة ، و ANR - وتجمع الأحداث المماثلة في مشكلات منفصلة. في كانون الثاني (يناير) 2023 ، أطلقنا محرك تحليل محسّنًا لتجميع الأحداث استنادًا إلى رمز التطبيق الخاص بك وتصميم محدث لعرض المشكلات الجديدة.
إليك ما ستختبره بهذه التحسينات:
عرض البيانات الوصفية المُجدَّدة في صف الإصدار
أصبح الآن من السهل فهم المشكلات وترتيبها في تطبيقك.عدد أقل من المشكلات المكررة
لا ينتج عن تغيير رقم السطر مشكلة جديدة.المزيد من التنبيهات والإشارات ذات مغزى
يمثل الإصدار الجديد خطأً جديدًا في الواقع.بحث أكثر قوة
تحتوي كل مشكلة على المزيد من البيانات الوصفية القابلة للبحث ، مثل نوع الاستثناء واسم الحزمة.
إليك كيفية طرح هذه التحسينات:
عندما نحصل على أحداث جديدة من تطبيقك ، سنتحقق مما إذا كانت تتطابق مع مشكلة حالية.
إذا لم يكن هناك تطابق ، فسنطبق تلقائيًا خوارزمية تجميع الأحداث الأكثر ذكاءً على الحدث وننشئ مشكلة جديدة مع تصميم البيانات الوصفية الذي تم تجديده.
هذا هو أول تحديث كبير نجريه لمجموعات الأحداث لدينا. إذا كانت لديك ملاحظات أو واجهت أي مشاكل ، فيرجى إخبارنا عن طريق تقديم تقرير.
يدعم Crashlytics إعداد تقارير ANR لتطبيقات Android من الأجهزة التي تعمل بنظام Android 11 والإصدارات الأحدث. تعد واجهة برمجة التطبيقات الأساسية التي نستخدمها لجمع أخطاء ANR ( getHistoricalProcessExitReasons ) أكثر موثوقية من SIGQUIT أو النهج القائمة على المراقبة. واجهة برمجة التطبيقات هذه متاحة فقط على أجهزة Android 11+.
قد يكون هناك عدم تطابق بين عدد أخطاء ANR بين Google Play و Crashlytics. هذا متوقع بسبب الاختلاف في آلية جمع بيانات ANR والإبلاغ عنها. تبلغ Crashlytics عن أخطاء ANR عند بدء تشغيل التطبيق في المرة التالية ، بينما يرسل Android Vitals بيانات ANR بعد حدوث ANR.
بالإضافة إلى ذلك ، لا تعرض Crashlytics سوى أخطاء ANR التي تحدث على الأجهزة التي تعمل بنظام Android 11+ ، مقارنة بـ Google Play الذي يعرض أخطاء ANR من الأجهزة المزودة بخدمات Google Play وتقبل الموافقة على جمع البيانات.
تحتوي سلاسل أدوات LLVM و GNU على إعدادات افتراضية ومعالجات مميزة لقطاع القراءة فقط من ثنائيات تطبيقك ، مما قد يؤدي إلى إنشاء تتبعات تكديس غير متسقة في وحدة تحكم Firebase. للتخفيف من ذلك ، أضف إشارات الرابط التالية إلى عملية الإنشاء الخاصة بك:
إذا كنت تستخدم الرابط
lldمن سلسلة أدوات LLVM ، أضف:-Wl,--no-rosegmentإذا كنت تستخدم رابط
ld.goldمن سلسلة أدوات GNU ، أضف:-Wl,--rosegment
إذا كنت لا تزال ترى تناقضات في تتبع المكدس (أو إذا لم تكن أي من العلامات ذات صلة بسلسلة الأدوات الخاصة بك) ، فحاول إضافة ما يلي إلى عملية الإنشاء بدلاً من ذلك:
-fno-omit-frame-pointer
يجمع المكوِّن الإضافي Crashlytics مولدًا مخصصًا لملف رموز Breakpad . إذا كنت تفضل استخدام الملف الثنائي الخاص بك لإنشاء ملفات رموز Breakpad (على سبيل المثال ، إذا كنت تفضل إنشاء جميع الملفات التنفيذية الأصلية في سلسلة الإنشاء الخاصة بك من المصدر) ، فاستخدم رمز الامتداد الاختياري symbolGeneratorBinary extension لتحديد المسار إلى الملف القابل للتنفيذ.
يمكنك تحديد المسار إلى ثنائي منشئ ملف رمز Breakpad الثنائي بإحدى طريقتين:
الخيار 1 : حدد المسار عبر امتداد
firebaseCrashlyticsفي ملفbuild.gradleأضف ما يلي إلى ملف
build.gradleعلى مستوى التطبيق:android { // ... buildTypes { // ... release { // ... firebaseCrashlytics { // existing; required for either symbol file generator nativeSymbolUploadEnabled true // Add this optional new block to specify the path to the executable symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }الخيار 2 : حدد المسار عبر سطر خاصية في ملف خصائص Gradle
يمكنك استخدام الخاصية
com.google.firebase.crashlytics.symbolGeneratorBinaryلتحديد المسار إلى الملف القابل للتنفيذ.يمكنك تحديث ملف خصائص Gradle يدويًا أو تحديث الملف عبر سطر الأوامر. على سبيل المثال ، لتحديد المسار عبر سطر الأوامر ، استخدم أمرًا مثل ما يلي:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
إذا رأيت الاستثناء التالي ، فمن المحتمل أنك تستخدم إصدارًا من DexGuard غير متوافق مع Firebase Crashlytics SDK:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
لا يؤدي هذا الاستثناء إلى تعطل تطبيقك ولكنه يمنعه من إرسال تقارير الأعطال. لإصلاح هذا:
تأكد من أنك تستخدم أحدث إصدار من DexGuard 8.x. يحتوي أحدث إصدار على القواعد المطلوبة بواسطة Firebase Crashlytics SDK.
إذا كنت لا ترغب في تغيير إصدار DexGuard الخاص بك ، فحاول إضافة السطر التالي إلى قواعد التشويش (في ملف تكوين DexGuard الخاص بك):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
عندما يستخدم أحد التطبيقات أداة تشويش لا تعرض امتداد الملف ، فإن Crashlytics تولد كل مشكلة بامتداد ملف .java افتراضيًا.
حتى تتمكن Crashlytics من إنشاء مشكلات تتعلق بامتداد الملف الصحيح ، تأكد من أن تطبيقك يستخدم الإعداد التالي:
- يستخدم Android Gradle 4.2.0 أو أعلى
- يستخدم R8 مع تشغيل التشويش. لتحديث تطبيقك إلى R8 ، اتبع هذه الوثائق .
لاحظ أنه بعد التحديث إلى الإعداد الموضح أعلاه ، قد تبدأ في رؤية مشكلات .kt الجديدة التي تعد نسخًا مكررة من مشكلات .java الحالية. راجع الأسئلة الشائعة لمعرفة المزيد عن هذا الظرف.
بدءًا من منتصف ديسمبر 2021 ، قامت Crashlytics بتحسين دعم التطبيقات التي تستخدم Kotlin.
حتى وقت قريب ، لم تعرض أدوات التعتيم المتاحة امتداد الملف ، لذلك قامت Crashlytics بإنشاء كل مشكلة بامتداد ملف .java افتراضيًا. ومع ذلك ، بدءًا من Android Gradle 4.2.0 ، يدعم R8 امتدادات الملفات.
مع هذا التحديث ، يمكن لـ Crashlytics الآن تحديد ما إذا كانت كل فئة مستخدمة داخل التطبيق مكتوبة بلغة Kotlin وتضمين اسم الملف الصحيح في توقيع المشكلة. تُنسب الأعطال الآن بشكل صحيح إلى ملفات .kt (حسب الاقتضاء) إذا كان تطبيقك يحتوي على الإعداد التالي:
- يستخدم تطبيقك Android Gradle 4.2.0 أو إصدار أحدث.
- يستخدم تطبيقك R8 مع تشغيل التشويش.
نظرًا لأن الأعطال الجديدة تتضمن الآن امتداد الملف الصحيح في توقيعات المشكلات الخاصة بها ، فقد ترى مشكلات .kt جديدة هي في الواقع مجرد نسخ مكررة من المشكلات الحالية ذات التصنيف .java . في وحدة تحكم Firebase ، نحاول التعرف عليك وإبلاغك إذا كانت مشكلة .kt الجديدة هي تكرار محتمل لمشكلة حالية تحمل علامة .java .
تمثل القيمة الخالية من الأعطال النسبة المئوية للمستخدمين الذين تفاعلوا مع تطبيقك ولكن لم يتعرضوا لأي عطل خلال فترة زمنية محددة.
هذه هي الصيغة لحساب نسبة المستخدمين الخالية من الأعطال. يتم توفير قيم الإدخال الخاصة به بواسطة 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.
دعم المنصة
لا يدعم Firebase Crashlytics NDK ARMv5 (armeabi). تمت إزالة دعم ABI هذا اعتبارًا من NDK r17.
القضايا المتراجعة
حدث تراجع في إحدى المشكلات عندما أغلقت المشكلة مسبقًا ولكن Crashlytics تحصل على تقرير جديد يفيد بأن المشكلة قد حدثت مرة أخرى. تعيد Crashlytics فتح هذه المشكلات المتراجعة تلقائيًا بحيث يمكنك معالجتها بما يتناسب مع تطبيقك.
فيما يلي مثال على سيناريو يشرح كيف تصنف Crashlytics مشكلة على أنها انحدار:
- لأول مرة على الإطلاق ، تحصل Crashlytics على تقرير عن حادث تحطم "أ". يفتح Crashlytics مشكلة مقابلة لذلك التعطل (المشكلة "أ").
- يمكنك إصلاح هذا الخطأ بسرعة ، وإغلاق المشكلة "أ" ، ثم إطلاق إصدار جديد من تطبيقك.
- يحصل موقع Crashlytics على تقرير آخر حول المشكلة "أ" بعد إغلاق المشكلة.
- إذا كان التقرير من إصدار تطبيق كان Crashlytics على علم به عندما أغلقت المشكلة (بمعنى أن الإصدار أرسل تقرير تعطل لأي عطل على الإطلاق) ، فلن تعتبر Crashlytics المشكلة على أنها تراجعت. ستبقى القضية مغلقة.
- إذا كان التقرير من إصدار تطبيق لم يكن Crashlytics على علم به عندما أغلقت المشكلة (مما يعني أن الإصدار لم يرسل أي تقرير تعطل مطلقًا عن أي عطل على الإطلاق) ، فإن Crashlytics تعتبر أن المشكلة تراجعت وستعيد فتح المشكلة .
عندما تتراجع إحدى المشكلات ، نرسل تنبيهًا لاكتشاف الانحدار ونضيف إشارة تراجع إلى المشكلة لإعلامك بأن Crashlytics أعادت فتح المشكلة. إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا ، فقم بكتم المشكلة بدلاً من إغلاقها.
إذا كان أحد التقارير من إصدار تطبيق قديم لم يرسل مطلقًا أي تقارير أعطال على الإطلاق عند إغلاق المشكلة ، فإن Crashlytics تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة.
يمكن أن يحدث هذا الموقف في الموقف التالي: لقد أصلحت خطأ وأصدرت إصدارًا جديدًا من تطبيقك ، ولكن لا يزال لديك مستخدمون على إصدارات أقدم بدون إصلاح الخطأ. إذا لم يرسل أحد هذه الإصدارات القديمة ، عن طريق الصدفة ، أي تقارير أعطال على الإطلاق عند إغلاق المشكلة ، وبدأ هؤلاء المستخدمون في مواجهة الخطأ ، فإن تقارير الأعطال هذه ستطلق مشكلة تراجع.
إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا ، فقم بكتم المشكلة بدلاً من إغلاقها.