Crash في تطوير التطبيقات المحمولة: ما هو، أنواعه وطرق منعه

ما هو Crash

Crash هو إنهاء غير طبيعي للتطبيق بسبب استثناء غير معالج أو إشارة نظام fatal لم يتم معالجتها في كود التطبيق. عندما يكتشف النظام أو الآلة الافتراضية (JVM, ART) حالة fatal — NullPointerException, IndexOutOfBoundsException, OutOfMemoryError — يقوم فورًا بإيقاف العملية وتفريغها من الذاكرة. يرى المستخدم إغلاقًا مفاجئًا للتطبيق دون أي إشعار نظامي بالخطأ. وفقًا لـ Google، التطبيقات التي يقل معدل خلوها من الأعطال عن 99% تفقد ما يصل إلى 20% من المستخدمين النشطين شهريًا.

في Android، تختلف آلية معالجة الأعطال عن أنظمة سطح المكتب. بدلاً من حوار تصحيح مع stack trace، يقوم Android ببساطة بإنهاء العملية دون حفظ معلومات مفصلة. جمع معلومات العطل هو مهمة المكتبات الخارجية (Crashlytics, Sentry, Bugsnag) التي تعترض الاستثناءات عبر Thread.setDefaultUncaughtExceptionHandler قبل إنهاء العملية.

iOS يستخدم آلية مشابهة مع NSException و Mach exceptions لمعالجة الأخطاء fatal. عند حدوث استثناء غير معالج، ينهي النظام التطبيق، ويُحفظ التقرير كملف .crash. يتطلب جمع الأعطال على iOS التكامل مع Crashlytics أو التقرير المدمج عبر Xcode Organizer.

الأنواع الرئيسية للأعطال

خمس فئات من الأعطال تغطي 90% من جميع حالات الفشل في التطبيقات المحمولة. يساعد فهم كل نوع على تشخيص المشكلات وإصلاحها في الإنتاج بشكل أسرع.

NullPointerException — ملك الأعطال

NullPointerException (NPE) هو أكثر أنواع الأعطال شيوعًا في جميع تطبيقات Java/Kotlin. يحدث عند محاولة استدعاء دالة أو الوصول إلى حقل لكائن قيمته null. السيناريوهات النموذجية: حقل Activity غير مهيأ عند تدوير الشاشة، استجابة null من الخادم أثناء إلغاء تسلسل JSON، تنقل غير دقيق عبر محول RecyclerView.

Kotlin يحل مشكلة NPE على مستوى اللغة من خلال أنواع آمنة من القيم الفارغة: String? لا يمكن استخدامه دون فحص صريح. ومع ذلك، فإن التوافق مع Java و Reflection لا يزالان يخلقان مخاطر. استخدم التعليقات التوضيحية @NonNull و @Nullable وفعّل strictNullChecks في أدوات التحليل الثابت.

fun safeLength(text: String?): Int {
    return text?.length ?: 0 // معالجة آمنة للقيم الفارغة null
}

IndexOutOfBoundsException وأخطاء المجموعات

IndexOutOfBoundsException يحدث عند الوصول إلى فهرس غير موجود في قائمة أو مصفوفة. السيناريوهات الشائعة: إزالة عنصر من RecyclerView دون مزامنة مع المحول، تعديل ArrayList متعدد الخيوط دون قفل، حساب غير صحيح للموضع في ViewPager. ConcurrentModificationException قريب له عند التكرار وتعديل المجموعات في وقت واحد.

استخدم CopyOnWriteArrayList للوصول متعدد الخيوط أو المجموعات الخالية من القفل من java.util.concurrent. لمزامنة واجهة المستخدم، استخدم DiffUtil الذي يحسب الفرق بين القائمتين القديمة والجديدة بأمان وكفاءة.

ClassCastException — مشاكل الأنواع

