اینڈرائیڈ میں ANR: یہ کیا ہے، وجوہات اور حل کے طریقے

اینڈرائیڈ میں ANR کیا ہے

ANR (Application Not Responding) اینڈرائیڈ میں ایک صارف تحفظ کا طریقہ کار ہے جو اس وقت فعال ہوتا ہے جب ایپ ان پٹ کا جواب دینا بند کر دیتی ہے۔ سسٹم واقعہ پروسیسنگ کے وقت کو ٹریک کرتا ہے: اگر BroadcastReceiver 10 سیکنڈ کے اندر onReceive مکمل نہیں کرتا، Service 20 سیکنڈ میں onCreate سے واپس نہیں آتی، یا ContentProvider 15 سیکنڈ میں جواب نہیں دیتا — اینڈرائیڈ ANR پیدا کرتا ہے۔

صارف کے لیے ANR کیسا لگتا ہے

جب ANR ہوتا ہے، اینڈرائیڈ تمام ونڈوز کے اوپر ایک نظامی ڈائیلاگ دکھاتا ہے: “ایپ جواب نہیں دے رہی۔ کیا آپ اسے بند کرنا چاہتے ہیں یا انتظار کرنا چاہتے ہیں؟” صارف ایپ کو بند کر سکتا ہے یا اس کے بحال ہونے کا انتظار کر سکتا ہے۔ اگر ANR بار بار ہوتے ہیں، تو صارف ایپ کو ان انسٹال کر دیتا ہے۔ Google Play اپنے درجہ بندی الگورتھم میں ANR شرح — ANR والے سیشنز کا فیصد — پر غور کرتا ہے۔

ANR اور iOS ہینگ میں فرق

iOS میں نظامی ڈائیلاگ کے ساتھ ANR کا کوئی ہم پلہ نہیں ہے۔ اس کے بجائے، Apple Watchdog استعمال کرتا ہے، جو 0x8badf00d خارجی کوڈ کے ساتھ عمل کو ختم کرتا ہے۔ صارف کو کوئی ڈائیلاگ نظر نہیں آتا — ایپ صرف ہوم اسکرین پر بند ہو جاتی ہے۔ یہ اینڈرائیڈ پر ANR کو صارف کے لیے زیادہ نمایاں بناتا ہے لیکن سسٹم کو زیادہ تشخیصی معلومات دیتا ہے۔

ANR کی بنیادی وجوہات

ANR اس وقت ہوتا ہے جب سسٹم چار اجزاء کی اقسام میں سے کسی ایک کے لیے ٹائم آؤٹ ٹریک کرتا ہے۔ ہر جزو کی اپنی وقت کی حد ہوتی ہے۔

BroadcastReceiver میں بلاک کرنا

BroadcastReceiver مرکزی تھریڈ میں عمل میں آتا ہے۔ اگر onReceive ایک مطالبتی نیٹ ورک کی درخواست، ڈیٹا بیس میں طویل تحریر شروع کرتا ہے یا لاک کا انتظار کرتا ہے — 10 سیکنڈ کے اندر ANR ہوتا ہے۔ حل: پس منظر کی کارروائی کے لیے goAsync() اور WorkManager استعمال کریں۔ ایک عام منظر نامہ FCM سے Push اطلاع وصول کرنا اور Room میں مطالبتی طور پر محفوظ کرنا ہے۔

Service میں طویل آپریشن

Service.onCreate اور Service.onStartCommand کی 20 سیکنڈ کی حد ہے۔ اگر سروس مرکزی تھریڈ میں بھاری ابتدا (لائبریریاں لوڈ کرنا، نیٹ ورک سے ترتیب پڑھنا) شروع کرتی ہے — ANR ناگزیر ہے۔ پس منظر میں یقینی عملدرآمد کے لیے IntentService (فرسودہ) یا WorkManager استعمال کریں۔

سست ابتدا کے ساتھ ContentProvider

