ایپ کریش: یہ کیا ہے، بند ہونے کی وجوہات اور پتہ لگانے کے طریقے

ایپ کریش کیا ہے

کریش — پروگرام کا غیر متوقع خاتمہ جو ایک غیر معمولی صورت حال کی وجہ سے ہوتا ہے جسے کوڈ نے ہینڈل نہیں کیا۔ موبائل آپریٹنگ سسٹمز میں، کریش فوری طور پر ایپ بند کر دیتا ہے اور “ایپ رک گئی” اسکرین دکھاتا ہے یا ہوم اسکرین پر واپس آ جاتا ہے۔

کریش دو بڑی کلاسز میں تقسیم ہوتے ہیں۔ ہینڈل کی گئی غلطیاں — try/catch بلاکس مستثنیٰ کو پکڑ لیتے ہیں، ایپ کام کرتی رہتی ہے، ممکنہ طور پر کچھ فعالیت کھونے کے ساتھ۔ غیر ہینڈلڈ کریش — مستثنیٰ OS لیول تک اوپر جاتا ہے، اور سسٹم پروسیس کو ختم کر دیتا ہے۔ دوسری قسم خاص طور پر خطرناک ہے کیونکہ صارف ڈیٹا محفوظ نہیں کر سکتا۔

بیس لاکھ صارفین اور 0.1% کریش ریٹ والا سسٹم ہر ریلیز پر 2,000 صارفین کھو دیتا ہے۔ Google Play Console (2024) کے مطابق، 1.5% سے زیادہ کریش ریٹ والی ایپس کو سفارشات سے خارج کر دیا جاتا ہے اور وہ 30% تک آرگینک ٹریفک کھو دیتی ہیں۔

موبائل ایپس میں کریش کی بنیادی وجوہات

NullPointerException (NPE) — Java/Kotlin میں کریش کا بادشاہ۔ null آبجیکٹ پر میتھڈ کال کرنے کی کوشش۔ Kotlin میں، null safety کی بدولت NPE کم عام ہے، لیکن !! آپریٹر استعمال کرتے وقت یا Java کوڈ کے ساتھ تعامل کرتے وقت یہ اب بھی ممکن ہے۔ Google (2024) کا اندازہ ہے کہ NPE تمام Android ایپ کریش کا 25% ہے۔

IndexOutOfBoundsException — ایک غیر موجود انڈیکس پر لسٹ کے عنصر تک رسائی۔ عام وجہ: ڈیٹا سرور سے غیر متوقع فارمیٹ میں آتا ہے، اور UI ایک ایسی پوزیشن دکھانے کی کوشش کرتا ہے جو موجود نہیں ہے۔ حل — انڈیکس کے ذریعے رسائی سے پہلے ہمیشہ کلیکشن کا سائز چیک کریں۔

ANR (Application Not Responding) — Android مخصوص مسئلہ۔ UI تھریڈ 5 سیکنڈ سے زیادہ بلاک رہتا ہے۔ بنیادی وجوہات: مین تھریڈ پر نیٹ ورک کی درخواستیں، بھاری حسابات، ڈیٹا بیس سنکرونائزیشن۔ Android میں StrictMode ڈویلپمنٹ کے دوران UI تھریڈ بلاک ہونے کا پتہ لگانے میں مدد کرتا ہے۔

OutOfMemoryError (OOM) — ایپ نے میموری کی حد عبور کر لی۔ 2–4 GB RAM والے موبائل آلات پر، بڑی تصاویر یا پیجینیشن کے بغیر لامتناہی فہرستوں کے ساتھ کام کرتے وقت OOM ایک عام مسئلہ ہے۔ حل — تصاویر لوڈ کرنے کے لیے Glide/Coil، کیشنگ کے لیے LruCache، RecyclerView میں ViewHolder۔

رن ٹائم مستثنیات اور مہلک غلطیاں

رن ٹائم مستثنیات — وہ غلطیاں جنہیں کمپائلر بلڈ ٹائم پر چیک نہیں کرتا۔ وہ صرف اس وقت ظاہر ہوتی ہیں جب کوڈ کسی مخصوص ڈیوائس پر مخصوص ڈیٹا کے ساتھ چلتا ہے۔ Java میں، یہ RuntimeException اور اس کے ذیلی طبقے ہیں: NullPointerException، IllegalArgumentException، ArithmeticException۔

مہلک غلطیاں (FATAL) — رن ٹائم نہیں، بلکہ سسٹم کی ناکامیاں۔ Signal 11 (SIGSEGV) — نیٹیو کوڈ میں میموری سیگمینٹیشن کی خلاف ورزی۔ Signal 6 (SIGABRT) — abort() کے ذریعے خود ایپ کی وجہ سے غیر معمولی خاتمہ۔ ایسے کریش کی تشخیص مشکل ہے کیونکہ اسٹیک ٹریس اکثر واضح سیاق و سباق نہیں دکھاتا۔

iOS میں، بنیادی وجوہات NSInvalidArgumentException (پیرامیٹر میں غیر متوقع nil) اور EXC_BAD_ACCESS (آزاد کردہ میموری تک رسائی) ہیں۔ Swift نے Objective-C کے مقابلے میں کریش کی تعداد کم کر دی ہے، لیکن ObjC رن ٹائم اور C لائبریریوں میں غلطیاں اب بھی کریش کا سبب بنتی ہیں۔

