ANR Androidon: mi ez, okai és elhárítási módszerek

Mi az ANR Androidon

ANR (Application Not Responding) — egy felhasználóvédelmi mechanizmus Androidon, amely akkor aktiválódik, amikor az alkalmazás leáll a bevitelre való reagálással. A rendszer nyomon követi az események feldolgozási idejét: ha a BroadcastReceiver nem fejezi be az onReceive-t 10 másodpercen belül, a Service nem tér vissza az onCreate-ből 20 másodpercen belül, és a ContentProvider nem válaszol 15 másodpercen belül — az Android ANR-t generál.

Hogyan néz ki az ANR a felhasználó számára

Amikor ANR történik, az Android egy rendszer-párbeszédablakot jelenít meg az összes ablak fölött: „Az alkalmazás nem válaszol. Bezárja vagy vár?”. A felhasználó bezárhatja az alkalmazást, vagy várhat a helyreállására. Ha az ANR gyakran ismétlődik, a felhasználó törli az alkalmazást. A Google Play figyelembe veszi az ANR-arányt — az ANR-rel rendelkező munkamenetek százalékát — a rangsorolási algoritmusokban.

Különbség az ANR és az iOS-beli lefagyások között

Az iOS-en nincs az ANR-nek megfelelő rendszer-párbeszédablakos megoldás. Ehelyett az Apple Watchdog-ot használ, amely 0x8badf00d kóddal fejezi be az alkalmazás folyamatát. A felhasználó nem lát párbeszédablakot — az alkalmazás egyszerűen bezáródik a főképernyőre. Ez az ANR-t Androidon jobban láthatóvá teszi a felhasználó számára, de több információt ad a rendszernek a diagnosztikához.

Az ANR fő okai

Az ANR akkor következik be, amikor a rendszer időtúllépést figyel a négy komponenstípus egyikénél. Minden komponensnek saját időkorlátja van.

Blokkolás a BroadcastReceiver-ben

BroadcastReceiver a fő szálon fut. Ha az onReceive szinkron hálózati kérést, hosszú adatbázis-írási műveletet indít, vagy blokkolásra vár — 10 másodperc után ANR lép fel. Megoldás: használjon goAsync()-t és WorkManager-t a háttérfeldolgozáshoz. Tipikus forgatókönyv — Push-értesítés fogadása az FCM-től és szinkron mentés a Room-ba.

Hosszú művelet a Service-ben

Service.onCreate és Service.onStartCommand 20 másodperces korláttal rendelkezik. Ha a szolgáltatás nehéz inicializálást (könyvtárak betöltése, konfiguráció olvasása a hálózatról) indít a fő szálon — az ANR elkerülhetetlen. Használjon IntentService-t (elavult) vagy WorkManager-t a garantált háttérszálon történő végrehajtáshoz.

ContentProvider hosszú inicializálással

ContentProvider.onCreate az Application.onCreate meghívása előtt fut, és 15 másodperces korlátja van. Ha a provider adatbázis-migrációt, szótárak betöltését vagy SDK-inicializálást végez a hálózatról — ez ANR-t okoz az alkalmazás indításakor. Megoldás: lusta inicializálás, nehéz műveletek áthelyezése a WorkManager-be.

• BroadcastReceiver — 10 másodperc az onReceive-re; használjon goAsync()-t a háttérfeldolgozáshoz
• Service — 20 másodperc az onCreate/onStartCommand-re; használjon WorkManager-t vagy CoroutineWorker-t
• ContentProvider — 15 másodperc az onCreate-re; helyezze át az inicializálást az Application.onCreate-be késleltetett indítással
• UI szál — 5 másodperc eseményfeldolgozás nélkül; bármely 5 másodpercnél hosszabb blokkolás ANR-t okoz

Hogyan diagnosztizáljuk az ANR-t

Az Android több eszközt kínál az ANR elemzéséhez: a rendszernaplóktól a speciális könyvtárakig.

A traces.txt elemzése

Minden ANR-nél az Android elmenti a /data/anr/traces.txt fájlt az alkalmazás összes szálának veremkiírásával. Keresse meg a „main” szálat — a veremben lévő utolsó metódus jelzi az okot. Tipikus minták: Thread.sleep(), InputStream.read(), BinderProxy.transact(). A fájl eszközről történő kinyeréséhez használjon adb-t rendszergazdai jogosultságokkal.

Firebase Crashlytics ANR-jelentésekkel

