Crashlytics استكشاف الأخطاء وإصلاحها والأسئلة الشائعة

عدم رؤية المستخدمين الذين يعانون من الأعطال و / أو سجلات مسارات التنقل و / أو تنبيهات السرعة

إذا كنت لا ترى مستخدمين خالين من الأعطال و / أو سجلات مسارات التنقل و / أو تنبيهات السرعة ، فإننا نوصي بالتحقق من تكوين تطبيقك لـ 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. وقد تلاحظ أيضًا ميزة تسمى "المتغيرات" في بعض مشكلاتك. إليكم السبب!

في أوائل عام 2023 ، طرحنا محرك تحليل محسّنًا لتجميع الأحداث بالإضافة إلى تصميم محدث وبعض الميزات المتقدمة للمشكلات الجديدة (مثل المتغيرات!). تحقق من منشور المدونة الأخير الخاص بنا للحصول على جميع التفاصيل ، ولكن يمكنك القراءة أدناه للحصول على النقاط البارزة.

تحلل Crashlytics جميع الأحداث من تطبيقك (مثل الأعطال ، والأحداث غير المميتة ، و ANRs) وتنشئ مجموعات من الأحداث تسمى المشكلات - كل الأحداث في مشكلة لها نقطة فشل مشتركة.

لتجميع الأحداث في هذه المشكلات ، يبحث محرك التحليل المحسّن الآن في العديد من جوانب الحدث ، بما في ذلك الإطارات في تتبع المكدس ورسالة الاستثناء ورمز الخطأ وخصائص نوع الخطأ والنظام الأساسي الأخرى.

ومع ذلك ، ضمن هذه المجموعة من الأحداث ، قد تكون آثار المكدس التي تؤدي إلى الفشل مختلفة. قد يعني تتبع المكدس المختلف سببًا جذريًا مختلفًا. لتمثيل هذا الاختلاف المحتمل في إحدى المشكلات ، نقوم الآن بإنشاء متغيرات داخل المشكلات - كل متغير عبارة عن مجموعة فرعية من الأحداث في مشكلة لها نفس نقطة الفشل وتتبع مكدس مماثل. باستخدام المتغيرات ، يمكنك تصحيح أخطاء تتبعات المكدس الأكثر شيوعًا داخل المشكلة وتحديد ما إذا كانت الأسباب الجذرية المختلفة تؤدي إلى الفشل.

إليك ما ستختبره بهذه التحسينات:

• عرض البيانات الوصفية المُجدَّدة في صف الإصدار
  أصبح الآن من السهل فهم المشكلات وترتيبها في تطبيقك.

• عدد أقل من المشكلات المكررة
  لا ينتج عن تغيير رقم السطر مشكلة جديدة.

• تصحيح أسهل للمشكلات المعقدة ذات الأسباب الجذرية المختلفة
  استخدم المتغيرات لتصحيح أخطاء تتبع المكدس الأكثر شيوعًا داخل المشكلة.

• المزيد من التنبيهات والإشارات ذات مغزى
  يمثل الإصدار الجديد خطأً جديدًا في الواقع.

• بحث أكثر قوة
  تحتوي كل مشكلة على المزيد من البيانات الوصفية القابلة للبحث ، مثل نوع الاستثناء واسم الحزمة.

إليك كيفية طرح هذه التحسينات:

• عندما نحصل على أحداث جديدة من تطبيقك ، سنتحقق مما إذا كانت تتطابق مع مشكلة حالية.

• إذا لم يكن هناك تطابق ، فسنطبق تلقائيًا خوارزمية تجميع الأحداث الأكثر ذكاءً على الحدث وننشئ مشكلة جديدة مع تصميم البيانات الوصفية الذي تم تجديده.

هذا هو أول تحديث كبير نجريه لمجموعات الأحداث لدينا. إذا كانت لديك ملاحظات أو واجهت أي مشاكل ، فيرجى إخبارنا عن طريق تقديم تقرير.

لماذا يتم الإبلاغ عن أخطاء ANR لنظام Android 11+ فقط؟

يدعم Crashlytics إعداد تقارير ANR لتطبيقات Android من الأجهزة التي تعمل بنظام Android 11 والإصدارات الأحدث. تعد واجهة برمجة التطبيقات الأساسية التي نستخدمها لجمع أخطاء ANR ( getHistoricalProcessExitReasons ) أكثر موثوقية من SIGQUIT أو النهج القائمة على المراقبة. واجهة برمجة التطبيقات هذه متاحة فقط على أجهزة Android 11+.