کریش مانیٹرنگ اور لاگ جمع کرنا

Firebase Crashlytics — موبائل ایپس کے لیے معیار۔ خود بخود اسٹیک ٹریس جمع کرتا ہے، لاگز، صارف ID اور ڈیوائس میٹا ڈیٹا شامل کرتا ہے۔ دستخط (غلطی کی کلاس + لائن) کے مطابق کریش کو گروپ کرتا ہے۔ ریئل ٹائم الرٹس — جب کریش ریٹ مقررہ حد سے تجاوز کر جائے (مثلاً، >0.1% فی گھنٹہ) تو اطلاعیں۔

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

لاگز کے لیے بہترین طریقہ کار: خطرناک کارروائی کرنے سے پہلے کلیدی میٹا ڈیٹا بھیجیں — اس طرح لاگ میں دکھائی دے گا کہ صارف کریش سے پہلے کیا کر رہا تھا۔ کسٹم کیز شامل کریں (API ورژن نمبر، آخری اسکرین، ان پٹ ڈیٹا کا سائز)۔ یہ بیکار اسٹیک ٹریس کو قابل عمل معلومات میں بدل دیتا ہے۔

مثال: Android میں Crashlytics ترتیب دینا

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

کریش سے بچاؤ کی حکمت عملی

آپشنل بائنڈنگ اور null safety — Kotlin میں nullable اقسام کے لیے `?` استعمال کریں، null کے محفوظ ہینڈلنگ کے لیے `let` اور `?:` استعمال کریں۔ Swift میں — optionals اور guard let۔ جدید Kotlin (2024) نے Contract تشریحات شامل کی ہیں: `@ContractsDsl` یہ اعلان کرنے کی اجازت دیتا ہے کہ کوئی فنکشن null واپس نہیں کرتا، اور کمپائلر اسے چیک کرتا ہے۔

نیٹ ورکنگ میں ایرر ہینڈلنگ — ہر نیٹ ورک کی درخواست کو ٹائم آؤٹ، پارسنگ کی غلطیاں اور سرور کی ناکامی کو ہینڈل کرنا چاہیے۔ Result ٹائپ کے ساتھ Retrofit — ایک سیلڈ کلاس جو ضمانت دیتی ہے کہ غلطی ہینڈل کی جائے گی۔ بغیر استثنا کے انداز: try/catch کے بجائے، کامیابی اور غلطی کی واضح ہینڈلنگ کے لیے سیلڈ Result استعمال کریں۔

فیچر فلیگ — نیا ورژن جاری کیے بغیر مسئلہ والی فعالیت کو دور سے غیر فعال کریں۔ اگر سرور سائیڈ آپریشن پرانے آلات پر کریش کا سبب بنتا ہے، تو فلیگ اسے اس گروپ کے لیے غیر فعال کر دیتا ہے۔ Firebase Remote Config اسٹور میں شائع کیے بغیر ایپ کے رویے کو تبدیل کرنے کی اجازت دیتا ہے۔

مرحلہ وار رول آؤٹ — نیا ورژن 5% صارفین کے لیے جاری کریں اور کریش ریٹ کی نگرانی کریں۔ اگر شرح ہدف سے کم رہتی ہے (عام طور پر <0.1%)، تو 25%، پھر 50%، پھر 100% تک بڑھائیں۔ Google Play Console اور App Store Connect حد سے تجاوز کرنے پر خودکار روک کے لیے مرحلہ وار رول آؤٹ کو سپورٹ کرتے ہیں۔

غلطی کا پتہ چلنے پر کارروائی کا منصوبہ

مرحلہ 1: درجہ بندی — شدت کا تعین کریں: سنگین (>1% صارفین میں کریش)، اعلیٰ (0.1–1%)، درمیانی (<0.1%)۔ سنگین کریش کے لیے — فوری ردعمل۔ باقی کے لیے — موجودہ سپرنٹ میں معیاری بگ فکس عمل۔ Google Play Console متاثرہ صارفین کی تعداد کے مطابق خود بخود کریش کی درجہ بندی کرتا ہے۔

مرحلہ 2: اسٹیک ٹریس تجزیہ — Crashlytics میں لاگ کھولیں، کریش کی صحیح جگہ دیکھیں۔ کسٹم کیز چیک کریں: کون سی اسکرین، کون سا ڈیٹا، OS ورژن۔ تازہ ترین ڈیپلائمنٹ سے منسلک کریں — اکثر کریش کوڈ میں حالیہ تبدیلی کی وجہ سے ہوتا ہے جس نے استعمال کے غیر متوقع منظر نامے کو متاثر کیا۔

مرحلہ 3: دوبارہ تخلیق — ایک جیسے پیرامیٹرز والے ڈیوائس یا ایمولیٹر پر کریش کو دوبارہ تخلیق کرنے کی کوشش کریں۔ اگر کامیاب نہ ہوں، تو کریش لاگ کو پیٹرن کے لیے چیک کریں: مخصوص ماڈل (Samsung A10)، Android ورژن (API < 26)، لوکیل۔ حل — ایک دفاعی شرط شامل کریں جو منظر نامے کا احاطہ کرے۔

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