ANR i Android: vad det är, orsaker och åtgärdsmetoder

Vad är ANR i Android

ANR (Application Not Responding) — är en användarskyddsmekanism i Android som aktiveras när applikationen slutar svara på inmatning. Systemet övervakar bearbetningstiden för händelser: om BroadcastReceiver inte slutför onReceive inom 10 sekunder, Service inte återvänder från onCreate inom 20 sekunder, och ContentProvider inte svarar inom 15 sekunder — genererar Android ett ANR.

Hur ANR ser ut för användaren

När ANR inträffar visar Android en systemdialogruta ovanför alla fönster: "Applikationen svarar inte. Stänga eller vänta?". Användaren kan stänga applikationen eller vänta på dess återställning. Om ANR upprepas ofta tar användaren bort applikationen. Google Play beaktar ANR-frekvensen — andelen sessioner med ANR — i rankningsalgoritmerna.

Skillnad mellan ANR och frysningar på iOS

På iOS finns ingen motsvarighet till ANR med systemdialogruta. Istället använder Apple Watchdog, som avslutar applikationsprocessen med kod 0x8badf00d. Användaren ser ingen dialogruta — applikationen stängs helt enkelt till hemskärmen. Detta gör ANR på Android mer synligt för användaren, men ger systemet mer information för diagnostik.

Huvudorsaker till ANR

ANR inträffar när systemet övervakar timeout för en av fyra komponenttyper. Varje komponent har sin egen tidsgräns.

Blockering i BroadcastReceiver

BroadcastReceiver körs i huvudtråden. Om onReceive startar en synkron nätverksförfrågan, en lång skrivoperation till databasen eller väntar på en blockering — uppstår ANR efter 10 sekunder. Lösning: använd goAsync() och WorkManager för bakgrundsbearbetning. Typiskt scenario — ta emot Push-meddelande från FCM och synkron spara i Room.

Lång operation i Service

Service.onCreate och Service.onStartCommand har en gräns på 20 sekunder. Om tjänsten startar tung initialisering (ladda bibliotek, läsa konfiguration från nätverket) i huvudtråden — är ANR oundvikligt. Använd IntentService (föråldrad) eller WorkManager för garanterad exekvering i bakgrundstråden.

ContentProvider med lång initialisering

ContentProvider.onCreate körs före anropet till Application.onCreate och har en gräns på 15 sekunder. Om leverantören utför databasmigrering, laddning av ordlistor eller SDK-initialisering från nätverket — orsakar detta ANR vid applikationsstart. Lösning: lazy-initialisering, flytta tunga operationer till WorkManager.

• BroadcastReceiver — 10 sekunder för onReceive; använd goAsync() för bakgrundsbearbetning
• Service — 20 sekunder för onCreate/onStartCommand; använd WorkManager eller CoroutineWorker
• ContentProvider — 15 sekunder för onCreate; flytta initialiseringen till Application.onCreate med fördröjd start
• UI-tråd — 5 sekunder utan händelsebearbetning; varje blockering längre än 5 sekunder orsakar ANR

Hur man diagnostiserar ANR

Android tillhandahåller flera verktyg för ANR-analys: från systemloggar till specialiserade bibliotek.

Analys av traces.txt

Vid varje ANR sparar Android filen /data/anr/traces.txt med en dump av stackarna för alla applikationens trådar. Hitta tråden "main" — den sista metoden i stacken indikerar orsaken. Typiska mönster: Thread.sleep(), InputStream.read(), BinderProxy.transact(). För att extrahera filen från enheten, använd adb med superanvändarrättigheter.

Firebase Crashlytics med ANR-rapporter

Firebase Crashlytics samlar automatiskt in ANR och visar dem på instrumentpanelen tillsammans med spårning. För Android 11+ kommer ANR-rapporter med full stack av huvudtråden. Integration kräver att ett beroende läggs till och initialisering av FirebaseApp i Application.onCreate.

Android Studio Profiler med trådspårning

CPU Profiler i Android Studio låter dig spela in en spårning av applikationens arbete och se vilka metoder som tar CPU-tid. Aktivera "Record with method traces" och återskapa scenariot som orsakar ANR. På tidslinjen kommer det att synas vilka metoder som kördes i huvudtråden vid frysningsögonblicket.

Exempel på Firebase Crashlytics-integration för att samla in ANR på Android:

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

Metoder för att åtgärda ANR

Att åtgärda ANR innebär främst att flytta alla långa operationer från huvudtråden till bakgrundstrådar. Låt oss titta på specifika tekniker för varje komponenttyp.

Använda WorkManager för bakgrundsuppgifter

WorkManager — Googles rekommenderade lösning för bakgrundsarbete. Det garanterar exekvering av uppgiften i bakgrundstråden med hänsyn till enhetens tillstånd. Till skillnad från Service blockerar WorkManager inte huvudtråden och är tolerant mot omstart av applikationen. För BroadcastReceiver, använd goAsync() och skicka resultatet PendingResult till WorkManager.

Kotlin Coroutines med rätt avsändare

Starta alla nätverksförfrågningar, databasarbete och filoperationer med Dispatchers.IO. Huvudtråden bör bara uppdatera UI. Använd viewModelScope för automatisk annullering av coroutines när Activity förstörs. Undvik runBlocking() i något sammanhang — detta är en synkron blockering av den aktuella tråden.

Lazy-initialisering av ContentProvider

Om ContentProvider utför lång initialisering, använd en mekanism för fördröjd laddning: skapa en leverantör som omedelbart returnerar data, och starta den tunga initialiseringen via WorkManager med fördröjning. Detta förhindrar ANR vid applikationsstart, när systemet är mest känsligt för fördröjningar.

Exempel på korrekt användning av BroadcastReceiver med goAsync i 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()
    }
}

Förebyggande av ANR i utveckling

Det bästa sättet att bekämpa ANR är att förhindra deras uppkomst i utvecklingsfasen genom verktyg och arkitekturlösningar.

StrictMode för att upptäcka blockering av huvudtråden

StrictMode med aktiverade policyer detectNetwork() och detectDiskReads()/detectDiskWrites() upptäcker potentiella ANR i utvecklingsfasen. I Debug-build, ställ in penaltyDeath — varje överträdelse leder till en omedelbar krasch, och utvecklaren ser problemet före commit.

Firebase Performance Monitoring för produktionsmätvärden

Firebase Performance övervakar exekveringstiden för nyckeloperationer och visar vilka scenarier som överskrider ANR-tröskeln. Konfigurera anpassad spårning för varje skärm och nätverksförfrågan. Om exekveringstiden överstiger 3 sekunder — är detta en potentiell ANR som kräver optimering.

Testning med nätverks- och diskfördröjningar

Simulera långsamma förhållanden: begränsa nätverkshastigheten via Network Link Conditioner på iOS eller Android Emulator. Sakta ner läsning från disk genom emulering av långsamt minne. ANR uppträder ofta just under sådana förhållanden, på utvecklarens snabba enheter är de inte synliga.

• BroadcastReceiver — använd alltid goAsync() för bearbetning längre än 1 sekund
• Service — ersätt med WorkManager eller CoroutineWorker med bakgrundsavsändare
• ContentProvider — undvik nätverk och databas i onCreate, använd lazy-init med WorkManager
• UI-tråd — StrictMode med penaltyDeath i Debug, Firebase Performance för produktionsövervakning