الإبلاغ عن الأعطال في تطوير التطبيقات المحمولة — ما هو، الخدمات والإعداد

ما هو الإبلاغ عن الأعطال?

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

كل تقرير عطل يحتوي على ثلاثة مكونات رئيسية: نوع الاستثناء (NullPointerException, SIGSEGV, NSInternalInconsistencyException)، مكدس استدعاءات كامل مع أرقام الأسطر، ومعلومات عن البيئة — إصدار نظام التشغيل، طراز الجهاز، حجم الذاكرة الحرة. وفقاً لـ Sentry Engineering، 2024، فإن الجمع بين هذه العناصر الثلاثة يسمح بإعادة إنتاج وإصلاح 85% من الأخطاء الحرجة.

أنظمة الإبلاغ عن الأعطال الحديثة توسع وظائفها إلى ما بعد الأعطال العادية. Firebase Crashlytics يجمع الأعطال المتكررة تلقائياً في مشكلات، Sentry يتتبع التراجعات بين الإصدارات، و Bugsnag يظهر مسار المستخدم إلى الخطأ. الخدمات الثلاث تدعم iOS و Android و React Native و Flutter.

وفقاً لـ Google I/O 2024، التطبيقات بدون الإبلاغ عن الأعطال تقضي في المتوسط 3–5 أيام عمل لتشخيص خطأ حرج واحد، بينما مع Crashlytics يستغرق 15–30 دقيقة. توفير الوقت يتجاوز 90% لكل حادثة.

كيف يعمل نظام جمع تقارير الأعطال

الهندسة المعمارية لنظام الإبلاغ عن الأعطال تتكون من ثلاث طبقات: SDK عميل مثبت في التطبيق، API خادم لاستقبال ومعالجة التقارير، ولوحة تحكم ويب للتحليل. SDK العميل يعترض الاستثناءات غير المعالجة، ويسلسلها إلى JSON ويرسلها إلى الخادم عند بدء التشغيل التالي للتطبيق.

إرسال تقرير العطل يحدث بشكل غير متزامن بعد إعادة تشغيل التطبيق. هذه نقطة أساسية: في لحظة العطل، لا يمكن للتطبيق ضمان نجاح إرسال البيانات عبر الشبكة. SDK يكتب التقرير في التخزين المحلي، وعند بدء التشغيل التالي يرسله عبر خيط خلفية. وفقاً لـ Firebase Engineering، 2024، هذا النهج يضمن توصيل 99.7% من تقارير الأعطال.

بالنسبة للاستثناءات غير المميتة (الاستثناءات المعالجة داخل try-catch)، يرسل SDK التقرير فوراً لأن التطبيق يستمر في العمل. التقارير غير المميتة تحتوي على نفس بيانات العطل ولكنها لا تقطع جلسة المستخدم. هذا مفيد بشكل خاص لتتبع أخطاء طلبات API والتحقق من البيانات ومنطق الأعمال.

تجميع الأعطال — خوارزمية خادم تدمج الأعطال المتطابقة بناءً على تجزئة لآخر 5–10 إطارات من المكدس. هذا يسمح للمطور برؤية ليس 1000 تقرير فردي بل مشكلة واحدة مع 1000 occurrence عبر أجهزة مختلفة وإصدارات نظام تشغيل.

Firebase Crashlytics: التكامل والإمكانيات

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

تكامل Crashlytics على Android

الإعداد Crashlytics على Android بسيط: أضف التبعية في build.gradle وقم بتهيئة SDK في Application.onCreate. Crashlytics يقوم تلقائياً بتعيين Thread.setDefaultUncaughtExceptionHandler الخاص به، معترضاً جميع الاستثناءات غير المعالجة.

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

إمكانية رئيسية لـ Crashlytics — المفاتيح والسجلات المخصصة. يمكن للمطور إضافة ما يصل إلى 64 زوج مفتاح-قيمة إلى كل تقرير عطل: حالة الشاشة، الخطة المحددة، مستوى المستخدم. كما تتوفر رسائل سجل مخصصة تظهر في التقرير بترتيب زمني.

Velocity Alert — الكشف التلقائي عن التراجعات

Velocity Alert هي ميزة Crashlytics التي تراقب الزيادات الحادة في عدد الأعطال لمشكلة معينة. إذا تجاوز عدد الأعطال بعد إصدار جديد حداً معيناً، يتلقى الفريق إشعار دفع وبريد إلكتروني قبل 5–15 دقيقة من شكاوى المستخدمين الجماعية.

إعداد حد التنشيط: 2x خلال ساعة واحدة للمشكلات الحرجة. وفقاً لـ Google، 2024، الفرق التي لديها Velocity Alert مفعل تصدر إصدارات الإصلاح السريع أسرع بنسبة 40% في المتوسط من الفرق التي تعتمد على المراقبة اليدوية للوحة التحكم.

