Android ڈیولپمنٹ میں ANR — یہ کیا ہے، وجوہات اور اسے ٹھیک کرنے کے طریقے

ANR کیا ہے

ANR (Application Not Responding) Android آپریٹنگ سسٹم کا ایک ڈائیلاگ باکس ہے جو ظاہر ہوتا ہے جب ایپ صارف کے ان پٹ پر جواب دینا بند کردے۔ سسٹم InputDispatcher کے ذریعے واقعہ پروسیسنگ وقت کو ٹریک کرتا ہے: اگر کوئی ٹچ یا بٹن دباؤ 5 سیکنڈ کے اندر پروسیس نہ ہو، تو Android ایپ کو بند کرنے یا انتظار کرنے کا اختیار دیتے ہوئے ڈائیلاگ دکھاتا ہے۔

ANR میکانزم منجمد ایپس سے صارف کے تجربے کی حفاظت کرتا ہے۔ Android ایک ایپ کو پورے سسٹم کو بلاک کرنے کی اجازت نہیں دیتا — ڈیسک ٹاپ OS کے برعکس، موبائل پلیٹ فارم زبردستی واقعہ پروسیسنگ وقت کو محدود کرتا ہے۔ BroadcastReceiver کی 10 سیکنڈ کی حد ہے اور foreground سروس کی 20 سیکنڈ کی حد ہے۔

ANR کوڈ میں کوئی استثنا نہیں ہے — یہ Linux عمل کی سطح پر ایک سسٹم میکانزم ہے۔ Android عمل کو SIGQUIT سگنل بھیجتا ہے، جس کے بعد سسٹم تمام تھریڈز کے کال اسٹیک کو traces.txt فائل میں محفوظ کرتا ہے۔ ڈیولپر ANR کو catch استثنا کے طور پر نہیں، بلکہ ایپ دوبارہ شروع ہونے کے بعد رپورٹ کے طور پر حاصل کرتا ہے۔ Android 11+ پر، ApplicationExitInfo API پروگراماتی طور پر عمل ختم ہونے کی وجہ حاصل کرنے کی اجازت دیتی ہے، بشمول ANR — یہ دستی traces.txt تجزیہ کے بغیر اعدادوشمار جمع کرنے کو آسان بناتا ہے۔

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

پانچ زمرے کی عملیات Android ایپس میں مستقل طور پر ANR کا باعث بنتی ہیں۔ ان میں سے ہر ایک مرکزی تھریڈ کو روکتا ہے، سسٹم کو ان پٹ واقعات اور اسکرین دوبارہ ڈرائنگ پر کارروائی کرنے سے روکتا ہے۔

مرکزی تھریڈ پر نیٹ ورک کی درخواستیں

UI تھریڈ پر انجام دی گئی مطابقت پذیر HTTP درخواستیں ابتدائی ڈیولپرز میں ANR کی سب سے عام وجہ ہیں۔ سرور سے ایک تیز درخواست بھی 1–3 سیکنڈ لے سکتی ہے، اور خراب کنکشن پر — 30 سیکنڈ یا اس سے زیادہ۔ Android API 11 سے مرکزی تھریڈ پر نیٹ ورک کی عملیات کو واضح طور پر منع کرتا ہے، NetworkOnMainThreadException پھینکتا ہے۔

غیر مطابقت پذیر کالز کے لیے Coroutines یا RxJava استعمال کریں۔ Dispatchers.IO ڈسپیچر والے coroutines پس منظر کے تھریڈ پر درخواست انجام دیتے ہیں اور Dispatchers.Main کے ذریعے نتیجہ مرکزی تھریڈ کو بھیجتے ہیں۔ یہ نیٹ ورک عملیات کے ذریعے UI تھریڈ روکے جانے کو مکمل طور پر ختم کرتا ہے۔

fun fetchUserData() {
    CoroutineScope(Dispatchers.Main).launch {
        val result = withContext(Dispatchers.IO) {
            api.getUserData() // پس منظر کا عمل
        }
        updateUI(result) // مرکزی تھریڈ پر نتیجہ
    }
}

UI تھریڈ پر گہری کمپیوٹیشن

بڑے ڈیٹا ایریز کو پروسیس کرنا، JSON یا XML کو پارس کرنا، براہ راست مرکزی تھریڈ پر bitmap کے ساتھ کام کرنا — ANR کی دوسری سب سے عام وجہ۔ واقعہ لوپ میں واپس آئے بغیر UI تھریڈ کے 300 ملی سیکنڈ مسلسل کام کرنے سے بھی رینڈرنگ میں نمایاں تاخیر ہوتی ہے، اور 5 سیکنڈ کی حد ANR کے طور پر ریکارڈ کی جاتی ہے۔

