ANR in Android: wat is het, oorzaken en oplossingen

Wat is ANR in Android

ANR (Application Not Responding) — is een gebruikersbeschermingsmechanisme in Android dat wordt geactiveerd wanneer een app stopt met reageren op invoer. Het systeem houdt de verwerkingstijd van gebeurtenissen bij: als BroadcastReceiver onReceive niet binnen 10 seconden voltooit, Service niet terugkeert van onCreate binnen 20 seconden, en ContentProvider niet reageert binnen 15 seconden — genereert Android een ANR.

Hoe ANR eruitziet voor de gebruiker

Wanneer ANR optreedt, toont Android een systeemdialoogvenster boven alle vensters: "App reageert niet. Sluiten of wachten?". De gebruiker kan de app sluiten of wachten op herstel. Als ANR vaak voorkomt, verwijdert de gebruiker de app. Google Play houdt rekening met het ANR-percentage — het percentage sessies met ANR — in de rangschikkingsalgoritmen.

Verschil tussen ANR en vastlopers op iOS

Op iOS bestaat geen equivalent van ANR met een systeemdialoogvenster. In plaats daarvan gebruikt Apple Watchdog, dat het app-proces beëindigt met code 0x8badf00d. De gebruiker ziet geen dialoogvenster — de app wordt gewoon naar het startscherm gesloten. Dit maakt ANR op Android zichtbaarder voor de gebruiker, maar geeft het systeem meer informatie voor diagnose.

Belangrijkste oorzaken van ANR

ANR treedt op wanneer het systeem een time-out bijhoudt voor een van de vier componenttypen. Elk onderdeel heeft zijn eigen tijdslimiet.

Blokkering in BroadcastReceiver

BroadcastReceiver wordt uitgevoerd in de hoofdthread. Als onReceive een synchroon netwerkverzoek, een lange schrijfbewerking naar de database of wachten op een blokkering start — treedt na 10 seconden ANR op. Oplossing: gebruik goAsync() en WorkManager voor verwerking op de achtergrond. Typisch scenario — ontvangen van een Push-melding van FCM en synchroon opslaan in Room.

Lange operatie in Service

Service.onCreate en Service.onStartCommand hebben een limiet van 20 seconden. Als de service een zware initialisatie start (laden van bibliotheken, lezen van configuratie uit het netwerk) in de hoofdthread — is ANR onvermijdelijk. Gebruik IntentService (verouderd) of WorkManager voor gegarandeerde uitvoering in een achtergrondthread.

ContentProvider met lange initialisatie

ContentProvider.onCreate wordt uitgevoerd vóór de aanroep van Application.onCreate en heeft een limiet van 15 seconden. Als de provider databasemigratie, het laden van woordenboeken of SDK-initialisatie via het netwerk uitvoert — veroorzaakt dit ANR bij het starten van de app. Oplossing: lazy-initialisatie, zware operaties verplaatsen naar WorkManager.

• BroadcastReceiver — 10 seconden voor onReceive; gebruik goAsync() voor achtergrondverwerking
• Service — 20 seconden voor onCreate/onStartCommand; gebruik WorkManager of CoroutineWorker
• ContentProvider — 15 seconden voor onCreate; verplaats initialisatie naar Application.onCreate met uitgestelde start
• UI-thread — 5 seconden zonder gebeurtenisverwerking; elke blokkering langer dan 5 seconden veroorzaakt ANR

Hoe ANR te diagnosticeren

Android biedt verschillende hulpmiddelen voor ANR-analyse: van systeemlogs tot gespecialiseerde bibliotheken.

Analyse van traces.txt

Bij elke ANR slaat Android het bestand /data/anr/traces.txt op met een dump van de stacks van alle threads van de app. Zoek de thread "main" — de laatste methode in de stack geeft de oorzaak aan. Typische patronen: Thread.sleep(), InputStream.read(), BinderProxy.transact(). Gebruik adb met supergebruikersrechten om het bestand van het apparaat te halen.

Firebase Crashlytics met ANR-rapporten

