تحديد المشاكل وحلّها في Crashlytics والأسئلة الشائعة بشأنها


تقدّم هذه الصفحة مساعدة في تحديد المشاكل وحلّها وإجابات عن الأسئلة الشائعة حول استخدام Crashlytics. إذا لم تتمكّن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية، يُرجى التواصل مع فريق دعم Firebase.

الأسئلة الشائعة/الإجراءات العامة لتحديد المشاكل وحلّها

قد تلاحظ تنسيقَين مختلفَين للمشاكل المدرَجة في جدول المشاكل في وحدة تحكّم Firebase. وقد تلاحظ أيضًا ميزة تُسمى "الصيغ" ضمن بعض مشاكلك. إليك السبب.

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

يحلِّل Crashlytics جميع الأحداث من تطبيقك (مثل الأعطال والأعطال غير المميتة وأخطاء ANR) وينشئ مجموعات من الأحداث تُسمى المشاكل، وجميع الأحداث في مشكلة ما لها نقطة فشل مشتركة.

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

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

في ما يلي الميزات التي ستستفيد منها من خلال هذه التحسينات:

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

  • عدد أقل من المشاكل المكرّرة
    لا يؤدي تغيير رقم السطر إلى ظهور مشكلة جديدة.

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

  • تنبيهات وإشارات أكثر وضوحًا
    تشير المشكلة الجديدة إلى خطأ جديد.

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

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

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

  • في حال عدم توفّر مطابقة، سنطبّق تلقائيًا على الحدث خوارزمية agrupación de eventos más inteligente الخاصة بنا وسننشئ مشكلة جديدة باستخدام تصميم metadata الذي تم تجديده.

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

إذا لم تظهر لك المقاييس الخالية من الأعطال (مثل المستخدِمين والجلسات الخالية من الأعطال) و/أو تنبيهات السرعة، تأكَّد من استخدام الإصدار 18.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) من Crashlytics (أو الإصدار 32.6.0 أو إصدار أحدث من Firebase BoM).

إذا لم تظهر لك سجلّات مسار التنقّل، ننصحك بالتحقّق من إعدادات تطبيقك بشأن Google Analytics. يجب استيفاء المتطلبات التالية:

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

إذا كانت بعض أخطاء ANR لا تتضمّن BuildId، يمكنك تحديد المشاكل وحلّها باتّباع الخطوات التالية:

  • تأكّد من استخدام أحدث إصدار من Crashlytics حزمة تطوير البرامج (SDK) لنظام التشغيل Android و Crashlytics المكوّن الإضافي لنظام Gradle.

    إذا لم تكن لديك BuildId لنظام التشغيل Android 11 وبعض أخطاء ANR في Android 12، من المحتمل أنك تستخدم حزمة تطوير برامج (SDK) أو مكوّن إضافي لنظام Gradle أو كليهما قديماً. لجمع BuildId بشكل صحيح لهذه الأخطاء ANR، عليك استخدام الإصدارين التاليين من IDE:

    • Crashlytics الإصدار 18.3.5 من حزمة تطوير البرامج (SDK) لنظام التشغيل Android والإصدارات الأحدث (الإصدار 31.2.2 من Firebase BoM والإصدارات الأحدث)
    • Crashlytics الإصدار 2.9.4 من المكوّن الإضافي Gradle والإصدارات الأحدث

  • تحقّق ممّا إذا كنت تستخدم موقعًا جغرافيًا غير عادي لمكتباتك المشتركة.

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

  • تأكَّد من عدم إزالة BuildId أثناء عملية الإنشاء.

    يُرجى العِلم أنّ النصائح التالية لتحديد المشاكل وحلّها تنطبق على كلّ من أخطاء ANR والأعطال المبرمَجة.

    • تحقَّق من توفّر BuildId من خلال تشغيل readelf -n على الملفات الثنائية. إذا كانت BuildId غير متوفّرة، أضِف -Wl,--build-id إلى العلامات الخاصة بنظام الإنشاء.

    • تأكَّد من أنّك لا تزيل BuildId عن غير قصد في محاولة لتقليل حجم حزمة APK.

    • إذا احتفظت بنسخ من مكتبة تمّت إزالة المحتوى غير الضروري منها وغير ذلك، احرص على الإشارة إلى النسخة الصحيحة في الرمز البرمجي.

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

بالإضافة إلى ذلك، لا يعرض Crashlytics سوى أخطاء ANR التي تحدث على الأجهزة التي تعمل بالإصدار 11 من Android والإصدارات الأحدث، مقارنةً بـ 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.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 properties

    يمكنك استخدام السمة com.google.firebase.crashlytics.breakpadBinary لتحديد مسار الملف التنفيذي.

    يمكنك تعديل ملف خصائص Gradle يدويًا أو تعديل الملف من خلال سطر الأوامر. على سبيل المثال، لتحديد المسار من خلال سطر الأوامر، استخدِم أمرًا مثل ما يلي:

    ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
  -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
  app:assembleRelease app:uploadCrashlyticsSymbolFileRelease

إذا ظهر لك الاستثناء التالي، من المحتمل أنّك تستخدم إصدارًا من IDE DevGuard غير متوافق مع حزمة SDK Firebase Crashlytics:

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

لا يؤدي هذا الاستثناء إلى تعطُّل تطبيقك، ولكنه يمنعه من إرسال تقارير تتعلّق بالانهيار. لحلّ هذه المشكلة، اتّبِع الخطوات التالية:

  1. تأكَّد من استخدام أحدث إصدار من DexGuard 8.x. يتضمّن أحدث إصدار قواعد مطلوبة من حزمة تطوير البرامج (SDK) لتطبيق Firebase Crashlytics.

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

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

عندما يستخدم التطبيق أداة تشويش لا تُظهر امتداد الملف، Crashlytics ينشئ كل مشكلة باستخدام امتداد ملف .java تلقائيًا.

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

  • استخدام الإصدار 4.2.0 من Android Gradle أو إصدار أحدث
  • يستخدم R8 مع تفعيل التشويش. لتحديث تطبيقك إلى الإصدار R8، اتّبِع تعليمات المستندات هذه.

يُرجى العلم أنّه بعد التحديث إلى الإعداد الموضّح أعلاه، قد تبدأ في رؤية مشاكل .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. يظهر عنوان البريد الإلكتروني هذا، بالإضافة إلى المذكرة، لجميع أعضاء المشروع الذين لديهم إذن بالاطّلاع على المذكرة.

يوضِّح ما يلي الأذونات المطلوبة لعرض الملاحظات وكتابتها وحذفها:

عمليات الدمج

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

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

دعم المنصة

لا يتوافق NDK لنظام التشغيل Firebase Crashlytics مع ARMv5 (armeabi). تم إيقاف واجهة برمجة التطبيقات هذه اعتبارًا من الإصدار r17 من NDK.

المشاكل التي تمّ حلّها

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

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

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

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

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

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

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