ContentProvider.onCreate Application.onCreate سے پہلے عمل میں آتا ہے اور اس کی 15 سیکنڈ کی حد ہے۔ اگر فراہم کنندہ ڈیٹا بیس منتقلی کرتا ہے، لغتیں لوڈ کرتا ہے یا نیٹ ورک سے SDK شروع کرتا ہے — یہ ایپ اسٹارٹ اپ پر ANR کا سبب بنتا ہے۔ حل: سست ابتدا، بھاری کارروائیوں کو WorkManager میں منتقل کرنا۔

• BroadcastReceiver — onReceive کے لیے 10 سیکنڈ؛ پس منظر کی کارروائی کے لیے goAsync() استعمال کریں
• Service — onCreate/onStartCommand کے لیے 20 سیکنڈ؛ WorkManager یا CoroutineWorker استعمال کریں
• ContentProvider — onCreate کے لیے 15 سیکنڈ؛ ابتدا کو تاخیری آغاز کے ساتھ Application.onCreate میں منتقل کریں
• UI تھریڈ — واقعہ پروسیسنگ کے بغیر 5 سیکنڈ؛ 5 سیکنڈ سے زیادہ کا کوئی بھی بلاک ANR کو متحرک کرتا ہے

ANR کی تشخیص کیسے کریں

Android نظامی لاگز سے لے کر خصوصی لائبریریوں تک ANR تجزیہ کے لیے کئی اوزار فراہم کرتا ہے۔

traces.txt کا تجزیہ

ہر ANR پر، Android تمام ایپ تھریڈز کے اسٹیک ڈمپ کے ساتھ /data/anr/traces.txt فائل محفوظ کرتا ہے۔ “main” تھریڈ تلاش کریں — اسٹیک میں آخری طریقہ وجہ کی نشاندہی کرتا ہے۔ عام نمونے: Thread.sleep()، InputStream.read()، BinderProxy.transact()۔ ڈیوائس سے فائل نکالنے کے لیے، سپر یوزر مراعات کے ساتھ adb استعمال کریں۔

ANR رپورٹس کے ساتھ Firebase Crashlytics

Firebase Crashlytics خود بخود ANRs جمع کرتا ہے اور انہیں نشانات کے ساتھ ڈیش بورڈ میں دکھاتا ہے۔ Android 11+ کے لیے، ANR رپورٹس مرکزی تھریڈ کے مکمل اسٹیک کے ساتھ آتی ہیں۔ انضمام کے لیے انحصار شامل کرنا اور Application.onCreate میں FirebaseApp کو شروع کرنا ضروری ہے۔

تھریڈ ٹریسنگ کے ساتھ Android Studio Profiler

Android Studio میں CPU Profiler آپ کو ایپ کے نشانات ریکارڈ کرنے اور یہ دیکھنے کی اجازت دیتا ہے کہ کون سے طریقے CPU وقت لے رہے ہیں۔ “Record with method traces” کو فعال کریں اور ANR پیدا کرنے والے منظر نامے کو دوبارہ تخلیق کریں۔ ٹائم لائن دکھائے گی کہ ہینگ کے وقت مرکزی تھریڈ میں کون سے طریقے چل رہے تھے۔

Android پر ANR جمع کرنے کے لیے Firebase Crashlytics انضمام کی مثال:

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        FirebaseCrashlytics.getInstance()
            .setCrashlyticsCollectionEnabled(true)
        StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build())
    }
}

ANR کے علاج کے طریقے

ANR کا علاج بنیادی طور پر تمام طویل کارروائیوں کو مرکزی تھریڈ سے پس منظر کے تھریڈز میں منتقل کرنا ہے۔ آئیے ہر جزو کی قسم کے لیے مخصوص تکنیکوں پر نظر ڈالتے ہیں۔

پس منظر کے کاموں کے لیے WorkManager کا استعمال

WorkManager پس منظر کے کام کے لیے Google کا تجویز کردہ حل ہے۔ یہ ڈیوائس کی حالت کو مدنظر رکھتے ہوئے پس منظر کے تھریڈ میں کام کی انجام دہی کی ضمانت دیتا ہے۔ Service کے برعکس، WorkManager مرکزی تھریڈ کو بلاک نہیں کرتا اور ایپ کے دوبارہ شروع ہونے کے خلاف مزاحم ہے۔ BroadcastReceiver کے لیے، goAsync() استعمال کریں اور PendingResult کو WorkManager کو بھیجیں۔