ClassCastException يحدث عند تحويل كائن إلى نوع غير متوافق. في Android، الأسباب النموذجية: نوع ViewHolder غير صحيح في RecyclerView (أنواع خلايا مختلفة بدون getItemViewType مناسب)، تحويل Fragment غير صحيح أثناء التنقل، كائنات Serializable بإصدارات فئات مختلفة.

استخدم التحويل الآمن في Kotlin عبر عامل التشغيل as?، الذي يعيد null عند عدم توافق الأنواع. في Java — تحقق عبر instanceof قبل التحويل. بالنسبة لكائنات Parcelable، أعلن دائمًا عن CREATOR في كل فئة.

IllegalStateException والأخطاء المنطقية

IllegalStateException يشير إلى استدعاء دالة في حالة غير مناسبة للكائن. مثال نموذجي في Android — getSupportFragmentManager() بعد onSaveInstanceState، عندما لا يُسمح بـ commit() لـ fragment. حالة شائعة أخرى — استدعاء dismiss() على حوار مغلق بالفعل.

تحقق من حالة دورة الحياة قبل عمليات FragmentManager. استخدم commitAllowingStateLoss() فقط عندما تكون متأكدًا من أن فقدان الحالة ليس حرجًا. في Kotlin، أنشئ منشئات شبيهة بـ DSL تستبعد الحالات غير الصالحة على مستوى الأنواع.

Native Crash (إشارات SIGSEGV, SIGABRT)

Native Crash يحدث في كود C/C++ الأصلي بسبب انتهاكات الذاكرة: إلغاء مرجع لمؤشر فارغ، double-free، تجاوز سعة المخزن المؤقت للمكدس. في Android، تحدث هذه الأعطال في مكتبات NDK ومحركات الألعاب (Unity, Unreal) والتبعيات النظامية. Native Crash لا يتم اعتراضه بواسطة Thread.setDefaultUncaughtExceptionHandler — فهو ينهي العملية فورًا.

لتشخيص الأعطال الأصلية، استخدم ملفات minidump (Breakpad) أو tombstones في Android. يدعم Firebase Crashlytics جمع الأعطال الأصلية عبر NDK SDK. على iOS، يتم حل مشكلة مماثلة باستخدام PLCrashReporter.

أدوات الإبلاغ عن الأعطال

ثلاث أدوات تهيمن على سوق الإبلاغ عن الأعطال في التطبيقات المحمولة. كل منها يوفر جمع stack trace، وتجميع حسب إصدار التطبيق، وإشعارات بالأعطال الجديدة.

Firebase Crashlytics

Crashlytics هي أداة الإبلاغ عن الأعطال الأكثر شيوعًا للتطبيقات المحمولة، وهي جزء من نظام Firebase البيئي. تجمع تلقائيًا stack traces ومعلومات الجهاز وإصدار نظام التشغيل والمفاتيح المخصصة للمستخدم. يستغرق التكامل 10 دقائق عبر Firebase Console و Gradle Plugin. تدعم Crashlytics أيضًا السجلات في الوقت الفعلي (Logcat) وتتبعات المستخدم.

FirebaseCrashlytics.getInstance()
    .setCustomKey("current_screen", "ProfileFragment")

FirebaseCrashlytics.getInstance()
    .log("User tapped login button")

Sentry

Sentry هو بديل لـ Crashlytics بنظام تصفية أكثر مرونة ودعم لأكثر من 90 منصة. على عكس Firebase، يوفر Sentry خادمًا مستضافًا ذاتيًا (self-hosted) للشركات ذات المتطلبات الصارمة للبيانات. يدعم Sentry التتبع التوزيعي و breadcrumbs والتكامل مع خطوط أنابيب CI/CD.

Bugsnag و AppCenter

Bugsnag يتميز بدعم التنبيهات القائمة على الشدة: يصنف الأعطال إلى critical و error و warning. AppCenter من Microsoft هي أداة مجانية بوظائف أساسية للمشاريع الصغيرة. كلاهما يدعم Android و iOS و React Native و Flutter.