Firebase Crashlytics automatikusan gyűjti az ANR-eket, és megjeleníti azokat a műszerfalon nyomkövetéssel együtt. Android 11+ esetén az ANR-jelentések a fő szál teljes vermével érkeznek. Az integrációhoz függőség hozzáadása és a FirebaseApp inicializálása szükséges az Application.onCreate-ben.

Android Studio Profiler szálkövetéssel

CPU Profiler az Android Studio-ban lehetővé teszi az alkalmazás működésének nyomkövetését, és annak megtekintését, hogy mely metódusok foglalják a CPU-időt. Kapcsolja be a „Record with method traces” opciót, és reprodukálja az ANR-t okozó forgatókönyvet. Az idővonalon látható lesz, hogy mely metódusok futottak a fő szálon a lefagyás pillanatában.

Példa a Firebase Crashlytics integrációjára ANR gyűjtéséhez Androidon:

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

Az ANR elhárításának módszerei

Az ANR elhárítása elsősorban az összes hosszú művelet áthelyezését jelenti a fő szálból a háttérszálakba. Tekintsük át a konkrét technikákat az egyes komponenstípusokhoz.

WorkManager használata háttérfeladatokhoz

WorkManager — a Google által ajánlott megoldás háttérmunkához. Garantálja a feladat végrehajtását a háttérszálon, figyelembe véve az eszköz állapotát. A Service-szel ellentétben a WorkManager nem blokkolja a fő szálat, és ellenálló az alkalmazás újraindításával szemben. BroadcastReceiver esetén használjon goAsync()-t, és adja át az eredmény PendingResult-ot a WorkManager-nek.

Kotlin Coroutines a megfelelő diszpécserekkel

Indítson minden hálózati kérést, adatbázis-műveletet és fájloperációt Dispatchers.IO-val. A fő szálnak csak a UI-t kell frissítenie. Használjon viewModelScope-t a coroutine-ok automatikus megszakításához az Activity megsemmisülésekor. Kerülje a runBlocking() használatát bármilyen kontextusban — ez az aktuális szál szinkron blokkolása.

ContentProvider lusta inicializálása

Ha a ContentProvider hosszú inicializálást végez, használjon késleltetett betöltési mechanizmust: hozzon létre egy providert, amely azonnal visszaadja az adatokat, és a nehéz inicializálást indítsa el WorkManager-en keresztül késleltetéssel. Ez megakadályozza az ANR-t az alkalmazás indításakor, amikor a rendszer a legérzékenyebb a késleltetésekre.

Példa a BroadcastReceiver helyes használatára goAsync-val Androidon:

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 megelőzése fejlesztés közben

A legjobb mód az ANR elleni küzdelemre az, ha megelőzzük azok megjelenését a fejlesztési szakaszban eszközök és architekturális megoldások segítségével.

StrictMode a fő szál blokkolásainak felismeréséhez

StrictMode a detectNetwork() és detectDiskReads()/detectDiskWrites() szabályzatok bekapcsolásával felismeri a potenciális ANR-eket a fejlesztési szakaszban. Debug buildben állítsa be a penaltyDeath-ot — bármely megsértés azonnali összeomláshoz vezet, és a fejlesztő látja a problémát a commit előtt.

Firebase Performance Monitoring éles metrikákhoz

Firebase Performance nyomon követi a kulcsfontosságú műveletek végrehajtási idejét, és megmutatja, mely forgatókönyvek lépik túl az ANR-küszöböt. Állítson be egyéni nyomkövetéseket minden képernyőhöz és hálózati kéréshez. Ha a végrehajtási idő meghaladja a 3 másodpercet — ez egy potenciális ANR, amely optimalizálást igényel.

Tesztelés hálózati és lemez-késleltetésekkel

Szimuláljon lassú körülményeket: korlátozza a hálózati sebességet a Network Link Conditioner segítségével iOS-en vagy Android Emulatoron. Lassítsa a lemezről való olvasást lassú memória emulációjával. ANR gyakran pont ilyen körülmények között jelentkezik, a fejlesztő gyors eszközein nem látható.

• BroadcastReceiver — mindig használjon goAsync()-t az 1 másodpercnél hosszabb feldolgozáshoz
• Service — cserélje le WorkManager-re vagy CoroutineWorker-re háttér-diszpécserrel
• ContentProvider — kerülje a hálózatot és adatbázist az onCreate-ben, használjon lazy-init-et WorkManager-rel
• UI szál — StrictMode penaltyDeath-tal Debug-ban, Firebase Performance az éles megfigyeléshez