Firebase is back at Google I/O on May 20-21! Register now.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

تحديد المشاكل وحلّها في Crashlytics والأسئلة الشائعة بشأنها
تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

ظهور تنسيقات مختلفة (و "صيغ" في بعض الأحيان) لبعض المشاكل في جدول المشاكل

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

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

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

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

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

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

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

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

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

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

عدم ظهور سجلّات شريط التنقل

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

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

تأكَّد بشكل خاص من استخدام على الأقل الإصدار التالي من حزمة تطوير البرامج (SDK) لبرنامج Google Analytics:
Android: الإصدار 17.2.3 والإصدارات الأحدث (BoM الإصدار 24.7.1 والإصدارات الأحدث)

عدم ظهور تنبيهات السرعة

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

عدم ظهور مقاييس خالية من الأعطال (أو ظهور مقاييس غير موثوقة)

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

تأكَّد من استخدام الإصدار 18.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) من Crashlytics (أو الإصدار 32.6.0 أو إصدار أحدث من Firebase BoM).
تأكَّد من أنّ إعدادات جمع البيانات لا تؤثّر في جودة مقاييس عدم حدوث الأعطال:
- في حال تفعيل ميزة إعداد التقارير عند الموافقة من خلال إيقاف ميزة إعداد تقارير الأعطال تلقائيًا، لا يمكن إرسال معلومات الأعطال سوى إلى Crashlytics من المستخدمين الذين وافقوا صراحةً على جمع data. وبالتالي، ستتأثّر دقة المقاييس الخالية من الأعطال لأنّه ليس لدى Crashlytics سوى معلومات الأعطال من هؤلاء المستخدمين الذين وافقوا على المشاركة (بدلاً من جميع المستخدمين). وهذا يعني أنّ مقاييس عدم حدوث الأعطال قد تكون أقل اعتمادية وأقل تعبيرًا عن الثبات العام لتطبيقك.
- إذا كانت ميزة جمع البيانات التلقائي غير مفعّلة، يمكنك استخدام sendUnsentReports لإرسال التقارير المخزّنة مؤقتًا على الجهاز إلى Crashlytics. سيؤدي استخدام هذه الطريقة إلى إرسال بيانات الأعطال إلى Crashlytics، ولكن ليس data الجلسات التي تؤدي إلى عرض قيم منخفضة أو صفرية للمقاييس الخالية من الأعطال في وحدة التحكّم.

كيف يتم احتساب عدد المستخدمين الذين لم يواجههم أي تعطُّل؟

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

لماذا يتم الإبلاغ عن أخطاء ANR فقط في الإصدار 11 من نظام التشغيل Android والإصدارات الأحدث؟

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

Why are some ANRs missing their `BuildId`s?

إذا كانت بعض أخطاء 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 والإصدارات الأحدث
تحقّق ممّا إذا كنت تستخدم موقعًا جغرافيًا غير عادي لمكتباتك المشتركة.

إذا كانت لديك مكتبات مشتركة في تطبيقك لا تتضمّن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 عند بدء تشغيل التطبيق next، في حين تُرسِل "مؤشرات Android الحيوية" بيانات أخطاء ANR بعد حدوثها.

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

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

عدم حدوث أعطال عند استخدام Dexguard

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

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

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

تأكَّد من استخدام أحدث إصدار من DexGuard 8.x. يتضمّن أحدث إصدار قواعد مطلوبة من حزمة SDK الخاصة بتطبيق Firebase Crashlytics.
إذا كنت لا تريد تغيير إصدار DexGuard، جرِّب إضافة السطر التالي إلى قواعد التشويش (في ملف إعدادات DexGuard):
```
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
```

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

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

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

استخدام الإصدار 4.2.0 من Android Gradle أو إصدار أحدث
يستخدم 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. يظهر عنوان البريد الإلكتروني هذا، بالإضافة إلى المذكرة، لجميع أعضاء المشروع الذين لديهم إذن بالوصول إلى المذكرة.

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

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

عمليات الدمج

يستخدم التطبيق أيضًا حزمة SDK الخاصة بمجموعة أدوات Google Mobile Ads، ولكنّه لا يتضمّن أعطال

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

أين تقع مجموعة بياناتي في BigQuery؟

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

الحصول على الدعم من فريق المنصة

هل يتوافق Crashlytics مع armeabi؟

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

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

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

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

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

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

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

لماذا تظهر لي مشاكل تتعلّق بالأداء المنخفض في الإصدارات القديمة من التطبيق؟

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

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

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