موبائل ڈویلپمنٹ میں Crash: یہ کیا ہے، اقسام اور روک تھام کے طریقے

Crash کیا ہے

Crash ایک ایپلیکیشن کا غیر معمولی خاتمہ ہے جو ایک غیر ہینڈل شدہ استثنیٰ یا مہلک نظام کے سگنل کی وجہ سے ہوتا ہے جسے ایپلیکیشن کوڈ میں ہینڈل نہیں کیا گیا۔ جب نظام یا ورچوئل مشین (JVM, ART) ایک مہلک حالت کا پتہ لگاتی ہے — NullPointerException, IndexOutOfBoundsException, OutOfMemoryError — یہ فوری طور پر عمل کو روک دیتی ہے اور اسے میموری سے نکال دیتی ہے۔ صارف بغیر کسی نظام کی خرابی کے اطلاع کے ایپلیکیشن کو اچانک بند ہوتے دیکھتا ہے۔ Google کے مطابق، 99% سے کم کریش فری شرح والی ایپلیکیشنز ماہانہ 20% تک فعال صارفین کھو دیتی ہیں۔

Android پر، کریش ہینڈلنگ کا طریقہ کار ڈیسک ٹاپ سسٹم سے مختلف ہے۔ اسٹیک ٹریس کے ساتھ ڈیبگ ڈائیلاگ کے بجائے، Android تفصیلی معلومات محفوظ کیے بغیر عمل کو ختم کر دیتا ہے۔ کریش کی معلومات جمع کرنا تیسرے فریق کی لائبریریوں (Crashlytics, Sentry, Bugsnag) کا کام ہے جو عمل ختم ہونے سے پہلے Thread.setDefaultUncaughtExceptionHandler کے ذریعے استثنیات کو روکتی ہیں۔

iOS مہلک غلطیوں کو سنبھالنے کے لیے NSException اور Mach exceptions کے ساتھ اسی طرح کا طریقہ کار استعمال کرتا ہے۔ جب ایک غیر ہینڈل شدہ استثنیٰ ہوتا ہے، نظام ایپلیکیشن کو ختم کر دیتا ہے اور رپورٹ .crash فائل کے طور پر محفوظ ہو جاتی ہے۔ iOS پر کریش جمع کرنے کے لیے Crashlytics کے ساتھ انضمام یا Xcode Organizer کے ذریعے بلٹ ان رپورٹ کی ضرورت ہوتی ہے۔

کریش کی اہم اقسام

پانچ اقسام موبائل ایپلیکیشنز میں تمام ناکامیوں کا 90% احاطہ کرتی ہیں۔ ہر قسم کو سمجھنا پروڈکشن میں مسائل کی تیزی سے تشخیص اور اصلاح میں مدد کرتا ہے۔

NullPointerException — کریش کا بادشاہ

NullPointerException (NPE) تمام Java/Kotlin ایپلیکیشنز میں کریش کی سب سے عام قسم ہے۔ یہ کسی ایسی چیز کے طریقہ کار کو کال کرنے یا فیلڈ تک رسائی حاصل کرنے کی کوشش کرنے پر ہوتا ہے جو null ہے۔ عام منظرنامے: اسکرین گھومنے پر غیر ابتدائی شدہ Activity فیلڈ، JSON ڈی سیریلائزیشن کے دوران سرور سے null جواب، RecyclerView اڈاپٹر کے ذریعے لاپرواہ نیویگیشن۔

Kotlin null محفوظ اقسام کے ذریعے زبان کی سطح پر 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 سے لاک فری مجموعے استعمال کریں۔ UI ہم آہنگی کے لیے، DiffUtil استعمال کریں جو پرانی اور نئی فہرستوں کے درمیان فرق کو محفوظ اور مؤثر طریقے سے شمار کرتا ہے۔

ClassCastException — قسم کے مسائل

ClassCastException کسی چیز کو غیر مطابقت پذیر قسم میں ڈھالنے پر ہوتا ہے۔ Android میں، عام وجوہات: RecyclerView میں غلط ViewHolder قسم (مناسب getItemViewType کے بغیر مختلف سیل کی اقسام)، نیویگیشن کے دوران غلط Fragment کاسٹنگ، مختلف کلاس ورژن والی Serializable اشیاء۔

as? آپریٹر کے ذریعے Kotlin کا محفوظ کاسٹ استعمال کریں، جو قسم کی عدم مطابقت پر null لوٹاتا ہے۔ Java میں — کاسٹ کرنے سے پہلے instanceof کے ذریعے جانچ کریں۔ Parcelable اشیاء کے لیے، ہر کلاس میں CREATOR کا اعلان کریں۔

IllegalStateException اور منطقی غلطیاں

IllegalStateException کسی چیز کی نامناسب حالت میں طریقہ کار کال کرنے کا اشارہ کرتا ہے۔ Android میں ایک عام مثال — onSaveInstanceState کے بعد getSupportFragmentManager()، جب Fragment کا commit() کی اجازت نہیں ہے۔ ایک اور عام معاملہ — پہلے سے بند ڈائیلاگ پر dismiss() کال کرنا۔