لماذا تفتقد بعض أخطاء ANR إلى BuildId الخاص بهم؟

إذا كانت بعض أخطاء ANR لديك تفتقد إلى BuildId الخاصة بها ، فحاول استكشاف الأخطاء وإصلاحها على النحو التالي:

• تأكد من أنك تستخدم إصدارًا محدثًا من Crashlytics Android SDK و Crashlytics Gradle plugin.

  إذا كنت تفتقد BuildId s لنظام Android 11 وبعض أخطاء ANR لنظام التشغيل Android 12 ، فمن المحتمل أنك تستخدم SDK قديمًا أو مكون Gradle الإضافي أو كليهما. لتجميع BuildId s بشكل صحيح لحالات 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 في لوحة تحكم Crashlytics و Google Play Console

قد يكون هناك عدم تطابق بين عدد أخطاء ANR بين Google Play و Crashlytics. هذا متوقع بسبب الاختلاف في آلية جمع بيانات ANR والإبلاغ عنها. تبلغ Crashlytics عن أخطاء ANR عند بدء تشغيل التطبيق في المرة التالية ، بينما يرسل Android Vitals بيانات ANR بعد حدوث ANR.

بالإضافة إلى ذلك ، لا تعرض Crashlytics سوى أخطاء ANR التي تحدث على الأجهزة التي تعمل بنظام Android 11+ ، مقارنة بـ Google Play الذي يعرض أخطاء ANR من الأجهزة المزودة بخدمات Google Play وتقبل الموافقة على جمع البيانات.

الاختلافات بين آثار مكدس NDK في لوحة معلومات Crashlytics ولوجكات

تحتوي سلاسل أدوات LLVM و GNU على إعدادات افتراضية ومعالجات مميزة لقطاع القراءة فقط من ثنائيات تطبيقك ، مما قد يؤدي إلى إنشاء تتبعات تكديس غير متسقة في وحدة تحكم Firebase. للتخفيف من ذلك ، أضف إشارات الرابط التالية إلى عملية الإنشاء الخاصة بك:

• إذا كنت تستخدم الرابط lld من سلسلة أدوات LLVM ، أضف:

  -Wl,--no-rosegment
  

• إذا كنت تستخدم رابط ld.gold من سلسلة أدوات GNU ، أضف:

  -Wl,--rosegment
  

إذا كنت لا تزال ترى تناقضات في تتبع المكدس (أو إذا لم تكن أي من العلامات ذات صلة بسلسلة الأدوات الخاصة بك) ، فحاول إضافة ما يلي إلى عملية الإنشاء بدلاً من ذلك:

-fno-omit-frame-pointer

كيف يمكنني استخدام ملف ثنائي منشئ ملفات رموز Breakpad الخاص بي لـ NDK؟

يجمع المكوِّن الإضافي 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

إذا رأيت الاستثناء التالي ، فمن المحتمل أنك تستخدم إصدارًا من DexGuard غير متوافق مع Firebase Crashlytics SDK:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

لا يؤدي هذا الاستثناء إلى تعطل تطبيقك ولكنه يمنعه من إرسال تقارير الأعطال. لإصلاح هذا:

1. تأكد من أنك تستخدم أحدث إصدار من DexGuard 8.x. يحتوي أحدث إصدار على القواعد المطلوبة بواسطة Firebase Crashlytics SDK.

2. إذا كنت لا ترغب في تغيير إصدار DexGuard الخاص بك ، فحاول إضافة السطر التالي إلى قواعد التشويش (في ملف تكوين DexGuard الخاص بك):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct
   

لماذا أرى أعطالًا من ملفات .kt التي تم تصنيفها على أنها مشكلات .java ؟

عندما يستخدم أحد التطبيقات أداة تشويش لا تعرض امتداد الملف ، فإن Crashlytics تولد كل مشكلة بامتداد ملف .java افتراضيًا.

حتى تتمكن Crashlytics من إنشاء مشكلات تتعلق بامتداد الملف الصحيح ، تأكد من أن تطبيقك يستخدم الإعداد التالي:

• يستخدم Android Gradle 4.2.0 أو أعلى
• يستخدم R8 مع تشغيل التشويش. لتحديث تطبيقك إلى R8 ، اتبع هذه الوثائق .

لاحظ أنه بعد التحديث إلى الإعداد الموضح أعلاه ، قد تبدأ في رؤية مشكلات .kt الجديدة التي تعد نسخًا مكررة من مشكلات .java الحالية. راجع الأسئلة الشائعة لمعرفة المزيد عن هذا الظرف.