Firebase Crashlytics verzamelt automatisch ANR's en toont ze in het dashboard samen met tracering. Voor Android 11+ komen ANR-rapporten met de volledige stack van de hoofdthread. Integratie vereist het toevoegen van een afhankelijkheid en initialisatie van FirebaseApp in Application.onCreate.

Android Studio Profiler met thread-tracering

CPU Profiler in Android Studio stelt u in staat een tracering van de app-werking vast te leggen en te zien welke methoden CPU-tijd in beslag nemen. Schakel "Record with method traces" in en reproduceer het scenario dat ANR veroorzaakt. Op de tijdlijn is te zien welke methoden op het moment van vastlopen in de hoofdthread werden uitgevoerd.

Voorbeeld van Firebase Crashlytics-integratie voor het verzamelen van ANR op Android:

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

Methoden om ANR te verhelpen

Het verhelpen van ANR betekent vooral het verplaatsen van alle lange operaties van de hoofdthread naar achtergrondthreads. Laten we de specifieke technieken voor elk componenttype bekijken.

Gebruik van WorkManager voor achtergrondtaken

WorkManager — de door Google aanbevolen oplossing voor achtergrondwerk. Het garandeert uitvoering van de taak in een achtergrondthread, rekening houdend met de apparaatstatus. In tegenstelling tot Service blokkeert WorkManager de hoofdthread niet en is het bestand tegen herstarten van de app. Gebruik voor BroadcastReceiver goAsync() en geef het resultaat PendingResult door aan WorkManager.

Kotlin Coroutines met de juiste dispatchers

Start alle netwerkverzoeken, databasewerk en bestandsbewerkingen met Dispatchers.IO. De hoofdthread mag alleen de UI bijwerken. Gebruik viewModelScope voor automatische annulering van coroutines bij vernietiging van Activity. Vermijd runBlocking() in elke context — dit is een synchrone blokkering van de huidige thread.

Lazy-initialisatie van ContentProvider

Als ContentProvider een lange initialisatie uitvoert, gebruik dan een mechanisme voor uitgesteld laden: maak een provider die onmiddellijk gegevens retourneert en start de zware initialisatie via WorkManager met vertraging. Dit voorkomt ANR bij het starten van de app, wanneer het systeem het meest gevoelig is voor vertragingen.

Voorbeeld van correct gebruik van BroadcastReceiver met goAsync in 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()
    }
}

Preventie van ANR in ontwikkeling

De beste manier om ANR te bestrijden is voorkomen dat ze ontstaan in de ontwikkelingsfase door middel van tools en architectuuroplossingen.

StrictMode voor detectie van hoofdthreadblokkeringen

StrictMode met ingeschakelde detectNetwork()- en detectDiskReads()/detectDiskWrites()-beleidsregels detecteert potentiële ANR's in de ontwikkelingsfase. Stel in Debug-build penaltyDeath in — elke overtreding leidt tot een onmiddellijke crash en de ontwikkelaar ziet het probleem vóór de commit.

Firebase Performance Monitoring voor productiemetrics

Firebase Performance houdt de uitvoeringstijd van kritieke bewerkingen bij en toont welke scenario's de ANR-drempel overschrijden. Stel aangepaste traceringen in voor elk scherm en netwerkverzoek. Als de uitvoeringstijd 3 seconden overschrijdt — is dit een potentiële ANR die optimalisatie vereist.

Testen met netwerk- en schijfvertragingen

Simuleer trage omstandigheden: beperk de netwerksnelheid via Network Link Conditioner op iOS of Android Emulator. Vertraag het lezen van de schijf door emulatie van traag geheugen. ANR verschijnt vaak juist onder dergelijke omstandigheden; op snelle ontwikkelaarsapparaten zijn ze niet zichtbaar.

• BroadcastReceiver — gebruik altijd goAsync() voor verwerking langer dan 1 seconde
• Service — vervang door WorkManager of CoroutineWorker met achtergronddispatcher
• ContentProvider — vermijd netwerk en database in onCreate, gebruik lazy-init met WorkManager
• UI-thread — StrictMode met penaltyDeath in Debug, Firebase Performance voor productiemonitoring