FragmentManager کے آپریشنز سے پہلے زندگی کے چکر کی حالت چیک کریں۔ commitAllowingStateLoss() صرف اس وقت استعمال کریں جب آپ کو یقین ہو کہ حالت کا نقصان اہم نہیں ہے۔ Kotlin میں، DSL نما بلڈرز بنائیں جو قسم کی سطح پر غلط حالتوں کو ختم کرتے ہیں۔

Native Crash (SIGSEGV, SIGABRT سگنل)

Native Crash میموری کی خلاف ورزیوں کی وجہ سے مقامی C/C++ کوڈ میں ہوتا ہے: null پوائنٹر حوالہ، ڈبل فری، اسٹیک بفر اوور فلو۔ Android میں، اس طرح کے کریش NDK لائبریریوں، گیم انجنوں (Unity, Unreal) اور نظام کے انحصار میں ہوتے ہیں۔ Native Crash Thread.setDefaultUncaughtExceptionHandler کے ذریعے نہیں روکا جاتا — یہ عمل کو فوراً ختم کرتا ہے۔

مقامی کریش کی تشخیص کے لیے، minidump فائلیں (Breakpad) یا Android tombstones استعمال کریں۔ Firebase Crashlytics NDK SDK کے ذریعے مقامی کریش جمع کرنے کی حمایت کرتا ہے۔ iOS پر، اسی طرح کا مسئلہ PLCrashReporter استعمال کرکے حل کیا جاتا ہے۔

کریش رپورٹنگ کے اوزار

تین اوزار موبائل کریش رپورٹنگ مارکیٹ پر حاوی ہیں۔ ہر ایک اسٹیک ٹریس جمع، ایپلیکیشن ورژن کے لحاظ سے جمع اور نئے کریش کی اطلاع فراہم کرتا ہے۔

Firebase Crashlytics

Crashlytics موبائل ایپلیکیشنز کے لیے سب سے مشہور کریش رپورٹر ہے، جو Firebase ماحولیاتی نظام کا حصہ ہے۔ یہ خود بخود اسٹیک ٹریس، ڈیوائس کی معلومات، OS ورژن اور صارف کی حسب ضرور کلیدیں جمع کرتا ہے۔ انضمام میں Firebase Console اور Gradle Plugin کے ذریعے 10 منٹ لگتے ہیں۔ Crashlytics ریئل ٹائم لاگز (Logcat) اور صارف کے ٹریک کو بھی سپورٹ کرتا ہے۔

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

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

Sentry

Sentry ایک زیادہ لچکدار فلٹرنگ سسٹم اور 90+ پلیٹ فارمز کی حمایت کے ساتھ Crashlytics کا متبادل ہے۔ Firebase کے برعکس، Sentry سخت ڈیٹا کی ضروریات والی کمپنیوں کے لیے سیلف ہوسٹڈ سرور فراہم کرتا ہے۔ Sentry تقسیم شدہ ٹریکنگ، breadcrumbs اور CI/CD پائپ لائن انضمام کی حمایت کرتا ہے۔

Bugsnag اور AppCenter

Bugsnag شدت پر مبنی الرٹس کی حمایت کے لیے نمایاں ہے: یہ کریش کو critical، error اور warning میں درجہ بندی کرتا ہے۔ Microsoft کا AppCenter چھوٹے پروجیکٹس کے لیے بنیادی فعالیت کے ساتھ ایک مفت ٹول ہے۔ دونوں Android، iOS، React Native اور Flutter کو سپورٹ کرتے ہیں۔

کریش کا تجزیہ کیسے کریں

کریش کا تجزیہ واقعہ کی مکمل تصویر کی تشکیل نو کا عمل ہے۔ اسٹیک ٹریس صرف آخری ناکامی کا نقطہ دکھاتا ہے لیکن وہ سیاق و سباق فراہم نہیں کرتا جو مسئلے کا باعث بنا۔ ایک پیشہ ورانہ نقطہ نظر میں چار مراحل شامل ہیں۔

پہلا مرحلہ — اسٹیک ٹریس پڑھنا۔ اس کلاس، طریقہ کار اور کوڈ کی لائن کی نشاندہی کریں جہاں استثنیٰ ہوا۔ کال چین کو اوپری فریم سے نیچے والے فریم تک ٹریس کریں: اسٹیک میں آخری لائن کریش کا مقام ہے، اور اوپری لائنیں کال کی ترتیب ہیں۔ پروڈکشن بلڈز کے لیے ڈی ابفاسکیشن (ProGuard/R8 میپنگ) لازمی ہے۔