لماذا أرى مشكلات .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

• يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية عرض الملاحظات المنشورة حول مشكلة ، لكن لا يمكنهم حذف ملاحظة أو كتابتها.

  • عارض المشروع أو عارض Firebase أو عارض الجودة أو عارض Crashlytics

يستخدم التطبيق أيضًا SDK لإعلانات Google على الجوال ولكنه لا يتعرض لأعطال

إذا كان مشروعك يستخدم Crashlytics جنبًا إلى جنب مع Google Mobile Ads SDK ، فمن المحتمل أن يتدخل المراسلون المعنيون بالأعطال عند تسجيل معالجات الاستثناءات. لإصلاح المشكلة ، قم بإيقاف تشغيل إعداد التقارير عن الأعطال في SDK لإعلانات الجوال من خلال استدعاء disableSDKCrashReporting .

أين تقع مجموعة بيانات BigQuery الخاصة بي؟

بعد ربط Crashlytics بـ BigQuery ، توجد مجموعات البيانات الجديدة التي تنشئها تلقائيًا في الولايات المتحدة ، بغض النظر عن موقع مشروع Firebase.

هل يدعم Crashlytics armeabi؟

لا يدعم Firebase Crashlytics NDK ARMv5 (armeabi). تمت إزالة دعم ABI هذا اعتبارًا من NDK r17.

ما هي قضية مرتدة؟

حدث تراجع في إحدى المشكلات عندما أغلقت المشكلة مسبقًا ولكن Crashlytics تحصل على تقرير جديد يفيد بأن المشكلة قد حدثت مرة أخرى. تعيد Crashlytics فتح هذه المشكلات المتراجعة تلقائيًا بحيث يمكنك معالجتها بما يتناسب مع تطبيقك.

فيما يلي مثال على سيناريو يشرح كيف تصنف Crashlytics مشكلة على أنها انحدار:

1. لأول مرة على الإطلاق ، تحصل Crashlytics على تقرير عن حادث تحطم "أ". يفتح Crashlytics مشكلة مقابلة لذلك التعطل (المشكلة "أ").
2. يمكنك إصلاح هذا الخطأ بسرعة ، وإغلاق المشكلة "أ" ، ثم إطلاق إصدار جديد من تطبيقك.
3. يحصل موقع Crashlytics على تقرير آخر حول المشكلة "أ" بعد إغلاق المشكلة.
   • إذا كان التقرير من إصدار تطبيق كان Crashlytics على علم به عندما أغلقت المشكلة (بمعنى أن الإصدار أرسل تقرير تعطل لأي عطل على الإطلاق) ، فلن تعتبر Crashlytics المشكلة على أنها تراجعت. ستبقى القضية مغلقة.
   • إذا كان التقرير من إصدار تطبيق لم يكن Crashlytics على علم به عندما أغلقت المشكلة (مما يعني أن الإصدار لم يرسل أي تقرير تعطل مطلقًا عن أي عطل على الإطلاق) ، فإن Crashlytics تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة .

عندما تتراجع إحدى المشكلات ، نرسل تنبيهًا لاكتشاف الانحدار ونضيف إشارة تراجع إلى المشكلة لإعلامك بأن Crashlytics أعادت فتح المشكلة. إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا ، فقم بكتم المشكلة بدلاً من إغلاقها.

لماذا أرى مشكلات رجوعًا لإصدارات التطبيق الأقدم؟

إذا كان أحد التقارير من إصدار تطبيق قديم لم يرسل مطلقًا أي تقارير أعطال على الإطلاق عند إغلاق المشكلة ، فإن Crashlytics تعتبر أن المشكلة قد تراجعت وستعيد فتح المشكلة.

يمكن أن يحدث هذا الموقف في الموقف التالي: لقد أصلحت خطأ وأصدرت إصدارًا جديدًا من تطبيقك ، ولكن لا يزال لديك مستخدمون على إصدارات أقدم بدون إصلاح الخطأ. إذا لم يرسل أحد هذه الإصدارات القديمة ، عن طريق الصدفة ، أي تقارير أعطال على الإطلاق عند إغلاق المشكلة ، وبدأ هؤلاء المستخدمون في مواجهة الخطأ ، فإن تقارير الأعطال هذه ستطلق مشكلة تراجع.

إذا كنت لا تريد إعادة فتح المشكلة بسبب خوارزمية الانحدار الخاصة بنا ، فقم بكتم المشكلة بدلاً من إغلاقها.