Firebase Crashlytics — ما هو، الأعطال وتشخيص الأخطاء

ما هو Firebase Crashlytics

Firebase Crashlytics هي خدمة مجانية من Google لمراقبة استقرار التطبيقات المحمولة، استحوذت عليها Google في 2017 مع شركة Fabric. يجمع Crashlytics تلقائياً معلومات حول كل عطل في التطبيق، ويجمع الأعطال المتطابقة حسب توقيع المكدس، ويعرضها في وحدة تحكم Firebase مع أولوية حسب عدد المستخدمين المتأثرين.

التاريخ والتطور

أُطلق Crashlytics في 2011 كجزء من منصة Fabric وسرعان ما أصبح المعيار الفعلي لتقارير الأعطال في iOS. بعد استحواذ Google عليه في 2017 مقابل ما يقدر بـ 2 مليار دولار (Fabric بأكملها)، تم دمج Crashlytics في SDK Firebase. أضافت النسخة 18.0.0 (2021) دعم Kotlin Multiplatform، والنسخة 19.0.0 (2024) أدخلت جمع ANR التلقائي على Android دون إعداد إضافي. وفقاً لـ Google (2026)، يعالج Crashlytics أكثر من 10 مليارات عطل شهرياً.

الحدود المجانية لـ Crashlytics

Crashlytics يُقدَّم مجاناً بحد أقصى 500 ألف جلسة يومياً لكل مشروع Firebase. هذا يكفي لمعظم التطبيقات — وفقاً لـ Google (2026)، 95% من المشاريع لا تتجاوز الحد. عند التجاوز، لا يتوقف جمع البيانات لكن تتوقف التقارير عن التحديث حتى اليوم التالي. للمشاريع عالية الحركة، تتوفر خطتا Spark وBlaze من Firebase — يبقى Crashlytics مجانياً في كلتا الخطتين، ويُحتسب حد الجلسات بشكل منفصل.

كيف يكتشف Crashlytics الأعطال ويجمعها

تعتمد آلية الجمع في Crashlytics على اعتراض الاستثناءات على مستوى المنصة ووقت التشغيل. على Android، يُثبت SDK معالج UncaughtExceptionHandler الذي يلتقط جميع استثناءات Kotlin وJava غير المعالجة. على iOS، يستخدم Crashlytics NSSetUncaughtExceptionHandler لـ Objective-C/Swift ومعالج استثناءات Mach الخاص به لأعطال الكود الأصلي.

أنواع الأعطال المعترضة

يميز Crashlytics خمسة أنواع من الأعطال: fatal (أعطال قاتلة)، non-fatal (استثناءات غير قاتلة تُمرر يدوياً)، ANR (Android — التطبيق لا يستجيب)، signal (إشارات نظام التشغيل — SIGSEGV, SIGABRT) وOOM (نفاد الذاكرة على iOS). يُعالج كل نوع بآلية منفصلة ويُعرض في وحدة التحكم بالعلامة المقابلة.

تنسيق تقرير العطل

يحتوي كل تقرير Crashlytics على معلومات شاملة: تتبع مكدس كامل بأسماء الفئات وأرقام الأسطر، إصدار التطبيق (versionName + versionCode)، طراز الجهاز، إصدار نظام التشغيل، الذاكرة المتاحة، اتجاه الشاشة والوقت منذ التشغيل. إذا كان Firebase Analytics متصلاً، يتضمن التقرير أيضاً مسار آخر 50 حدثاً للمستخدم قبل العطل — وهذا أمر بالغ الأهمية لإعادة إنتاج العطل.

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

دمج Crashlytics في مشروع Android

ربط Crashlytics بتطبيق Android يتطلب إضافة تبعيتين في build.gradle وتكوين إضافة Google Services. يُفعّل SDK تلقائياً تقارير الأعطال عند تهيئة Firebase دون كود إضافي. للتشغيل الصحيح، يلزم أيضاً إضافة google-services وملف google-services.json من وحدة تحكم Firebase.

// build.gradle (مستوى المشروع)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (مستوى التطبيق)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

تكوين إضافة Crashlytics

تقوم إضافة com.google.firebase.crashlytics بمهمتين: توليد معرف بناء فريد (build ID) لتعيين المكدس المبهم وإنشاء موارد SDK Crashlytics تلقائياً. بدون الإضافة، ستُوسم الأعطال بأنها "unmapped" — سترى فقط أسماء فئات مبهمة (a.b.c) دون إمكانية العثور على الكود المصدر. تُضاف الإضافة إلى build.gradle الجذر وbuild.gradle لوحدة التطبيق.

التحقق من التكامل

لـ اختبار تكامل Crashlytics، يُستخدم الأسلوب الخاص forceCrash() الذي يولد استثناء اختباري. هذا الأسلوب غير متاح في إصدارات الإنتاج. بعد تشغيل عطل اختباري، يظهر التقرير في وحدة تحكم Firebase خلال 1-5 دقائق. إذا لم يظهر التقرير، تحقق من أن google-services.json يطابق حزمة التطبيق وعدم وجود أعلام في AndroidManifest تعطل جمع البيانات.

تحليل الأعطال وتجميع التقارير

توفر وحدة تحكم Crashlytics مستويين للعرض: قائمة بجميع الأعطال (Issues) مجمعة حسب نوع العطل، وتقرير مفصل لكل Issue مع تتبع وإحصائيات وبيانات مخصصة. يجمع كل Issue جميع الأعطال ذات التوقيع نفسه — نفس نوع الاستثناء وتتبع المكدس المتطابق.

Issues والتجميع