كيفية تحليل العطل

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

المرحلة الأولى — قراءة stack trace. حدد الفئة والدالة وسطر الكود حيث حدث الاستثناء. تتبع سلسلة الاستدعاءات من الإطار العلوي إلى السفلي: آخر سطر في المكدس هو موقع العطل، والأسطر العلوية هي تسلسل الاستدعاءات. إزالة التعتيم (خريطة ProGuard/R8) إلزامية لإصدارات الإنتاج.

المرحلة الثانية — سياق الجهاز. يعرض Crashlytics طراز الجهاز وإصدار نظام التشغيل والذاكرة المتاحة وإصدار التطبيق. على سبيل المثال، عطل يحدث فقط على Samsung Galaxy S10 مع Android 11 يشير إلى مشكلة في إصدار معين من One UI، وليس خطأ عام في الكود.

المرحلة الثالثة — إعادة الإنتاج على جهاز اختبار. إذا لم يتكرر العطل بشكل مستقر، اسأل المستخدم عن الخطوات الدقيقة أو استخدم Remote Config لتسجيل الدخول قبل قسم الكود المشكل. اختبار AB للإصلاح على جزء من الجمهور يساعد في تأكيد الحل.

المرحلة الرابعة — المراقبة بعد الإصلاح. بعد نشر الإصلاح، راقب معدل العطل لمدة 3–5 أيام. إذا اختفى العطل تمامًا — نجح الإصلاح. إذا انخفض التكرار لكنه لم يصل إلى الصفر — يوجد سيناريو ثانٍ يتطلب تحليلًا منفصلًا.

ممارسات منع الأعطال

نهج منهجي لمنع الأعطال يشمل أدوات التحليل الثابت والاختبار الإلزامي للحالات الحدية ومعالجة الأخطاء بشكل صحيح على جميع مستويات التطبيق.

التحليل الثابت للكود

Detekt (Kotlin) و Lint (Android) يجدان المشكلات المحتملة في وقت الترجمة: المتغيرات غير المستخدمة، احتمالات NPE، استخدام غير صحيح لـ API. قم بتضمين هذه الأدوات في خط أنابيب CI مع حد للأخطاء. على سبيل المثال، Detekt مع تهيئة 30+ تحذيرًا أو أي خطأ مانع لا يمرر البناء.

اختبارات الوحدة واختبارات واجهة المستخدم

تغطية السيناريوهات الرئيسية للاستخدام باختبارات الوحدة هي الحماية الأساسية ضد أعطال الانحدار. اختبر نماذج البيانات و ViewModel وطبقات UseCase مع الحالات الحدية: قيم null وقوائم فارغة و JSON غير صالح. تغطي اختبارات واجهة المستخدم عبر Espresso أو Compose Test التدفقات الحرجة: المصادقة والدفع والتوجيه.

التدهور التدريجي

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

الإصدار التدريجي مع المراقبة

الإصدارات المرحلية هي ممارسة قياسية في Google Play و App Store: يتم توزيع إصدار جديد على 5%، ثم 20%، ثم 100% من الجمهور بفاصل 1–3 أيام. في كل مرحلة، يتم مراقبة معدل الأعطال: إذا انخفض معدل الخلو من الأعطال عن 99.5%، يتوقف الإصدار تلقائيًا. يتيح Firebase Remote Config تعطيل الميزات المشكلة دون نشر إصدار جديد.

التحكم في إصدارات التبعيات

Renovate أو Dependabot في CI يتحققان تلقائيًا من المكتبات بحثًا عن ثغرات معروفة وأخطاء حرجة. تحديث تبعية واحدة قد يزيل فئة كاملة من الأعطال. ومع ذلك، اختبر التحديثات على بيئة staging قبل الإصدار إلى الإنتاج — قد يحتوي إصدار المكتبة الجديد على تغييرات غير متوافقة.