WorkManager اور پس منظر کی خدمات بھاری کمپیوٹیشن کو مرکزی تھریڈ سے ہٹانے کے لیے ڈیزائن کی گئی ہیں۔ UI کو روکے بغیر ڈیٹا کو ٹکڑوں میں منتقل کرنے کے لیے AsyncTask (متروک)، ListenableFuture یا Kotlin Flow استعمال کریں۔

ہم آہنگی کے لاک اور Deadlock

Deadlock اس وقت ہوتا ہے جب دو تھریڈ لاک رکھتے ہیں اور ایک دوسرے کا انتظار کرتے ہیں۔ اگر تھریڈز میں سے ایک مرکزی تھریڈ ہے، تو سسٹم ٹھیک 5 سیکنڈ کے بعد ANR ریکارڈ کرتا ہے۔ UI تھریڈ سے بلائے گئے Thread.join()، CountDownLatch.await() اور synchronized بلاکس روکے جانے کا خطرہ رکھتے ہیں۔

مرکزی تھریڈ پر کسی بھی روکنے والی کارروائی سے گریز کریں۔ synchronized کی بجائے ConcurrentHashMap استعمال کریں؛ Thread.join() کی بجائے async/await کے ساتھ coroutines استعمال کریں۔ یہ قاعدہ Android میں کسی بھی زبان پر لاگو ہوتا ہے: Java، Kotlin یا JNI کے ذریعے C++۔

طویل عرصے تک چلنے والا BroadcastReceiver

BroadcastReceiver ڈیفالٹ طور پر مرکزی تھریڈ پر چلتا ہے۔ اگر onReceive() 10 سیکنڈ سے زیادہ مصروف ہو، تو Android ANR دکھاتا ہے۔ onReceive کے اندر ڈیٹابیس یا نیٹ ورک سے ڈیٹا لوڈ کرنا منجمد ہونے کا یقینی راستہ ہے۔

پس منظر کے تھریڈ پر سوئچ کرنے کے لیے BroadcastReceiver کے اندر goAsync() استعمال کریں، یا getBackgroundBroadcastReceiver() کے ساتھ registerReceiver استعمال کریں۔ یہ UI کو روکے بغیر واقعات پر کارروائی کرنے کی اجازت دیتا ہے۔

مرکزی تھریڈ پر ContentProvider اور SQLite

ContentProvider کو بھاری سوالات یا UI تھریڈ پر SQLite کے ساتھ براہ راست کام — ANR کی ایک کم واضح لیکن عام وجہ۔ ڈیٹابیس کی منتقلی یا ہزاروں ریکارڈز کی بلک اندراج کے دوران، عملدرآمد کا وقت 5 سیکنڈ کی حد سے تجاوز کر سکتا ہے۔

تمام ڈیٹابیس عملیات کو suspend فنکشنز کے ساتھ Room کے ذریعے پس منظر کے تھریڈز میں منتقل کریں۔ Room خود بخود چیک کرتا ہے کہ سوال مرکزی تھریڈ پر انجام نہیں دے رہا ہے اور خلاف ورزی کی صورت میں استثنا پھینکتا ہے۔

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

ANR کی تشخیص عام استثناؤں کی ڈیبگنگ سے مختلف ہے — آپ ANR کو try-catch بلاک میں نہیں پکڑ سکتے۔ معلومات کا بنیادی ذریعہ traces.txt فائل ہے، جو Android منجمد ہونے کے لمحے بناتا ہے۔

traces.txt میں ANR کے وقت تمام ایپ تھریڈز کا کال اسٹیک ہوتا ہے۔ حقیقی ڈیوائس سے فائل پڑھنے کے لیے، adb bugreport کمانڈ چلائیں، جو حالیہ تمام ANRs سمیت مکمل سسٹم رپورٹ جمع کرتی ہے۔ ایمولیٹر کے لیے، فائل /data/anr/traces.txt پر دستیاب ہے۔ کال اسٹیک دکھاتا ہے کہ روکے جانے کے وقت مرکزی تھریڈ پر کون سا طریقہ کار انجام دے رہا تھا۔

adb bugreport bugreport.zip
unzip -p bugreport.zip "*traces*" > traces.txt

Google Play Console جمع شدہ رپورٹس اور غلطی کی تعدد کے ساتھ ANR & Crash سیکشن فراہم کرتی ہے۔ ہر ANR کے لیے، کال اسٹیک اور ڈیوائس کے اعدادوشمار دکھائے جاتے ہیں: ماڈل، Android ورژن، علاقہ۔ یہ مخصوص ڈیوائسز یا سسٹم ورژن پر منحصر ANRs کی شناخت کرنے کی اجازت دیتا ہے۔

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

ANR کو کیسے روکیں

