Android dasturlashda ANR — bu nima, sabablari va tuzatish usullari

ANR nima

ANR (Application Not Responding) — bu Android operatsion tizimining dialog oynasi bo‘lib, ilova foydalanuvchi kiritishiga javob berishni to‘xtatganda paydo bo‘ladi. Tizim InputDispatcher orqali hodisalarni qayta ishlash vaqtini kuzatadi: agar teginish yoki tugma bosilishi 5 soniya ichida qayta ishlanmasa, Android ilovani yopish yoki kutish taklifi bilan dialogni ko‘rsatadi.

ANR mexanizmi foydalanuvchi tajribasini muzlab qolgan ilovalardan himoya qiladi. Android bitta ilovaga butun tizimni bloklashiga ruxsat bermaydi — Desktop OTlardan farqli o‘laroq, mobil platforma hodisalarni qayta ishlash vaqtini majburiy cheklaydi. BroadcastReceiver 10 soniya, foreground xizmati esa 20 soniya chegarasiga ega.

ANR kodda istisno EMAS — bu Linux jarayonlari darajasida tizim mexanizmi. Android jarayonga SIGQUIT signalini yuboradi, shundan so‘ng tizim barcha oqimlarning chaqiruv stekini traces.txt faylida saqlaydi. Dasturchi ANRni catch-istisnosi sifatida emas, balki ilova qayta ishga tushgandan keyin hisobot sifatida oladi. Android 11+ da ApplicationExitInfo API si paydo bo‘ldi, bu jarayonning tugash sababini, jumladan ANRni dasturiy ravishda olish imkonini beradi — bu traces.txt ni qo‘lda pars qilmasdan statistika to‘plashni osonlashtiradi.

ANRning asosiy sabablari

Besh toifa operatsiyalar Android ilovalarida barqaror ANRga olib keladi. Ularning har biri asosiy oqimni bloklaydi, tizimga kirish hodisalarini qayta ishlash va ekranni qayta chizishga to‘sqinlik qiladi.

Asosiy oqimda tarmoq so‘rovlari

Sinxron HTTP so‘rovlari UI oqimida bajariladi — bu yangi boshlovchi dasturchilarda ANRning eng keng tarqalgan sababi. Hatto serverga tezkor so‘rov 1–3 soniya davom etishi mumkin, zaif ulanishda esa 30 soniya va undan ko‘p. Android API 11 dan boshlab asosiy oqimda tarmoq operatsiyalarini ochiq taqiqlaydi, NetworkOnMainThreadException ni chiqaradi.

Asinxron chaqiruvlar uchun Coroutines yoki RxJava dan foydalaning. Dispatchers.IO dispetcheri bilan korutinlar so‘rovni fon oqimida bajaradi, natijani esa Dispatchers.Main orqali asosiy oqimga uzatadi. Bu UI oqimining tarmoq operatsiyalari bilan bloklanishini butunlay yo‘q qiladi.

fun fetchUserData() {
    CoroutineScope(Dispatchers.Main).launch {
        val result = withContext(Dispatchers.IO) {
            api.getUserData() // fon operatsiyasi
        }
        updateUI(result) // asosiy oqimdagi natija
    }
}

UI oqimida intensiv hisoblashlar

Katta ma‘lumot massivlarini qayta ishlash, JSON yoki XML pars qilish, asosiy oqimda bitmap bilan to‘g‘ridan-to‘g‘ri ishlash — ANRning chastota bo‘yicha ikkinchi sababi. Hatto 300 millisoniya uzluksiz UI oqimi ishi hodisa aylanishiga qaytmasdan sezilarli kechikishga olib keladi, 5 soniyalik chegara esa ANR sifatida qayd etiladi.

WorkManager va fon xizmatlari og‘ir hisoblashlarni asosiy oqimdan olib tashlash uchun mo‘ljallangan. UI ni bloklamasdan ma‘lumotlarni qismlarda uzatish uchun AsyncTask (eskirgan), ListenableFuture yoki Kotlin Flow dan foydalaning.

Sinkronizatsiya bloklanishlari va Deadlock

Deadlock ikki oqim blokirovkalarni ushlab, bir-birini kutganda yuzaga keladi. Agar oqimlardan biri asosiy bo‘lsa, tizim 5 soniyadan so‘ng ANRni qayd etadi. UI oqimidan chaqirilgan Thread.join(), CountDownLatch.await() va synchronized bloklari bloklanish xavfini keltiradi.

Asosiy oqimda har qanday bloklovchi operatsiyalardan saqlaning. synchronized o‘rniga ConcurrentHashMap, Thread.join() o‘rniga async/await bilan korutinlardan foydalaning. Bu qoida Androiddagi har qanday til uchun amal qiladi: Java, Kotlin yoki JNI orqali C++.

BroadcastReceiverning uzoq ishlashi

BroadcastReceiver sukut bo‘yicha asosiy oqimda ishlaydi. Agar onReceive() 10 soniyadan ortiq band bo‘lsa, Android ANRni ko‘rsatadi. Ma‘lumotlar bazasidan yoki tarmoqdan onReceive ichida ma‘lumot yuklash muzlashga kafolatlangan yo‘ldir.

BroadcastReceiver ichida fon oqimiga o‘tish uchun goAsync() yoki getBackgroundBroadcastReceiver() bilan registerReceiver dan foydalaning. Bu UI ni bloklamasdan hodisalarni qayta ishlash imkonini beradi.

Asosiy oqimda ContentProvider va SQLite

UI oqimida ContentProvider ga og‘ir so‘rovlar yoki SQLite bilan to‘g‘ridan-to‘g‘ri ishlash — kamroq ravshan, ammo tez-tez uchraydigan ANR sababi. Ma‘lumotlar bazasining migratsiyasi yoki minglab yozuvlarni ommaviy kiritishda bajarilish vaqti 5 soniyalik chegaradan oshib ketishi mumkin.

