ANR у Android-у: шта је то, узроци и методе отклањања

Шта је ANR у Android-у

ANR (Application Not Responding) — механизам заштите корисника у Android-у који се активира када апликација престане да реагује на унос. Систем прати време обраде догађаја: ако BroadcastReceiver не заврши onReceive у 10 секунди, Service се не врати из onCreate за 20 секунди, а ContentProvider не одговори за 15 секунди — Android генерише ANR.

Како ANR изгледа за корисника

Када настане ANR, Android приказује системски дијалог изнад свих прозора: „Апликација не реагује. Затворити је или сачекати?”. Корисник може да затвори апликацију или сачека њен опоравак. Ако се ANR често понавља, корисник брише апликацију. Google Play узима у обзир ANR стопу — проценат сесија са ANR-ом — у алгоритмима рангирања.

Разлика између ANR-а и замрзавања на iOS-у

На iOS-у не постоји аналог ANR-а са системским дијалогом. Уместо тога, Apple користи Watchdog, који завршава процес апликације кодом 0x8badf00d. Корисник не види дијалог — апликација се једноставно затвара на главни екран. То чини ANR на Android-у видљивијим за корисника, али даје систему више информација за дијагностику.

Основни узроци ANR-а

ANR настаје када систем прати тајмаут за једну од четири врсте компоненти. Свака компонента има своје временско ограничење.

Блокирање у BroadcastReceiver-у

BroadcastReceiver се извршава у главној нити. Ако onReceive покрене синхрони мрежни захтев, дугу операцију уписа у базу или чека на блокаду — после 10 секунди настаје ANR. Решење: користите goAsync() и WorkManager за обраду у позадини. Типичан сценариј — примање Push обавештења од FCM-а и синхроно чување у Room-у.

Дуга операција у Service-у

Service.onCreate и Service.onStartCommand имају лимит од 20 секунди. Ако сервис покреће тешку иницијализацију (учитавање библиотека, читање конфигурације из мреже) у главној нити — ANR је неизбежан. Користите IntentService (застарео) или WorkManager за гарантовано извршење у позадинској нити.

ContentProvider са дугом иницијализацијом

ContentProvider.onCreate се извршава пре позива Application.onCreate и има лимит од 15 секунди. Ако провајдер врши миграцију базе, учитавање речника или иницијализацију SDK-а из мреже — то изазива ANR при покретању апликације. Решење: lazy-иницијализација, пребацивање тешких операција у WorkManager.

• BroadcastReceiver — 10 секунди за onReceive; користите goAsync() за позадинску обраду
• Service — 20 секунди за onCreate/onStartCommand; користите WorkManager или CoroutineWorker
• ContentProvider — 15 секунди за onCreate; преместите иницијализацију у 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 са суперкорисничким правима.

Firebase Crashlytics са ANR извештајима

Firebase Crashlytics аутоматски прикупља ANR и приказује их на контролној табли заједно са трасирањем. За Android 11+, ANR извештаји стижу са комплетним стеком главне нити. Интеграција захтева додавање зависности и иницијализацију FirebaseApp у Application.onCreate.

Android Studio Profiler са трасирањем нити

CPU Profiler у Android Studio-у омогућава снимање трасирања рада апликације и увид у то који методи заузимају процесорско време. Укључите „Record with method traces” и репродукујте сценариј који изазива ANR. На временској линији ће бити видљиво који су се методи извршавали у главној нити у тренутку замрзавања.

Пример интеграције Firebase Crashlytics-а за прикупљање ANR-а на Android-у:

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 са правим диспечерима

Покрећите све мрежне захтеве, рад са базом и операције са датотекама са Dispatchers.IO. Главна нит треба само да ажурира UI. Користите viewModelScope за аутоматско отказивање корутина при уништењу Activity-ја. Избегавајте runBlocking() у било ком контексту — то је синхроно блокирање тренутне нити.

Lazy-иницијализација ContentProvider-а

Ако ContentProvider врши дугу иницијализацију, користите механизам одложеног учитавања: направите провајдер који враћа податке одмах, а тешку иницијализацију покрените кроз WorkManager са закашњењем. Ово спречава ANR при покретању апликације, када је систем најосетљивији на кашњења.

Пример правилног коришћења BroadcastReceiver-а са goAsync у Android-у:

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 за откривање блокирања главне нити

StrictMode са укљученим политикама detectNetwork() и detectDiskReads()/detectDiskWrites() открива потенцијалне ANR у фази развоја. У Debug верзији подесите penaltyDeath — свако кршење ће довести до тренутног пада, а програмер ће видети проблем пре комитовања.

Firebase Performance Monitoring за производне метрике

Firebase Performance прати време извршења кључних операција и показује који сценарији прелазе праг ANR-а. Подесите прилагођена трасирања за сваки екран и мрежни захтев. Ако време извршења прелази 3 секунде — то је потенцијални ANR који захтева оптимизацију.

Тестирање са кашњењима мреже и диска

Симулирајте споре услове: ограничите брзину мреже преко Network Link Conditioner-а на iOS-у или Android Emulator-у. Успорите читање са диска кроз емулацију споре меморије. ANR се често појављује управо у таквим условима, на брзим уређајима програмера није видљив.

• BroadcastReceiver — увек користите goAsync() за обраду дужу од 1 секунде
• Service — замените WorkManager-ом или CoroutineWorker-ом са позадинским диспечером
• ContentProvider — избегавајте мрежу и базу у onCreate, користите lazy-init са WorkManager-ом
• UI нит — StrictMode са penaltyDeath у Debug, Firebase Performance за производни мониторинг