تجميع الأعطال هو ميزة رئيسية في Crashlytics. بدلاً من عرض آلاف الأعطال الفردية، تجمعها الخدمة في Issues بناءً على بصمة (fingerprint) — مجموع تدقيق لتتبع المكدس. يمكن أن يحتوي Issue واحد على من 1 إلى عدة ملايين من الأعطال. يعرض كل Issue: عدد الحالات القاتلة، عدد المستخدمين الفريدين، إصدار التطبيق الذي ظهر فيه العطل، والنسبة المئوية للمستخدمين الذين واجهوا المشكلة.

وفقاً لـ Google (2026)، في المتوسط 20% من Issues تمثل 80% من جميع أعطال التطبيق القاتلة (مبدأ باريتو). يرتب Crashlytics تلقائياً Issues حسب الشدة — كلما زاد عدد المستخدمين المتأثرين، زادت الأولوية. يتيح ذلك للمطور إصلاح المشكلات الأكثر انتشاراً أولاً.

إحصائيات حسب الإصدارات

Crashlytics يتتبع استقرار كل إصدار من التطبيق بشكل منفصل. يُظهر رسم المستخدمين الخاليين من الأعطال (crash-free users) النسبة المئوية للمستخدمين الذين لم يواجهوا عطلاً قاتلاً في كل إصدار. إذا انخفضت النسبة عن حد (افتراضياً 99%) عند التحديث، يرسل Crashlytics إشعاراً عبر البريد الإلكتروني وفي وحدة تحكم Firebase. هذا يسمح بتراجع سريع عن الإصدار المشكل أو إصدار إصلاح عاجل.

المفاتيح المخصصة والسجلات وBreadcrumbs

Crashlytics يوفر ثلاث آليات لإثراء التقارير بالسياق: مفاتيح مخصصة (keys) للبيانات المنظمة، سجلات (logs) للتتبع النصي، وBreadcrumbs من Analytics لمسار المستخدم. جميع أنواع البيانات الثلاثة تُرفق بتقرير العطل وتكون مرئية في بطاقة التفاصيل الخاصة به.

المفاتيح المخصصة

Custom Keys هي أزواج مفتاح-قيمة تُرسل مع كل عطل. حد أقصى 64 مفتاحاً لكل تطبيق، كل مفتاح هو سلسلة تصل إلى 1024 حرفاً. المفاتيح مفيدة لتوسيم حالة التطبيق: مستوى الاشتراك، حالة التفويض، آخر شاشة، هل VPN مفعل. القيم تُستبدل — مفتاح جديد بنفس الاسم يحل محل القديم.

تسجيل الأحداث

Custom Logs هي رسائل نصية يخزنها Crashlytics في مخزن دائري بحجم 64 كيلوبايت. تُرفق السجلات تلقائياً بالعطل التالي. إذا لم يحدث عطل، لا تُرسل السجلات إلى الخادم (لا تستهلك حركة مرور). يُستخدم التسجيل لتسجيل خطوات المستخدم قبل العطل: "payment_processing_started"، "api_call_initiated"، "response_received_200".

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

Breadcrumbs من Analytics

إذا كان Firebase Analytics متصلاً بالمشروع، يتلقى Crashlytics تلقائياً Breadcrumbs — آخر 50 حدث تحليلات قبل العطل. يحتوي كل breadcrumb على اسم الحدث ومعلماته. يتيح ذلك إعادة بناء التسلسل الدقيق للإجراءات التي أدت إلى العطل: المستخدم فتح الشاشة → أضاف منتجاً → انتقل إلى الدفع → حدث العطل. تُعرض Breadcrumbs في بطاقة Issue في علامة تبويب منفصلة "Logs".

أفضل الممارسات للعمل مع الأعطال

Crashlytics يكون أكثر فعالية عند تكوين السياق وعملية معالجة Issues بشكل صحيح. تُظهر الممارسة أن الفرق التي طبقت سير عمل لإدارة الأعطال تقلل وقت إصلاح الأخطاء الحرجة بنسبة 60% (بيانات Google، 2026).

تحديد أولويات Issues

ليست كل الأعطال بنفس الأهمية. تحديد الأولويات حسب عدد المستخدمين والتكرار يساعد في التركيز على المشكلات الأكثر حرجاً. القاعدة العامة: إصلاح Issues التي تؤثر على أكثر من 0.1% من المستخدمين خلال 24 ساعة. Issues ذات الحدوث الفردي (< 0.01%) يمكن تأجيلها حتى الإصدار المخطط التالي. يضع Crashlytics علامة تلقائياً على الانتكاسات (regressions) — Issues التي تم إصلاحها لكنها ظهرت مرة أخرى في إصدار جديد.

التكامل مع CI/CD

API Crashlytics تسمح بدمج تقارير الأعطال في خط أنابيب CI/CD عبر REST API أو Firebase CLI. مع كل إصدار جديد، يمكنك التحقق تلقائياً مما إذا كانت نسبة المستخدمين الخاليين من الأعطال تتجاوز حداً معيناً. إذا تجاوز الحد، يمنع CI/CD النشر ويرسل إشعاراً للفريق. يدعم Firebase CLI الأمر firebase crashlytics:builds:upload لرفع ملفات تعيين ProGuard/R8 — بدونها ستكون المكدسات غير قابلة للقراءة.

وفقاً لـ Google (2026)، التطبيقات التي تستخدم التحقق التلقائي من حد المستخدمين الخاليين من الأعطال في CI/CD تصدر انتكاسات أقل بنسبة 40% إلى الإنتاج. الحد الموصى به: مستخدمون خالون من الأعطال >= 99.5% للإصدارات الحرجة و>= 99.0% للإصدارات العادية.