دوسرا مرحلہ — ڈیوائس کا سیاق و سباق۔ Crashlytics ڈیوائس ماڈل، OS ورژن، دستیاب میموری اور ایپلیکیشن ورژن دکھاتا ہے۔ مثال کے طور پر، Android 11 کے ساتھ صرف Samsung Galaxy S10 پر ہونے والا کریش ایک مخصوص One UI ورژن کے ساتھ مسئلہ کی طرف اشارہ کرتا ہے، عام کوڈ کی غلطی نہیں۔

تیسرا مرحلہ — ٹیسٹ ڈیوائس پر دوبارہ پیدا کرنا۔ اگر کریش مستقل طور پر دوبارہ پیدا نہیں ہوتا، صارف سے صحیح اقدامات پوچھیں یا مسئلہ کوڈ والے حصے سے پہلے لاگنگ کے لیے Remote Config استعمال کریں۔ سامعین کے ایک حصے پر فکس کا AB ٹیسٹ حل کی تصدیق کرنے میں مدد کرتا ہے۔

چوتھا مرحلہ — فکس کے بعد نگرانی۔ فکس شائع کرنے کے بعد، 3–5 دن تک کریش کی شرح کی نگرانی کریں۔ اگر کریش مکمل طور پر غائب ہو جائے — فکس کام کر گیا۔ اگر تعدد کم ہوا لیکن صفر نہیں ہوا — ایک دوسرا منظرنامہ ہے جس کے لیے علیحدہ تجزیہ کی ضرورت ہے۔

کریش سے بچاؤ کی مشقیں

کریش سے بچاؤ کے لیے ایک منظم نقطہ نظر میں جامد تجزیہ کے اوزار، لازمی کنارے کیس کی جانچ اور ایپلیکیشن کی تمام سطحوں پر مناسب غلطی کا انتظام شامل ہے۔

جامد کوڈ تجزیہ

Detekt (Kotlin) اور Lint (Android) مرتب کرنے کے وقت ممکنہ مسائل تلاش کرتے ہیں: غیر استعمال شدہ متغیرات، ممکنہ NPE، غلط API استعمال۔ ان اوزاروں کو غلطی کی حد کے ساتھ CI پائپ لائن میں شامل کریں۔ مثال کے طور پر، 30+ انتباہات یا کسی بھی غلطی کو روکنے والی ترتیب کے ساتھ Detekt بلڈ کو پاس نہیں ہونے دیتا۔

یونٹ ٹیسٹ اور UI ٹیسٹ

یونٹ ٹیسٹ کے ساتھ اہم استعمال کے منظرناموں کا احاطہ رجعت کریش کے خلاف بنیادی تحفظ ہے۔ کنارے کیسز (null اقدار، خالی فہرستیں، غلط JSON) کے ساتھ ڈیٹا ماڈل، ViewModel اور UseCase پرتوں کی جانچ کریں۔ Espresso یا Compose Test کے ذریعے UI ٹیسٹ اہم بہاؤ کا احاطہ کرتے ہیں: تصدیق، ادائیگی، آن بورڈنگ۔

خوبصورت انحطاط

ایپلیکیشن کو اس طرح ڈیزائن کریں کہ ایک ماڈیول میں ناکامی پوری اسکرین کو کریش نہ کرے۔ فال بیک حالت کے ساتھ ViewModel کی سطح پر کیچ بلاکس استعمال کریں: فہرست کے بجائے پلیس ہولڈر دکھانا، آف لائن ہونے پر کیشڈ ڈیٹا، لوڈنگ کی غلطی پر فال بیک امیج۔ یہ ممکنہ کریش کو کنٹرول شدہ UX منظرنامے میں بدل دیتا ہے۔

نگرانی کے ساتھ مرحلہ وار رول آؤٹ

مرحلہ وار رول آؤٹ Google Play اور App Store پر ایک معیاری عمل ہے: ایک نیا ورژن 5%، پھر 20%، پھر 100% سامعین تک 1–3 دن کے وقفے سے تقسیم کیا جاتا ہے۔ ہر مرحلے پر کریش کی شرح کی نگرانی کی جاتی ہے: اگر کریش فری شرح 99.5% سے نیچے گرتی ہے، رول آؤٹ خود بخود رک جاتا ہے۔ Firebase Remote Config نیا ورژن شائع کیے بغیر مسئلہ والی خصوصیات کو غیر فعال کرنے کی اجازت دیتا ہے۔

انحصار ورژن کنٹرول

CI میں Renovate یا Dependabot معروف کمزوریوں اور اہم بگز کے لیے لائبریریوں کو خود بخود چیک کرتے ہیں۔ ایک واحد انحصار کو اپ ڈیٹ کرنے سے کریش کی پوری کلاس ختم ہو سکتی ہے۔ تاہم، پروڈکشن میں رول آؤٹ کرنے سے پہلے اسٹیجنگ ماحول میں اپ ڈیٹس کی جانچ کریں — لائبریری کے نئے ورژن میں غیر مطابقت پذیر تبدیلیاں ہو سکتی ہیں۔