ANR کی روک تھام ایک بنیادی اصول پر مبنی ہے: مرکزی تھریڈ کو صرف UI واقعات کو ہینڈل کرنا چاہیے۔ 16 ملی سیکنڈ (ایک فریم کا وقت) سے زیادہ لمبی کوئی بھی کارروائی پس منظر کے تھریڈ پر انجام دی جانی چاہیے۔

StrictMode — خودکار جانچ

StrictMode ترقی کے دوران ممکنہ ANRs کا پتہ لگانے کے لیے Android کا بلٹ ان ٹول ہے۔ اسے ڈسک اور نیٹ ورک عملیات کے لیے جھنڈوں کے ساتھ Application.onCreate() میں فعال کریں۔ خلاف ورزی پر، StrictMode استثنا پھینکتا ہے یا logcat میں لکھتا ہے۔

if (BuildConfig.DEBUG) {
    StrictMode.ThreadPolicy.Builder()
        .detectDiskReads()
        .detectDiskWrites()
        .detectNetwork()
        .penaltyLog()
        .build()
        .let { StrictMode.setThreadPolicy(it) }
}

غیر مطابقت پذیر نمونے: Coroutines اور RxJava

Kotlin Coroutines — جدید Android ایپس میں غیر مطابقت پذیر کام کا معیاری طریقہ۔ بنیادی طریقہ: I/O عملیات Dispatchers.IO پر انجام دی جاتی ہیں، نتیجہ UI اپ ڈیٹس کے لیے Dispatchers.Main کو بھیجا جاتا ہے۔ Flow جیسے منظرناموں کے لیے، CPU گہرے کاموں کے لیے Dispatchers.Default استعمال کریں۔

RxJava پرانے منصوبوں میں مقبول رہتا ہے۔ subscribeOn(Schedulers.io()) اور observeOn(AndroidSchedulers.mainThread()) — ANR کو روکنے کے لیے کم از کم سیٹ۔ بنیادی اصول وہی ہے: کوئی Observable یا Flowable مرکزی تھریڈ سے ڈیٹا خارج نہیں کرنا چاہیے۔

پیداوار میں نگرانی

Firebase Crashlytics SDK ورژن 18.4.0 سے ANR نگرانی کو باکس سے باہر سپورٹ کرتا ہے۔ Android 11+ کے لیے، Crashlytics سسٹم API ApplicationExitInfo استعمال کرتا ہے، جو صحیح ختم ہونے کی وجہ فراہم کرتا ہے: ANR، Crash، یا سسٹم قتل۔ سیاق و سباق کے تجزیہ کے لیے اسکرین اور حالت کے پیرامیٹرز کے ساتھ حسب ضرور کیز کو فعال کریں۔

ANR کا پتہ لگانے کے اوزار

پانچ اوزار ANR کے ساتھ کام کرنے کے تمام مراحل کا احاطہ کرتے ہیں: ورک سٹیشن پر ڈیبگنگ سے لے کر پیداوار میں نگرانی تک۔ ہر ٹول اپنا کام حل کرتا ہے اور مختلف منظرناموں کے لیے ڈیٹا فراہم کرتا ہے۔

ہر ٹول کا اپنا مقام ہے: StrictMode ابتدائی مراحل میں واضح خلاف ورزیاں پکڑتا ہے، Crashlytics صارفین کے درمیان حقیقی ANR تعدد دکھاتا ہے، اور adb bugreport پیچیدہ معاملات کے لیے سب سے مکمل تصویر فراہم کرتا ہے۔ مکمل کوریج کے لیے ان کو یکجا کریں۔

Firebase Performance Monitoring

Firebase Performance UI تھریڈ کے جوابی وقت کو ٹریک کرتا ہے اور مشتبہ طور پر طویل عملیات کے لیے خود بخود ٹریس بناتا ہے۔ اگر مرکزی تھریڈ 500 ms سے زیادہ بلاک ہو، تو Performance ذمہ دار طریقہ کے نام کے ساتھ ایک حسب ضرور ٹریس ریکارڈ کرتا ہے۔ یہ صارف کی شمولیت کے بغیر اور اہم ہونے سے پہلے ANR منظرناموں کا پتہ لگانے کی اجازت دیتا ہے۔

Firebase Crashlytics کے ساتھ انضمام ایک مکمل تصویر دیتا ہے: Performance ANR سے پہلے سستی دکھاتا ہے، اور Crashlytics منجمد ہونے کو دکھاتا ہے۔ Firebase Console میں ANR کی شرح 0.1% سے زیادہ ہونے پر الرٹس ترتیب دیں، اور آپ کو صارفین کی بڑے پیمانے پر شکایات سے پہلے نئے مسائل کے بارے میں اطلاعات موصول ہوں گی۔