تكامل Crashlytics على iOS

على iOS يتكامل SDK Crashlytics عبر CocoaPods أو Swift Package Manager. SDK يعترض كل من استثناءات Objective-C (عبر NSSetUncaughtExceptionHandler) وإشارات نظام التشغيل (SIGSEGV, SIGABRT) من خلال معالج استثناءات mach الخاص به.

وفقاً لـ Apple Developer، 2024، Crashlytics لنظام iOS يعالج ما يصل إلى 98% من جميع أنواع الأعطال، بما في ذلك أخطاء الذاكرة منخفضة المستوى التي لا تكتشفها الأدوات القياسية. هذا يجعل Crashlytics المعيار الفعلي لتطوير iOS.

Sentry و Bugsnag: منصات بديلة

Sentry هي منصة مفتوحة المصدر لمراقبة الأخطاء تدعم أكثر من 80 لغة وإطار عمل. على عكس Crashlytics، Sentry موجهة لمطوري الخلفية ولكنها توفر SDK كاملة لنظامي iOS و Android و React Native و Flutter.

الميزة الرئيسية لـ Sentry هي مراقبة الأداء في لوحة تحكم واحدة. يرى المطورون ليس فقط الأعطال ولكن أيضاً المعاملات التي أدت إليها: طلبات الشبكة البطيئة، تجميد واجهة المستخدم، عمليات قاعدة البيانات الطويلة. وفقاً لـ Sentry، 2024، 40% من الأعطال لها مشاكل أداء سابقة تبقى غير ملحوظة بدون هذا النهج.

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

تختلف تكاليف الخدمات: Crashlytics مجاني ضمن Firebase، Sentry يقدم خطة مجانية لـ 5000 حدث شهرياً، Bugsnag من 29 دولاراً شهرياً. المنصات الثلاث توفر SDK مفتوحة المصدر. اختيار الخدمة يعتمد على حجم الفريق والميزانية ومتطلبات أمان البيانات.

الإبلاغ عن الأعطال على iOS: الخصائص و NSException

خصوصية iOS — بنية متعددة الطبقات لمعالجة الأخطاء. يجب أن تعترض SDKs الإبلاغ عن الأعطال استثناءات Objective-C (NSException)، أخطاء Swift (Error)، إشارات POSIX (SIGSEGV, SIGBUS) واستثناءات mach. كل نوع يتطلب آلية اعتراض منفصلة.

NSException هو أبسط نوع للاعتراض عبر NSSetUncaughtExceptionHandler. ومع ذلك، وفقاً لـ Apple، 2024، 30% فقط من الأعطال في تطبيقات Swift الحديثة هي NSException. أما 70% المتبقية فهي إشارات نظام تشغيل وأخطاء runtime Swift، والتي تتطلب آلية معالج استثناءات mach.

يجب على مطوري iOS اختبار الإبلاغ عن الأعطال من خلال توليد أعطال محلية من أنواع مختلفة: __builtin_trap() للإشارات، [NSException raise:...] للاستثناءات، fatalError() لـ Swift. فقط بهذه الطريقة يمكن التأكد من أن SDK يغطي جميع أنواع الأعطال.

الإبلاغ عن الأعطال على Android: ANR والأعطال الأصلية

Android يضيف نوعين محددين من الأعطال غير موجودين في iOS: ANR (التطبيق لا يستجيب) و عطل أصلي في كود C/C++. يحدث ANR عندما يتم حظر خيط واجهة المستخدم لأكثر من 5 ثوانٍ — يعرض النظام حوار "التطبيق لا يستجيب" ويقترح إغلاقه.

Thread.setDefaultUncaughtExceptionHandler القياسي لا يعترض ANR، لأنه ليس استثناءً بل إشارة من ActivityManager. لتتبع ANR، تستخدم Crashlytics و Sentry خيط مراقبة خلفية يتحقق من استجابة خيط واجهة المستخدم كل 5 ثوانٍ. وفقاً لـ Firebase، 2024، 15% من جميع مشكلات Android هي ANR وليست أعطالاً.

الأعطال الأصلية على Android تحدث في كود C/C++ الذي يعمل عبر JNI (واجهة Java الأصلية). هذه الأعطال ليست استثناءات Java ولا يتم اعتراضها بواسطة Thread.setDefaultUncaughtExceptionHandler. لمعالجتها، يتم استخدام Google Breakpad أو Crashpad، التي تقوم بتثبيت معالجات sigaction لإشارات SIGSEGV و SIGABRT و SIGBUS.

وفقاً لـ Google I/O 2024، عدد الأعطال الأصلية في ازدياد مع انتشار محركات الألعاب (Unity, Unreal Engine) ومكتبات الرؤية الحاسوبية (ML Kit, OpenCV). يُنصح مطورو التطبيقات الهجينة بتوصيل الإبلاغ عن الأعطال الأصلية دائماً.