تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
توفر هذه الصفحة مساعدة لاستكشاف الأخطاء وإصلاحها وإجابات على الأسئلة الشائعة حول استخدام Crashlytics. إذا لم تتمكّن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية، يُرجى التواصل مع فريق دعم Firebase.
الإجراءات العامّة لتحديد المشاكل وحلّها/الأسئلة الشائعة
الاطّلاع على تنسيقات مختلفة
(وأحيانًا "صيغ" لبعض المشاكل في جدول المشاكل)
قد تلاحظ تنسيقين مختلفين للمشكلات مدرجتين في جدول المشاكل ضمن وحدة تحكُّم Firebase. وقد تلاحظ أيضًا ميزة تسمى "المتغيرات"
ضمن بعض مشكلاتك. إليك السبب.
في أوائل العام 2023، طرحنا محرّك تحليل محسّن لتجميع الأحداث، بالإضافة إلى تصميم محدَّث وبعض الميزات المتقدّمة لحلّ المشاكل الجديدة (مثل الخيارات المختلفة). يمكنك مراجعة مشاركة المدونة الحديثة لمعرفة جميع التفاصيل، ولكن يمكنك قراءة النقاط الأساسية أدناه.
ويحلّل تطبيق Crashlytics جميع الأحداث في تطبيقك (مثل الأعطال والأخطاء غير الفادحة وأخطاء ANR) وينشئ مجموعات من الأحداث باسم المشاكل، حيث تتضمّن جميع الأحداث في العدد نقطة مشتركة من الفشل.
ولتجميع الأحداث حسب هذه المشاكل، يفحص محرك التحليل المحسّن الآن العديد من جوانب الفعالية، بما في ذلك الإطارات في تقرير تتبُّع تسلسل استدعاء الدوال البرمجية، ورسالة الاستثناء، ورمز الخطأ، وخصائص النظام الأساسي أو نوع الخطأ الأخرى.
ومع ذلك، داخل هذه المجموعة من الأحداث، قد تختلف عمليات تتبُّع تسلسل استدعاء الدوال البرمجية التي تؤدي إلى الفشل. وقد يؤدي اختلاف عملية تتبُّع تسلسل استدعاء الدوال البرمجية إلى سبب أساسي مختلف.
لتمثيل هذا الاختلاف المحتمل ضمن مشكلة، ننشئ الآن صيغًا مختلفة ضمن المشاكل، فكل صيغة هي مجموعة فرعية من الأحداث ضمن مشكلة لها نقطة العطل نفسها وتتبُّع تسلسل استدعاء الدوال البرمجية مشابهًا. باستخدام الصيغ، يمكنك تصحيح الأخطاء في عمليات تتبُّع تسلسُل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن المشكلة وتحديد ما إذا كانت الأسباب الجذرية المختلفة تؤدي إلى الإخفاق.
في ما يلي تجربتك هذه التحسينات:
البيانات الوصفية المجدَّدة المعروضة ضمن صف المشاكل أصبح من السهل فهم المشاكل وتصنيفها في تطبيقك.
عدد أقل من المشاكل المكرّرة لا يؤدي تغيير رقم السطر إلى حدوث مشكلة جديدة.
تصحيح الأخطاء بسهولة أكبر عند معالجة المشاكل المعقّدة ذات الأسباب الجذرية المختلفة يمكنك استخدام الصيغ لتصحيح أخطاء عمليات تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن المشكلة.
تنبيهات وإشارات أكثر فائدة تشير المشكلة الجديدة إلى خطأ جديد.
بحث أكثر فعالية تحتوي كل مشكلة على بيانات وصفية أكثر قابلية للبحث،
مثل نوع الاستثناء واسم الحزمة.
في ما يلي طريقة طرح هذه التحسينات:
عندما نحصل على أحداث جديدة من تطبيقك، سنتحقق مما إذا كانت تطابق مشكلة حالية أم لا.
وفي حال عدم العثور على نتيجة مطابِقة، سنطبّق تلقائيًا خوارزمية التجميع الأذكى
لتجميع الأحداث على الحدث وننشئ مشكلة جديدة في تصميم البيانات الوصفية
المحسّن.
هذا هو أول تحديث مهم نجريه على تجميع الفعاليات. إذا كانت لديك أي ملاحظات أو واجهت أي مشاكل، يُرجى إعلامنا بها من خلال
تقديم بلاغ
.
عدم ظهور مقاييس خالية من الأعطال و/أو تنبيهات السرعة
إذا لم تظهر لك مقاييس خالية من الأعطال (مثل المستخدمين والجلسات الخالية من الأعطال)
و/أو تنبيهات السرعة،
تأكَّد من استخدام
الإصدار 18.6.0 من حزمة تطوير البرامج Crashlytics أو الإصدارات الأحدث (أو المكوّن الإضافي Firebase BoM v32.6.0+ Fashlytics .
عدم ظهور سجلّات شريط التنقّل
إذا لم تظهر لك سجلّات شريط التنقّل، ننصحك بالتحقّق من إعدادات تطبيقك في "إحصاءات Google".
احرص على استيفاء المتطلبات التالية:
ويجب التأكّد على وجه التحديد من استخدامك على الأقل للإصدار التالي من
حزمة تطوير البرامج (SDK) لمنصة Firebase في "إحصاءات Google": Android: الإصدار 17.2.3 أو الإصدارات الأحدث(الإصدار 24.7.1 من BoM أو الإصدارات الأحدث).
لماذا لا يتم الإبلاغ عن أخطاء ANR إلا
في الإصدار 11 والإصدارات الأحدث من نظام التشغيل Android؟
يدعم تطبيق Crashlytics إعداد تقارير عن أخطاء ANR لتطبيقات Android على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android والإصدارات الأحدث. إنّ واجهة برمجة التطبيقات الأساسية التي نستخدمها لجمع أخطاء ANR
(getHistoryProcessExceptions)
أكثر موثوقية من الأساليب المستندة إلى SIGQUIT أو مراقب النظام. لا تتوفّر واجهة برمجة التطبيقات هذه إلا على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android والإصدارات الأحدث.
لماذا لا تتوفّر أخطاء BuildId في بعض أخطاء ANR؟
في حال عدم توفّر أخطاء BuildId في بعض أخطاء ANR، يمكنك تحديد المشاكل وحلّها كما يلي:
تأكَّد من استخدام أحدث إصدار من حزمة تطوير البرامج (SDK) لنظام التشغيل Android من Crashlytics
وإصدار من المكوّن الإضافي Crashlytics Gradle.
إذا لم تستخدم رموز BuildId لنظام التشغيل Android 11 وبعض أخطاء ANR في الإصدار 12، من المرجَّح أنّك تستخدم حزمة تطوير برامج (SDK) قديمة أو مكوّن إضافي قديم من Gradle أو كليهما.
لجمع أخطاء BuildId بشكل صحيح لأخطاء ANR هذه، عليك استخدام الإصدارات التالية:
الإصدار 18.3.5 من حزمة تطوير البرامج (SDK) لنظام التشغيل Android من Crashlytics (الإصدار 31.2.2 أو الأحدث من Firebase BoM)
الإصدار 2.9.4 من المكوّن الإضافي Crashlytics Gradle أو الإصدارات الأحدث
تحقّق مما إذا كنت تستخدم موقعًا جغرافيًا غير عادي لمكتباتك المشتركة.
إذا كنت تفتقد BuildId فقط للمكتبات المشتركة في تطبيقك، من المحتمل أنّك لا تستخدم الموقع الجغرافي التلقائي والعادي للمكتبات المشتركة. في هذه الحالة، قد لا يتمكن تطبيق Crashlytics من تحديد مكان BuildId المرتبطة. ننصحك بالتفكير في استخدام الموقع
القياسي للمكتبات المشتركة.
تأكَّد من عدم إزالة BuildId أثناء عملية التصميم.
يُرجى العلم أنّ النصائح التالية لتحديد المشاكل وحلّها تنطبق على أخطاء ANR والأعطال الأصلية.
تحقق من وجود BuildId من خلال تشغيل readelf -n على برامجك الثنائية. إذا لم تتوفّر عناصر BuildId، أضِف -Wl,--build-id إلى العلامات الخاصة بنظام الإصدار.
تأكد من عدم إزالة BuildId عن غير قصد في محاولة
لتقليل حجم APK.
إذا احتفظت بإصدارات مكتبة مختصرة وغير تجريدة، فتأكد من
الإشارة إلى الإصدار الصحيح في التعليمات البرمجية.
الاختلافات بين تقارير أخطاء ANR في لوحة بيانات Crashlytics وGoogle Play Console
قد يكون هناك عدم تطابق بين عدد أخطاء ANR بين Google Play وCrashlytics. وهذا أمر متوقَّع بسبب الاختلاف في آلية جمع بيانات ANR والإبلاغ عنها. يُبلِغ Crashlytics عن أخطاء ANR عند بدء تشغيل التطبيق في المرة التالية، بينما ترسل مؤشرات Android الحيوية بيانات ANR بعد حدوث خطأ ANR.
بالإضافة إلى ذلك، لا يعرض تطبيق Crashlytics أخطاء ANR التي تحدث إلا على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android أو الإصدارات الأحدث، مقارنةً بتطبيق Google Play الذي يعرض أخطاء ANR من الأجهزة التي تم قبول الموافقة على جمع البيانات وخدمات Google Play منها.
الاختلافات
بين عمليات تتبُّع تسلسُل استدعاء الدوال البرمجية NDK في لوحة بيانات Crashlytics وأداة Logcat
لدى سلسلتَي أدوات LLVM وGNU إعدادات تلقائية ومعالجات مختلفة للقسم المخصّص للقراءة فقط في البرامج الثنائية لتطبيقك، ما قد يؤدي إلى إنشاء عمليات تتبُّع تسلسل استدعاء الدوال البرمجية غير متّسقة في وحدة تحكُّم Firebase. للحدّ من هذه المشاكل، أضِف علامات الربط التالية
إلى عملية التصميم:
إذا كنت تستخدم رابط lld من سلسلة أدوات LLVM، أضِف ما يلي:
-Wl,--no-rosegment
إذا كنت تستخدم رابط ld.gold من سلسلة أدوات GNU، أضِف ما يلي:
-Wl,--rosegment
في حال استمرار ظهور تباينات في تتبُّع تسلسل استدعاء الدوال البرمجية (أو إذا لم تكن أي علامة مرتبطة بسلسلة الأدوات)، جرِّب إضافة ما يلي إلى عملية التصميم بدلاً من ذلك:
-fno-omit-frame-pointer
كيف يمكنني استخدام
البرنامج الثنائي لإنشاء ملف رموز Breakpad الخاص بي؟
يضم المكوّن الإضافي Crashlytics أداة مخصّصة لإنشاء ملفات رموز Breakpad.
إذا كنت تفضّل استخدام البرنامج الثنائي الخاص بك لإنشاء ملفات رموز لوحة الإيقاف (على سبيل المثال، إذا كنت تفضّل إنشاء جميع الملفات التنفيذية الأصلية في سلسلة الإصدار من المصدر)، استخدِم سمة الإضافة symbolGeneratorBinary الاختيارية لتحديد مسار الملف التنفيذي.
يمكنك تحديد المسار إلى البرنامج الثنائي لمنشئ ملف رمز Breakpad بإحدى الطريقتين التاليتين:
الخيار 1: حدد المسار من خلال الإضافة firebaseCrashlytics
في ملف build.gradle
أضِف ما يلي إلى ملف build.gradle.kts على مستوى التطبيق:
الإصدار 3.0.0 من المكوّن الإضافي Gradle أو الإصدارات الأحدث
android {
buildTypes {
release {
configure<CrashlyticsExtension> {
nativeSymbolUploadEnabled = true
// Add these optional fields to specify the path to the executable
symbolGeneratorType = "breakpad"
breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
الإصدارات الأقدم للمكوّنات الإضافية
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.breakpadBinary
لتحديد مسار الملف التنفيذي.
يمكنك تحديث ملف خصائص Gradle يدويًا أو تحديث الملف
عبر سطر الأوامر. على سبيل المثال، لتحديد المسار من خلال سطر الأوامر،
استخدِم أمرًا مثل ما يلي:
لماذا تظهر لي أعطال في ملفات .kt مصنَّفة على أنّها مشاكل .java؟
عندما يستخدم تطبيق أداة تشويش لا تعرض امتداد الملف، ينشئ تطبيق Crashlytics كل مشكلة بامتداد ملف .java تلقائيًا.
حتى يتمكّن تطبيق Crashlytics من حدوث مشاكل بشأن امتداد الملف الصحيح، يُرجى التأكُّد من أن تطبيقك يستخدم الإعداد التالي:
يتم استخدام الإصدار 4.2.0 من نظام Gradle المتوافق مع Android أو الإصدارات الأحدث.
يتم استخدام R8 مع تفعيل إخفاء مفاتيح فك التشفير. لتحديث التطبيق إلى الإصدار R8، يُرجى اتّباع هذه
الوثائق.
يُرجى العِلم أنّه بعد الانتقال إلى الإعداد الموضّح أعلاه، قد تبدأ في ظهور مشاكل .kt جديدة مكرّرة لمشاكل .java الحالية. يُرجى الاطّلاع على
الأسئلة الشائعة لمعرفة المزيد حول هذه الحالة.
لماذا أرى
.kt مشكلة، مثل تكرار مشاكل
.java الحالية؟
اعتبارًا من منتصف شهر ديسمبر 2021، حسّنت Crashlytics دعم التطبيقات التي تستخدم Kotlin.
حتى وقت قريب، لم تعرض أدوات التشويش المتاحة امتداد الملف، لذلك
أنشأ تطبيق Crashlytics تلقائيًا كل مشكلة بامتداد ملف .java.
ومع ذلك، اعتبارًا من الإصدار 4.2.0 من نظام Gradle المتوافق مع Android، أصبحت R8 متوافقة مع امتدادات الملفات.
من خلال هذا التحديث، يمكن لتطبيق Crashlytics الآن تحديد ما إذا كان كل فئة يتم استخدامها داخل التطبيق مكتوبًا بلغة Kotlin وتضمين اسم الملف الصحيح في توقيع المشكلة. تُنسب الأعطال الآن بشكل صحيح إلى ملفات .kt (حسب الحاجة)
إذا كان تطبيقك مضبوطًا على الإعداد التالي:
يستخدم تطبيقك الإصدار 4.2.0 من نظام التشغيل Android Gradle أو الإصدارات الأحدث.
يستخدم تطبيقك الإصدار R8 مع تفعيل ميزة إخفاء مفاتيح فك التشفير.
وبما أنّ الأعطال الجديدة تتضمّن الآن امتداد الملف الصحيح في توقيعات المشاكل، قد تلاحظ مشاكل .kt جديدة ليست في الواقع سوى نُسخًا طبق الأصل من مشاكل حالية تحمل تصنيف .java. في "وحدة تحكُّم Firebase"، نحاول رصد المشكلة الجديدة في .kt وإبلاغك بها إذا كانت هذه المشكلة نسخة متكررة لمشكلة حالية تحمل التصنيف .java.
من يمكنه عرض الملاحظات وكتابتها وحذفها حول مشكلة ما؟
تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات معينة من خلال الأسئلة
وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها بالبريد الإلكتروني لحساب
Google. عنوان البريد الإلكتروني هذا مرئي، إلى جانب الملاحظة، لجميع أعضاء المشروع الذين لديهم إمكانية الوصول لعرض الملاحظة.
في ما يلي وصف للوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات
الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
من يمكنه عرض الملاحظات وكتابتها وحذفها حول مشكلة ما؟
تسمح الملاحظات لأعضاء المشروع بالتعليق على مشكلات معينة من خلال الأسئلة
وتحديثات الحالة وما إلى ذلك.
عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها بالبريد الإلكتروني لحساب
Google. عنوان البريد الإلكتروني هذا مرئي، إلى جانب الملاحظة، لجميع أعضاء المشروع الذين لديهم إمكانية الوصول لعرض الملاحظة.
في ما يلي وصف للوصول المطلوب لعرض الملاحظات وكتابتها وحذفها:
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات
الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة ما.
يستخدم التطبيق أيضًا
حزمة "SDK لإعلانات Google على الأجهزة الجوّالة" ولكنه لا يتلقّى أعطالاً
إذا كان مشروعك يستخدم Crashlytics إلى جانب حزمة SDK لإعلانات Google على الأجهزة الجوّالة، فمن المحتمل أن يتدخل أصحاب تقارير الأعطال عند تسجيل معالِجات الاستثناء. لحل المشكلة، عليك إيقاف ميزة إعداد تقارير الأعطال في
"SDK لإعلانات الأجهزة الجوّالة" من خلال الاتصال بالرقم disableSDKCrashReporting.
أين توجد مجموعة بيانات BigQuery؟
بعد ربط Crashlytics بأداة BigQuery، يتم تلقائيًا تحديد موقع مجموعات البيانات الجديدة التي تنشئها في الولايات المتحدة، بغض النظر عن موقع مشروعك على Firebase.
دعم المنصة
هل يتيح تطبيق Crashlytics استخدام armeabi؟
لا يتوافق Firebase Crashlytics NDK مع ARMv5 (الذي يُشار إليه اختصارًا باسم Armeabi).
تمّت إزالة إمكانية استخدام واجهة التطبيق الثنائية (ABI) هذه اعتبارًا من الإصدار NDK r17.
المشاكل التي تم التراجع عنها
ما هي المشكلة التي تؤدي إلى تراجع أداء المحتوى؟
تراجعت المشكلة عندما أغلقت المشكلة في السابق، ولكن
تلقّى Crashlytics تقريرًا جديدًا يفيد بحدوث هذه المشكلة مرة أخرى.
ويعيد تطبيق Crashlytics تلقائيًا فتح هذه المشاكل التي تراجعت، حتى تتمكن من حلّها بالشكل المناسب لتطبيقك.
إليك مثال سيناريو يشرح كيفية تصنيف تطبيق Crashlytics لمشكلة على أنها انحدار:
تتلقّى Crashlytics لأول مرة تقرير أعطال عن الأعطال "A". يفتح Crashlytics مشكلة ذات صلة بهذا العطل (المشكلة "أ").
أنصحك بإصلاح هذا الخطأ بسرعة، وإغلاق المشكلة "أ"، ثم طرح إصدار جديد من تطبيقك.
يحصل Crashlytics على تقرير آخر عن المشكلة "أ" بعد إغلاق
المشكلة.
إذا كان التقرير من إصدار تطبيق عرفه تطبيق Crashlytics عند إغلاق المشكلة (أي أنّ الإصدار قد أرسل تقرير أعطال لأي عُطل على الإطلاق)، لن يعتبر Crashlytics المشكلة على أنّها تراجعت. ستظل المشكلة مغلقة.
إذا كان التقرير صادرًا من إصدار تطبيق لم يعلمه تطبيق Crashlytics عندما تم إغلاق المشكلة (أي أنّ الإصدار لم يرسل أيًا تقرير أعطال على الإطلاق) عندها، يعتبر Crashlytics أنّ المشكلة قد تراجعت، وسيعيد فتحها.
عندما تتراجع إحدى المشاكل، نرسل تنبيه بشأن رصد التراجع ونضيف إشارة انحدار إلى المشكلة لإعلامك بأنّ Crashlytics أعاد فتح المشكلة. إذا كنت لا تريد إعادة فتح المشكلة بسبب
خوارزمية الانحدار، يمكنك "كتم" المشكلة بدلاً من إغلاقها.
لماذا أرى مشاكل تراجعت
في الإصدارات القديمة من التطبيق؟
إذا كان التقرير من إصدار تطبيق قديم لم يسبق أن أرسل أي تقارير أعطال على الإطلاق عند غلق المشكلة، سيعتبر تطبيق Crashlytics أن المشكلة قد تراجعت ثم سيعيد فتح المشكلة.
يمكن أن يحدث هذا الموقف في الحالة التالية: عندما أصلحت خطأً وطرحت إصدارًا جديدًا من التطبيق، ولكن لا يزال لديك مستخدمون على إصدارات قديمة بدون إصلاح الخطأ. إذا كان أحد هذه الإصدارات القديمة قد لم يرسل أي تقارير أعطال على الإطلاق عند إغلاق المشكلة، وبدأ هؤلاء المستخدمون في مواجهة الخطأ، ستؤدي تقارير الأعطال هذه إلى ظهور مشكلة تراجعت الصفحة.
إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار، يمكنك "تجاهل" المشكلة بدلاً من إغلاقها.