Android-da ANR: bu nima, sabablari va bartaraf etish usullari

Android-da ANR nima

ANR (Application Not Responding) — ilova kiritishga javob berishni to‘xtatganda ishga tushadigan Android-da foydalanuvchini himoya qilish mexanizmidir. Tizim hodisalarni qayta ishlash vaqtini kuzatadi: agar BroadcastReceiver 10 soniya ichida onReceive-ni tugatmasa, Service 20 soniya ichida onCreate-dan qaytmasa va ContentProvider 15 soniya ichida javob bermasa — Android ANR yaratadi.

ANR foydalanuvchiga qanday ko‘rinadi

ANR yuz berganda, Android barcha oynalar ustida tizim dialogini ko‘rsatadi: «Ilova javob bermayapti. Uni yopish yoki kutish?». Foydalanuvchi ilovani yopishi yoki uning tiklanishini kutishi mumkin. Agar ANR tez-tez takrorlansa, foydalanuvchi ilovani o‘chiradi. Google Play reyting algoritmlarida ANR darajasini — ANR bilan sessiyalar foizini — hisobga oladi.

ANR va iOS-dagi muzlash o‘rtasidagi farq

iOS-da tizim dialogiga ega ANR analogi yo‘q. Buning o‘rniga Apple Watchdog-dan foydalanadi, u ilovani 0x8badf00d kodi bilan tugatadi. Foydalanuvchi dialog ko‘rmaydi — ilova oddiygina asosiy ekranga yopiladi. Bu ANR-ni Android-da foydalanuvchi uchun sezilarliroq qiladi, ammo diagnostika uchun tizimga ko‘proq ma’lumot beradi.

ANR ning asosiy sabablari

ANR tizim to‘rtta komponent turidan biri uchun vaqt chegarasini kuzatganda yuz beradi. Har bir komponentning o‘z vaqt chegarasi bor.

BroadcastReceiver-da bloklanish

BroadcastReceiver asosiy oqimda bajariladi. Agar onReceive sinxron tarmoq so‘rovi, ma’lumotlar bazasiga uzoq yozish operatsiyasi yoki blokirovkani kutsa — 10 soniyadan keyin ANR paydo bo‘ladi. Yechim: fon ishlovi uchun goAsync() va WorkManager-dan foydalaning. Odatdagi stsenariy — FCM dan Push bildirishnomasini olish va Room-da sinxron saqlash.

Service-da uzoq operatsiya

Service.onCreate va Service.onStartCommand 20 soniya chegarasiga ega. Agar xizmat asosiy oqimda og‘ir ishga tushirishni (kutubxonalarni yuklash, tarmoqdan konfiguratsiyani o‘qish) boshlasa — ANR muqarrar. Fon oqimida kafolatlangan bajarish uchun IntentService (eskirgan) yoki WorkManager-dan foydalaning.

Uzoq ishga tushirish bilan ContentProvider

ContentProvider.onCreate Application.onCreate chaqiruvidan oldin bajariladi va 15 soniya chegarasiga ega. Agar provayder ma’lumotlar bazasi migratsiyasi, lug‘atlarni yuklash yoki tarmoqdan SDK ishga tushirishni amalga oshirsa — bu ilova ishga tushirilganda ANRga sabab bo‘ladi. Yechim: lazy-ishga tushirish, og‘ir operatsiyalarni WorkManager-ga o‘tkazish.

• BroadcastReceiver — onReceive uchun 10 soniya; fon ishlovi uchun goAsync() dan foydalaning
• Service — onCreate/onStartCommand uchun 20 soniya; WorkManager yoki CoroutineWorker dan foydalaning
• ContentProvider — onCreate uchun 15 soniya; ishga tushirishni kechiktirilgan boshlash bilan Application.onCreate ga o‘tkazing
• UI oqimi — hodisalarni qayta ishlashsiz 5 soniya; 5 soniyadan ortiq har qanday bloklash ANRga sabab bo‘ladi

ANRni qanday diagnostika qilish kerak

Android tizim jurnallaridan maxsus kutubxonalargacha ANR tahlili uchun bir nechta vositalarni taqdim etadi.

traces.txt tahlili

Har bir ANRda Android /data/anr/traces.txt faylini ilovaning barcha oqimlari steklari bilan saqlaydi. «Main» oqimini toping — stekdagi oxirgi usul sababni ko‘rsatadi. Odatdagi namunalar: Thread.sleep(), InputStream.read(), BinderProxy.transact(). Faylni qurilmadan olish uchun superfoydalanuvchi huquqlari bilan adb dan foydalaning.

ANR hisobotlari bilan Firebase Crashlytics