مناسب ڈسپیچر کے ساتھ Kotlin Coroutines

تمام نیٹ ورک کی درخواستیں، ڈیٹا بیس کی کارروائیاں اور فائل I/O Dispatchers.IO کے ساتھ چلائیں۔ مرکزی تھریڈ کو صرف UI کو اپ ڈیٹ کرنا چاہیے۔ Activity تباہ ہونے پر خودکار coroutine منسوخی کے لیے viewModelScope استعمال کریں۔ کسی بھی سیاق و سباق میں runBlocking() سے بچیں — یہ موجودہ تھریڈ کو مطالبتی طور پر بلاک کرتا ہے۔

ContentProvider کی سست ابتدا

اگر ContentProvider سست ابتدا کرتا ہے، تو سست لوڈنگ کا طریقہ کار استعمال کریں: ایک فراہم کنندہ بنائیں جو فوری طور پر ڈیٹا لوٹاتا ہے اور WorkManager کے ذریعے تاخیر کے ساتھ بھاری ابتدا شروع کریں۔ یہ ایپ اسٹارٹ اپ پر ANR کو روکتا ہے، جب نظام تاخیر کے لیے سب سے زیادہ حساس ہوتا ہے۔

Android میں goAsync کے ساتھ BroadcastReceiver کے صحیح استعمال کی مثال:

class FcmReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        val pendingResult = goAsync()
        WorkManager.getInstance(context!!)
            .enqueue(OneTimeWorkRequest.from(NotificationWorker::class.java))
        pendingResult.finish()
    }
}

ترقی میں ANR کی روک تھام

ANR سے لڑنے کا بہترین طریقہ یہ ہے کہ اوزاروں اور تعمیری فیصلوں کے ذریعے ترقی کے دوران انہیں روکا جائے۔

مرکزی تھریڈ بلاک کا پتہ لگانے کے لیے StrictMode

فعال پالیسیوں detectNetwork() اور detectDiskReads()/detectDiskWrites() کے ساتھ StrictMode ترقی کے دوران ممکنہ ANR کی نشاندہی کرتا ہے۔ Debug بلڈز میں penaltyDeath سیٹ کریں — کوئی بھی خلاف ورزی فوری کریش کا سبب بنے گی اور ڈویلپر کمٹ سے پہلے مسئلہ دیکھے گا۔

پیداواری میٹرک کے لیے Firebase Performance Monitoring

Firebase Performance اہم کارروائیوں کے عملدرآمد کے وقت کو ٹریک کرتا ہے اور دکھاتا ہے کہ کون سے منظر نامے ANR کی حد سے تجاوز کرتے ہیں۔ ہر اسکرین اور نیٹ ورک کی درخواست کے لیے حسب ضرورت نشانات ترتیب دیں۔ اگر عملدرآمد کا وقت 3 سیکنڈ سے تجاوز کر جائے — یہ ایک ممکنہ ANR ہے جسے بہتر بنانے کی ضرورت ہے۔

نیٹ ورک اور ڈسک تاخیر کے ساتھ جانچ

سست حالات کی نقل کریں: iOS یا Android Emulator پر Network Link Conditioner استعمال کرکے نیٹ ورک کی رفتار محدود کریں۔ سست میموری کی نقل کے ذریعے ڈسک پڑھنے کو سست کریں۔ ANR اکثر ایسے حالات میں ظاہر ہوتے ہیں؛ تیز ڈویلپر ڈیوائسز پر یہ نظر نہیں آتے۔

• BroadcastReceiver — 1 سیکنڈ سے زیادہ کی کارروائی کے لیے ہمیشہ goAsync() استعمال کریں
• Service — پس منظر کے ڈسپیچر کے ساتھ WorkManager یا CoroutineWorker سے تبدیل کریں
• ContentProvider — onCreate میں نیٹ ورک اور ڈیٹا بیس سے بچیں، WorkManager کے ساتھ lazy-init استعمال کریں
• UI تھریڈ — Debug میں penaltyDeath کے ساتھ StrictMode، پیداواری نگرانی کے لیے Firebase Performance