Barcha ma‘lumotlar bazasi operatsiyalarini suspend funksiyalari bilan Room orqali fon oqimlariga o‘tkazing. Room so‘rovning asosiy oqimda bajarilmasligini avtomatik tekshiradi va buzilishda istisno chiqaradi.

ANRni qanday aniqlash mumkin

ANR diagnostikasi oddiy istisnolarni tuzatishdan farq qiladi — ANRni try-catch da ushlay olmaysiz. Asosiy ma‘lumot manbai Android muzlash vaqtida yaratadigan traces.txt faylidir.

traces.txt ANR vaqtida ilovaning barcha oqimlarining chaqiruv stekini o‘z ichiga oladi. Haqiqiy qurilmadan faylni o‘qish uchun so‘nggi vaqtdagi barcha ANRlarni o‘z ichiga olgan to‘liq tizim hisobotini yig‘uvchi adb bugreport buyrug‘ini bajaring. Emulyator uchun fayl /data/anr/traces.txt da mavjud. Chaqiruv steki bloklanish vaqtida asosiy oqimda qaysi metod bajarilayotganini ko‘rsatadi.

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

Google Play Console yig‘ilgan hisobotlar va xato chastotalari bilan ANR & Crash bo‘limini taqdim etadi. Har bir ANR uchun chaqiruv steki va qurilmalar bo‘yicha statistika ko‘rsatiladi: model, Android versiyasi, mintaqa. Bu muayyan qurilmalar yoki tizim versiyalariga bog‘liq bo‘lgan ANRlarni aniqlash imkonini beradi.

Android Studio 2021 yildan profilerda ANR Watchdog ni o‘z ichiga oladi. Asosiy oqim chegara vaqtidan ortiq javob bermasa, avtomatik ravishda oqimlar dumpini yozib oladi. Asbob hodisalarning vaqt chizig‘ini ko‘rsatadi: qaysi operatsiyalar ishga tushirilgan, qaysi metodlar bajarilgan va bloklanish qaysi bosqichda sodir bo‘lgan.

ANRning oldini olish

ANR profilaktikasi bir asosiy qoidaga asoslanadi: asosiy oqim faqat UI hodisalarini qayta ishlashi kerak. 16 millisoniyadan (bir kadr vaqti) ortiq davom etadigan har qanday operatsiya fon oqimida bajarilishi kerak.

StrictMode — avtomatik tekshirish

StrictMode — rivojlanish bosqichida potentsial ANRlarni aniqlash uchun Android ichki vositasi. Uni disk va tarmoq operatsiyalari uchun bayroqlar bilan Application.onCreate() da yoqing. Buzilishda StrictMode istisno chiqaradi yoki logcat ga yozadi.

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

Asinxron na‘munalar: Coroutines va RxJava

Kotlin Coroutines — zamonaviy Android ilovalarida asinxron ishning standart usuli. Asosiy qabul: kirish-chiqish operatsiyalari Dispatchers.IO da bajariladi, natija UI yangilash uchun Dispatchers.Main ga uzatiladi. Flow stsenariylari uchun CPU intensiv vazifalar uchun Dispatchers.Default dan foydalaning.

RxJava eski loyihalarda mashhur bo‘lib qolmoqda. subscribeOn(Schedulers.io()) va observeOn(AndroidSchedulers.mainThread()) — ANRning oldini olish uchun minimal to‘plam. Xuddi shu qoida: hech qanday Observable yoki Flowable asosiy oqimdan ma‘lumotlarni emit qilmasligi kerak.

Ishlab chiqarishda monitoring

Firebase Crashlytics SDK 18.4.0 versiyasidan ANR monitoringini qutidan chiqqandek qo‘llab-quvvatlaydi. Android 11+ uchun Crashlytics tugashning aniq sababini ta‘minlovchi tizim API ApplicationExitInfo dan foydalanadi: ANR, Crash yoki tizim tomonidan o‘ldirish. Kontekstli tahlil uchun ekran va holat parametrlari bilan maxsus kalitlarni yoqing.

ANRni aniqlash vositalari

Besh vosita ANR bilan ishlashning barcha bosqichlarini qamrab oladi: ish stansiyasida tuzatishdan ishlab chiqarishdagi monitoringgacha. Har bir vosita o‘z vazifasini hal qiladi va turli stsenariylar uchun ma‘lumotlarni taqdim etadi.

Har bir vosita o‘z o‘rniga ega: StrictMode dastlabki bosqichlarda ochiq buzilishlarni ushlaydi, Crashlytics foydalanuvchilarda ANRning haqiqiy chastotasini ko‘rsatadi, adb bugreport esa murakkab holatlar uchun eng to‘liq tasvirni beradi. To‘liq qamrov uchun ularni birlashtiring.

Firebase Performance Monitoring

Firebase Performance UI oqimining javob vaqtini kuzatadi va shubhali uzoq operatsiyalar uchun avtomatik treyslar yaratadi. Agar asosiy oqim 500 ms dan ortiq bloklansa, Performance aybdor metod nomi bilan maxsus treysni qayd etadi. Bu ANR stsenariylarini foydalanuvchi ishtirokisiz va ular kritik bo‘lishidan oldin aniqlash imkonini beradi.

Firebase Crashlytics bilan integratsiya to‘liq tasvirni beradi: Performance ANRdan oldingi sekinlashishlarni, Crashlytics esa muzlash faktini ko‘rsatadi. Firebase Console da ANR rate 0.1% dan yuqori hodisaga ogohlantirishlarni sozlang va foydalanuvchilarning ommaviy shikoyatlaridan oldin yangi muammolar haqida xabarlar olasiz.