Firebase Crashlytics avtomatik ravishda ANRlarni to‘playdi va ularni kuzatish bilan birga asboblar panelida ko‘rsatadi. Android 11+ uchun ANR hisobotlari asosiy oqimning to‘liq steklari bilan keladi. Integratsiya bog‘liqlikni qo‘shish va Application.onCreate da FirebaseApp ishga tushirishni talab qiladi.

Android Studio Profiler oqim kuzatuvi bilan

CPU Profiler Android Studio da ilova ishini kuzatishni yozib olish va qaysi usullar protsessor vaqtini olishini ko‘rish imkonini beradi. «Record with method traces»-ni yoqing va ANRga sabab bo‘lgan stsenariyni takrorlang. Vaqt shkalasida muzlash paytida asosiy oqimda qaysi usullar bajarilgani ko‘rinadi.

Android da ANR yig‘ish uchun Firebase Crashlytics integratsiyasi namunasi:

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

ANRni bartaraf etish usullari

ANRni bartaraf etish, birinchi navbatda, barcha uzoq operatsiyalarni asosiy oqimdan fon oqimlariga o‘tkazishdir. Har bir komponent turi uchun aniq texnikalarni ko‘rib chiqamiz.

Fon vazifalari uchun WorkManager dan foydalanish

WorkManager — Google tomonidan fon ishi uchun tavsiya etilgan yechim. U qurilma holatini hisobga olgan holda vazifaning fon oqimida bajarilishini kafolatlaydi. Service-dan farqli o‘laroq, WorkManager asosiy oqimni bloklamaydi va ilovani qayta ishga tushirishga chidamli. BroadcastReceiver uchun goAsync() dan foydalaning va natijani PendingResult-ni WorkManager-ga o‘tkazing.

To‘g‘ri dispetcherlar bilan Kotlin Coroutines

Barcha tarmoq so‘rovlarini, ma’lumotlar bazasi bilan ishlashni va fayl operatsiyalarini Dispatchers.IO bilan ishga tushiring. Asosiy oqim faqat UI-ni yangilashi kerak. Activity yo‘q qilinganda koroutinlarni avtomatik bekor qilish uchun viewModelScope-dan foydalaning. Har qanday kontekstda runBlocking() dan saqlaning — bu joriy oqimning sinxron bloklanishi.

ContentProvider ni Lazy-ishga tushirish

Agar ContentProvider uzoq ishga tushirishni amalga oshirsa, kechiktirilgan yuklash mexanizmidan foydalaning: darhol ma’lumot qaytaradigan provayder yarating va og‘ir ishga tushirishni WorkManager orqali kechikish bilan ishga tushiring. Bu tizim kechikishlarga eng sezgir bo‘lgan ilova ishga tushirilganda ANRning oldini oladi.

Android da goAsync bilan BroadcastReceiver dan to‘g‘ri foydalanish namunasi:

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

Ishlab chiqishda ANR profilaktikasi

ANR bilan kurashishning eng yaxshi usuli vositalar va arxitektura yechimlari orqali ularni ishlab chiqish bosqichida oldini olishdir.

Asosiy oqim bloklanishlarini aniqlash uchun StrictMode

StrictMode detectNetwork() va detectDiskReads()/detectDiskWrites() siyosatlari yoqilgan holda ishlab chiqish bosqichida potentsial ANRlarni aniqlaydi. Debug yig‘ilishida penaltyDeath-ni o‘rnating — har qanday buzilish darhol ishdan chiqishga olib keladi va dasturchi muammoni tasdiqlashdan oldin ko‘radi.

Ishlab chiqarish ko‘rsatkichlari uchun Firebase Performance Monitoring

Firebase Performance asosiy operatsiyalarning bajarilish vaqtini kuzatadi va qaysi stsenariylar ANR chegarasidan oshishini ko‘rsatadi. Har bir ekran va tarmoq so‘rovi uchun maxsus kuzatuvlarni sozlang. Bajarilish vaqti 3 soniyadan oshsa — bu optimallashtirishni talab qiladigan potentsial ANRdir.

Tarmoq va disk kechikishlari bilan sinov

Sekin shartlarni simulyatsiya qiling: iOS yoki Android Emulator-da Network Link Conditioner orqali tarmoq tezligini cheklang. Sekin xotira emulyatsiyasi orqali diskdan o‘qishni sekinlashtiring. ANR ko‘pincha aynan shunday sharoitlarda namoyon bo‘ladi, dasturchining tez qurilmalarida ko‘rinmaydi.

• BroadcastReceiver — 1 soniyadan ortiq ishlov uchun har doim goAsync() dan foydalaning
• Service — fon dispetcheri bilan WorkManager yoki CoroutineWorker bilan almashtiring
• ContentProvider — onCreate da tarmoq va ma’lumotlar bazasidan saqlaning, WorkManager bilan lazy-init dan foydalaning
• UI oqimi — Debug da penaltyDeath bilan StrictMode, ishlab chiqarish monitoringi uchun Firebase Performance