توفر هذه الصفحة مساعدة في استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول استخدام 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) وإنشاء مجموعات من الأحداث تسمى المشكلات - جميع الأحداث في مشكلة ما لها نقطة فشل مشتركة.
لتجميع الأحداث في هذه المشكلات، يبحث محرك التحليل المحسّن الآن في العديد من جوانب الحدث، بما في ذلك الإطارات الموجودة في تتبع المكدس، ورسالة الاستثناء، ورمز الخطأ، وخصائص النظام الأساسي أو نوع الخطأ الأخرى.
ومع ذلك، ضمن هذه المجموعة من الأحداث، قد تكون تتبعات المكدس التي تؤدي إلى الفشل مختلفة. قد يعني تتبع المكدس المختلف سببًا جذريًا مختلفًا. لتمثيل هذا الاختلاف المحتمل داخل مشكلة ما، نقوم الآن بإنشاء متغيرات داخل المشكلات - كل متغير عبارة عن مجموعة فرعية من الأحداث في مشكلة لها نفس نقطة الفشل وتتبع مكدس مماثل. باستخدام المتغيرات، يمكنك تصحيح أخطاء تتبعات المكدس الأكثر شيوعًا داخل المشكلة وتحديد ما إذا كانت الأسباب الجذرية المختلفة هي التي تؤدي إلى الفشل.
إليك ما ستختبره مع هذه التحسينات:
يتم عرض البيانات التعريفية المجددة داخل صف المشكلة
أصبح من السهل الآن فهم المشكلات وفرزها في تطبيقك.عدد أقل من القضايا المكررة
لا يؤدي تغيير رقم السطر إلى مشكلة جديدة.تصحيح أسهل للمشكلات المعقدة ذات الأسباب الجذرية المختلفة
استخدم المتغيرات لتصحيح أخطاء تتبعات المكدس الأكثر شيوعًا داخل المشكلة.المزيد من التنبيهات والإشارات ذات مغزى
تمثل المشكلة الجديدة في الواقع خطأً جديدًا.بحث أكثر قوة
تحتوي كل مشكلة على المزيد من البيانات التعريفية القابلة للبحث، مثل نوع الاستثناء واسم الحزمة.
وإليك كيفية نشر هذه التحسينات:
عندما نحصل على أحداث جديدة من تطبيقك، سنتحقق مما إذا كانت تتطابق مع مشكلة موجودة أم لا.
إذا لم يكن هناك تطابق، فسنطبق تلقائيًا خوارزمية تجميع الأحداث الأكثر ذكاءً على الحدث وننشئ مشكلة جديدة من خلال تصميم البيانات التعريفية المتجدد.
هذا هو أول تحديث كبير نجريه على مجموعة الأحداث الخاصة بنا. إذا كانت لديك تعليقات أو واجهت أي مشكلات، فيرجى إبلاغنا بذلك عن طريق تقديم تقرير.
يدعم Crashlytics إعداد تقارير ANR لتطبيقات Android من الأجهزة التي تعمل بنظام Android 11 والإصدارات الأحدث. تعد واجهة برمجة التطبيقات الأساسية التي نستخدمها لجمع ANRs ( getHistoricalProcessExitReasons ) أكثر موثوقية من SIGQUIT أو الأساليب القائمة على المراقبة. واجهة برمجة التطبيقات هذه متاحة فقط على الأجهزة التي تعمل بنظام التشغيل Android 11+.
إذا كانت بعض أخطاء ANR الخاصة بك تفتقد معرفات BuildId الخاصة بها، فقم باستكشاف الأخطاء وإصلاحها على النحو التالي:
تأكد من أنك تستخدم إصدارًا محدثًا من البرنامج الإضافي Crashlytics Android SDK وCrashlytics Gradle.
إذا كنت تفتقد
BuildIdلنظام Android 11 وبعض أخطاء ANR لنظام Android 12، فمن المحتمل أنك تستخدم SDK قديمًا أو مكون Gradle الإضافي أو كليهما. لتجميعBuildIdلأخطاء ANR هذه بشكل صحيح، يلزمك استخدام الإصدارات التالية:- Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
- البرنامج المساعد Crashlytics Gradle v2.9.4+
تحقق مما إذا كنت تستخدم موقعًا غير قياسي لمكتباتك المشتركة.
إذا كنت تفتقد فقط
BuildIdللمكتبات المشتركة لتطبيقك، فمن المحتمل أنك لا تستخدم الموقع الافتراضي القياسي للمكتبات المشتركة. إذا كان الأمر كذلك، فقد لا يتمكن Crashlytics من تحديدBuildIdالمرتبط. نوصي بأن تفكر في استخدام الموقع القياسي للمكتبات المشتركة.تأكد من عدم إزالة
BuildIdأثناء عملية الإنشاء.لاحظ أن نصائح استكشاف الأخطاء وإصلاحها التالية تنطبق على كل من أخطاء ANR والأعطال الأصلية.
تحقق من وجود
BuildIdعن طريق تشغيلreadelf -nعلى الثنائيات الخاصة بك. إذا كانتBuildIdغائبة، فقم بإضافة-Wl,--build-idإلى العلامات الخاصة بنظام البناء الخاص بك.تأكد من أنك لا تقوم عن غير قصد بتجريد
BuildIdفي محاولة لتقليل حجم ملف APK الخاص بك.إذا احتفظت بإصدارات مجردة وغير مجردة من المكتبة، فتأكد من الإشارة إلى الإصدار الصحيح في التعليمات البرمجية الخاصة بك.
من الممكن أن يكون هناك عدم تطابق بين عدد أخطاء 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 الاختيارية لتحديد المسار إلى الملف القابل للتنفيذ.
يمكنك تحديد المسار إلى الملف الثنائي لمولد رمز 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% (كان مستخدم واحد من أصل مستخدمين خاليًا من الأعطال).
تفاعل اثنان من المستخدمين مع تطبيقك يوم الأربعاء، ولكن واحدًا منهم فقط (المستخدم ب) لم يتعرض لأي أعطال.خلال اليومين الماضيين، بلغت نسبة المستخدمين الذين لم يتعرضوا لأي أعطال 33.3% (كان 1 من أصل 3 مستخدمين خاليًا من الأعطال).
تفاعل ثلاثة من المستخدمين مع تطبيقك خلال اليومين الماضيين، ولكن واحدًا منهم فقط (المستخدم ج) لم يتعرض لأي أعطال.خلال الأيام الثلاثة الماضية، كانت نسبة المستخدمين الذين لم يتعرضوا لأي أعطال هي 0% (0 من أصل 3 مستخدمين لم يتعرضوا لأي أعطال).
تفاعل ثلاثة من المستخدمين مع تطبيقك خلال الأيام الثلاثة الماضية، ولكن لم يتعرض أي منهم لأي أعطال.
لا ينبغي مقارنة قيمة المستخدمين الخاليين من الأعطال خلال فترات زمنية مختلفة. يزداد احتمال تعرض مستخدم واحد لعطل كلما زاد عدد المرات التي يستخدم فيها تطبيقك، لذلك من المرجح أن تكون قيمة المستخدمين الخاليين من الأعطال أصغر لفترات زمنية أطول.
تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات محددة من خلال الأسئلة وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها بالبريد الإلكتروني لحساب Google الخاص به. عنوان البريد الإلكتروني هذا مرئي مع الملاحظة لجميع أعضاء المشروع الذين لديهم حق الوصول لعرض الملاحظة.
فيما يلي وصف للوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات الموجودة وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
- مالك المشروع أو المحرر ، أو مسؤول Firebase ، أو مسؤول الجودة ، أو مسؤول Crashlytics
يمكن لأعضاء المشروع الذين يتمتعون بأي من الأدوار التالية عرض الملاحظات المنشورة حول مشكلة ما، لكن لا يمكنهم حذف ملاحظة أو كتابتها.
- عارض المشروع، عارض Firebase ، عارض الجودة ، أو عارض Crashlytics
التكامل
إذا كان مشروعك يستخدم Crashlytics جنبًا إلى جنب مع Google Mobile Ads SDK، فمن المحتمل أن يتدخل مراسلو الأعطال عند تسجيل معالجات الاستثناءات. لإصلاح المشكلة، قم بإيقاف تشغيل تقارير الأعطال في SDK لإعلانات الجوال عن طريق الاتصال disableSDKCrashReporting .
بعد ربط Crashlytics بـ BigQuery، يتم تحديد موقع مجموعات البيانات الجديدة التي تقوم بإنشائها تلقائيًا في الولايات المتحدة، بغض النظر عن موقع مشروع Firebase الخاص بك.
دعم المنصة
لا يدعم Firebase Crashlytics NDK ARMv5 (armeabi). تمت إزالة دعم ABI هذا اعتبارًا من NDK r17.
القضايا المتخلفة
حدث تراجع في المشكلة عندما قمت بإغلاق المشكلة مسبقًا، لكن Crashlytics تحصل على تقرير جديد يفيد بتكرار حدوث المشكلة. يقوم Crashlytics بإعادة فتح هذه المشكلات المتراجعة تلقائيًا حتى تتمكن من معالجتها بالشكل المناسب لتطبيقك.
فيما يلي مثال لسيناريو يشرح كيفية قيام Crashlytics بتصنيف المشكلة على أنها انحدار:
- لأول مرة على الإطلاق، تحصل Crashlytics على تقرير عطل حول Crash "A". يفتح Crashlytics مشكلة مقابلة لهذا العطل (الإصدار "أ").
- يمكنك إصلاح هذا الخطأ بسرعة، وإغلاق المشكلة "أ"، ثم إصدار إصدار جديد من تطبيقك.
- تحصل Crashlytics على تقرير آخر حول المشكلة "أ" بعد إغلاق المشكلة.
- إذا كان التقرير من إصدار تطبيق عرفته Crashlytics عندما أغلقت المشكلة (بمعنى أن الإصدار قد أرسل تقرير تعطل عن أي عطل على الإطلاق)، فلن تعتبر Crashlytics أن المشكلة تراجعت. ستبقى القضية مغلقة.
- إذا كان التقرير من إصدار تطبيق لم تكن Crashlytics على علم به عندما أغلقت المشكلة (بمعنى أن الإصدار لم يرسل أبدًا أي تقرير تعطل عن أي عطل على الإطلاق)، فإن Crashlytics تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة .
عندما تتراجع مشكلة ما، نرسل تنبيهًا للكشف عن الانحدار ونضيف إشارة تراجع إلى المشكلة لإعلامك بأن Crashlytics أعادت فتح المشكلة. إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا، فقم "بتجاهل" المشكلة بدلاً من إغلاقها.
إذا كان التقرير من إصدار تطبيق قديم لم يرسل مطلقًا أي تقارير أعطال على الإطلاق عندما أغلقت المشكلة، فإن Crashlytics تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة.
يمكن أن يحدث هذا الموقف في الموقف التالي: لقد قمت بإصلاح الخلل وإصدار إصدار جديد من تطبيقك، ولكن لا يزال لديك مستخدمين على الإصدارات الأقدم دون إصلاح الخلل. إذا، عن طريق الصدفة، لم يرسل أحد هذه الإصدارات الأقدم أي تقارير أعطال على الإطلاق عندما أغلقت المشكلة، وبدأ هؤلاء المستخدمون في مواجهة الخطأ، فإن تقارير الأعطال هذه ستؤدي إلى حدوث مشكلة تراجعية.
إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا، فقم "بتجاهل" المشكلة بدلاً من إغلاقها.