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

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

• لقد فعّلت Google Analytics في مشروعك على Firebase.

• فعّلت ميزة مشاركة البيانات لخدمة Google Analytics. اطّلِع على مزيد من المعلومات عن هذا الإعداد في مقالة إدارة إعدادات مشاركة البيانات في "إحصاءات Google".

• لقد أضفت حزمة تطوير البرامج (SDK) لمنصة Firebase لنظام التشغيل Google Analytics إلى تطبيقك. يجب إضافة حزمة تطوير البرامج هذه بالإضافة إلى حزمة تطوير البرامج Crashlytics.

• استخدام أحدث إصدارات حزمة تطوير البرامج (SDK) لمنصّة Firebase لجميع المنتجات التي تستخدمها في تطبيقك

  تأكّد بشكل خاص من استخدام على الأقل الإصدار التالي من حزمة تطوير برامج Firebase لنظام التشغيل Google Analytics:
  iOS والإصدارات الأحدث — الإصدار 6.3.1 والإصدارات الأحدث (الإصدار 8.9.0 والإصدارات الأحدث لنظام التشغيل macOS وtvOS).

إذا لم تظهر لك تنبيهات السرعة، تأكَّد من استخدام: الإصدار 10.8.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) من Crashlytics

إذا لم تظهر لك مقاييس خالية من الأعطال (مثل المستخدمين والجلسات الخالية من الأعطال) أو إذا كانت تظهر لك مقاييس غير موثوقة، تحقّق مما يلي:

• تأكَّد من استخدام الإصدار 10.8.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) من Crashlytics.

• تأكَّد من أنّ إعدادات جمع البيانات لا تؤثّر في جودة مقاييس عدم حدوث الأعطال:

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

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

اطّلِع على فهم المقاييس الخالية من الأعطال.

لتحميل ملفات dSYMs الخاصة بمشروعك والحصول على إخراج مفصّل، يُرجى التحقّق مما يلي:

1. تأكَّد من أنّ مرحلة إنشاء مشروعك تحتوي على نص تشغيل Crashlytics، الذي يسمح لـ Xcode بتحميل ملفات dSYM لمشروعك في وقت الإنشاء (اطّلِع على بدء Crashlytics للحصول على تعليمات حول إضافة النص البرمجي). بعد تعديل مشروعك، افرض حدوث عطل وتأكَّد من ظهوره في لوحة بيانات Crashlytics.

2. إذا ظهرت لك تنبيه "تعذُّر العثور على ملف dSYM" في وحدة تحكّم Firebase، تحقَّق من Xcode للتأكّد من إنشاء ملفات dSYM بشكل صحيح للإصدار.

3. إذا كان Xcode يُنشئ ملفات dSYM بشكل صحيح، وكنت لا تزال ترى ملفات dSYM غير متوفّرة، من المحتمل أنّ أداة تشغيل النصوص البرمجية تتعذّر عليها تحميل ملفات dSYM. في هذه الحالة، جرِّب كلًّا مما يلي:

   • تأكَّد من استخدام أحدث إصدار من Crashlytics.

   • حمِّل ملفات dSYM غير المتوفّرة يدويًا:

     • الخيار 1: استخدِم خيار "السحب والإفلات" المستنِد إلى وحدة التحكّم في علامة تبويب dSYMs لتحميل أرشيف zip يحتوي على ملفات dSYM غير المتوفّرة.
     • الخيار 2: استخدِم النص البرمجي upload-symbols لتحميل ملفات dSYM غير المتوفّرة، وذلك للأرقام التعريفية العالمية للأجهزة (UUID) المقدَّمة في علامة التبويب ملفات dSYM.

4. إذا استمر ظهور أخطاء عدم توفّر ملفات dSYM أو إذا لم تنجح عمليات التحميل، يُرجى التواصل مع فريق دعم Firebase والحرص على تضمين السجلات.

إذا بدا أنّ عمليات تتبُّع تسلسل استدعاء الدوال البرمجية غير مفعَّلة بشكل جيد، تحقَّق مما يلي:

• إذا كانت اللقطات من مكتبة تطبيقك لا تحتوي على إشارات إلى رمز تطبيقك، تأكَّد من عدم ضبط -fomit-frame-pointer كعلامة compiling (تجميع).

• إذا ظهرت لك عدة إطارات (Missing) لمكتبة تطبيقك، تحقّق مما إذا كانت هناك نماذج dSYM اختيارية مُدرَجة على أنّها غير متوفّرة (لإصدار التطبيق المتأثّر) في علامة التبويب Crashlytics نماذج dSYM في وحدة تحكّم Firebase. إذا كان الأمر كذلك، اتّبِع خطوة تحديد وحلّ مشكلة "تعذُّر تحميل ملف dSYM" في مقالة الأسئلة الشائعة حول عدم توفّر ملفات dSYM أو عدم تحميلها على هذه الصفحة. يُرجى العِلم أنّ تحميل ملفات dSYM هذه لن يؤدي إلى ترميز الأعطال التي سبق حدوثها، ولكنّ ذلك سيساعد في ضمان ترميز الأعطال المستقبلية.

تتيح الملاحظات لأعضاء المشروع التعليق على مشاكل معيّنة من خلال طرح أسئلة أو إرسال رسائل بشأن الحالة أو غيرها.

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

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

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

  • مالك المشروع أو محرّره، مشرف Firebase، مشرف الجودة، أو مشرف Crashlytics

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

  • مُشاهد المشروع، مُشاهد Firebase، مُشاهد الجودة، أو مُشاهد Crashlytics

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

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

نعم، يمكنك تنفيذ Crashlytics في مشاريع macOS وtvOS. احرص على تضمين الإصدار 8.9.0 أو الإصدارات الأحدث من حزمة تطوير البرامج (SDK) لبرنامج Firebase على Google Analytics حتى تتمكّن الأعطال من الوصول إلى المقاييس التي يجمعها Google Analytics (المستخدِمون الذين لم يواجهوا أي أعطال وأحدث إصدار وتنبيهات السرعة وسجلّات مسار التنقّل).

يمكنك الآن الإبلاغ عن الأعطال في تطبيقات متعدّدة في مشروع واحد على Firebase، حتى إذا تم إنشاء التطبيقات لمنصّات Apple مختلفة (مثل iOS وtvOS و Mac Catalyst). في السابق، كان عليك فصل التطبيقات إلى مشاريع Firebase فردية إذا كانت تحتوي على معرّف الحزمة نفسه.

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

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

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

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

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

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

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