ANR in der Android-Entwicklung — was es ist, Ursachen und Behebungsmöglichkeiten

Was ist ANR

ANR (Application Not Responding) ist ein Dialogfeld des Android-Betriebssystems, das erscheint, wenn eine App nicht mehr auf Benutzereingaben reagiert. Das System verfolgt die Ereignisverarbeitungszeit über InputDispatcher: Wenn eine Berührung oder ein Tastendruck nicht innerhalb von 5 Sekunden verarbeitet wird, zeigt Android einen Dialog an, der das Schließen oder Warten auf die App anbietet.

Der ANR-Mechanismus schützt die Benutzererfahrung vor eingefrorenen Apps. Android erlaubt es einer App nicht, das gesamte System zu blockieren — im Gegensatz zu Desktop-Betriebssystemen begrenzt die mobile Plattform die Ereignisverarbeitungszeit zwangsweise. BroadcastReceiver hat ein Limit von 10 Sekunden und ein Vordergrunddienst hat 20 Sekunden.

ANR ist KEINE Ausnahme im Code — es ist ein Systemmechanismus auf Linux-Prozessebene. Android sendet ein SIGQUIT-Signal an den Prozess, woraufhin das System den Aufrufstapel aller Threads in der Datei traces.txt speichert. Der Entwickler erhält ANR nicht als catch-Ausnahme, sondern als Bericht nach dem Neustart der App. Unter Android 11+ ermöglicht die ApplicationExitInfo-API, den Grund für die Prozessbeendigung programmatisch zu ermitteln, einschließlich ANR — dies vereinfacht die Statistikerfassung ohne manuelles Parsen von traces.txt.

Hauptursachen von ANR

Fünf Kategorien von Operationen führen in Android-Apps konsistent zu ANR. Jede von ihnen blockiert den Hauptthread und verhindert, dass das System Eingabeereignisse und Bildschirmneuzeichnung verarbeitet.

Netzwerkanfragen auf dem Hauptthread

Synchronisierte HTTP-Anfragen, die auf dem UI-Thread ausgeführt werden, sind die häufigste Ursache für ANR bei Anfängern. Selbst eine schnelle Anfrage an einen Server kann 1–3 Sekunden dauern, und bei schlechter Verbindung — 30 Sekunden oder mehr. Android verbietet ab API 11 ausdrücklich Netzwerkoperationen auf dem Hauptthread und wirft NetworkOnMainThreadException.

Verwenden Sie Coroutines oder RxJava für asynchrone Aufrufe. Koroutinen mit dem Dispatcher Dispatchers.IO führen die Anfrage in einem Hintergrundthread aus und übergeben das Ergebnis über Dispatchers.Main an den Hauptthread. Dies eliminiert die Blockierung des UI-Threads durch Netzwerkoperationen vollständig.

fun fetchUserData() {
    CoroutineScope(Dispatchers.Main).launch {
        val result = withContext(Dispatchers.IO) {
            api.getUserData() // Hintergrundoperation
        }
        updateUI(result) // Ergebnis auf dem Hauptthread
    }
}

Intensive Berechnungen auf dem UI-Thread

Das Verarbeiten großer Datenarrays, das Parsen von JSON oder XML, die direkte Arbeit mit Bitmaps auf dem Hauptthread — die zweithäufigste Ursache für ANR. Selbst 300 Millisekunden ununterbrochener Arbeit des UI-Threads ohne Rückkehr zur Ereignisschleife verursachen eine spürbare Rendering-Verzögerung, und der Grenzwert von 5 Sekunden wird als ANR registriert.

WorkManager und Hintergrunddienste sind dafür ausgelegt, schwere Berechnungen vom Hauptthread zu entfernen. Verwenden Sie AsyncTask (veraltet), ListenableFuture oder Kotlin Flow, um Daten in Blöcken zu übergeben, ohne die UI zu blockieren.

Synchronisationssperren und Deadlock

Ein Deadlock tritt auf, wenn zwei Threads Sperren halten und aufeinander warten. Wenn einer der Threads der Hauptthread ist, registriert das System genau nach 5 Sekunden ANR. Thread.join(), CountDownLatch.await() und synchronized-Blöcke, die vom UI-Thread aufgerufen werden, bergen ein Blockierungsrisiko.

Vermeiden Sie jegliche blockierenden Operationen auf dem Hauptthread. Verwenden Sie statt synchronized ConcurrentHashMap, statt Thread.join() — Koroutinen mit async/await. Diese Regel gilt für jede Sprache in Android: Java, Kotlin oder C++ über JNI.

Langlaufender BroadcastReceiver

BroadcastReceiver wird standardmäßig auf dem Hauptthread ausgeführt. Wenn onReceive() länger als 10 Sekunden beschäftigt ist, zeigt Android ANR an. Das Laden von Daten aus einer Datenbank oder einem Netzwerk innerhalb von onReceive ist ein garantierter Weg zum Einfrieren.

Verwenden Sie goAsync() innerhalb von BroadcastReceiver, um zu einem Hintergrundthread zu wechseln, oder registerReceiver mit getBackgroundBroadcastReceiver(). Dies ermöglicht die Ereignisverarbeitung ohne Blockierung der UI.

ContentProvider und SQLite auf dem Hauptthread

Schwere Abfragen an ContentProvider oder direkte Arbeit mit SQLite auf dem UI-Thread — eine weniger offensichtliche, aber häufige Ursache für ANR. Bei der Datenbankmigration oder dem Masseneinfügen Tausender Datensätze kann die Ausführungszeit das 5-Sekunden-Limit überschreiten.

Verlagern Sie alle Datenbank-Operationen mit Room und suspend-Funktionen in Hintergrundthreads. Room prüft automatisch, ob die Abfrage nicht auf dem Hauptthread ausgeführt wird, und wirft bei Verstoß eine Ausnahme.

Wie man ANR diagnostiziert

Die Diagnose von ANR unterscheidet sich vom Debuggen normaler Ausnahmen — Sie können ANR nicht in einem try-catch-Block abfangen. Die Hauptinformationsquelle ist die Datei traces.txt, die Android im Moment des Einfrierens erstellt.

traces.txt enthält den Aufrufstapel aller App-Threads zum Zeitpunkt des ANR. Um die Datei von einem echten Gerät zu lesen, führen Sie den Befehl adb bugreport aus, der einen vollständigen Systembericht einschließlich aller aktuellen ANRs sammelt. Für einen Emulator ist die Datei unter /data/anr/traces.txt verfügbar. Der Aufrufstapel zeigt, welche Methode zum Zeitpunkt der Blockierung auf dem Hauptthread ausgeführt wurde.

adb bugreport bugreport.zip
unzip -p bugreport.zip "*traces*" > traces.txt

Google Play Console bietet den Bereich ANR & Crash mit aggregierten Berichten und Fehlerhäufigkeiten. Für jeden ANR werden der Aufrufstapel und Gerätestatistiken angezeigt: Modell, Android-Version, Region. Dies ermöglicht die Identifizierung von ANRs, die von bestimmten Geräten oder Systemversionen abhängen.

Android Studio enthält seit 2021 ANR Watchdog im Profiler. Es zeichnet automatisch Thread-Dumps auf, wenn der Hauptthread länger als eine Schwellenzeit nicht antwortet. Das Tool zeigt eine Zeitleiste der Ereignisse: welche Operationen gestartet wurden, welche Methoden ausgeführt wurden und in welcher Phase die Blockierung auftrat.

Wie man ANR verhindert

Die Prävention von ANR basiert auf einer grundlegenden Regel: Der Hauptthread sollte nur UI-Ereignisse verarbeiten. Jede Operation, die länger als 16 Millisekunden (die Zeit eines Frames) dauert, sollte in einem Hintergrundthread ausgeführt werden.

StrictMode — automatische Prüfung

StrictMode ist ein integriertes Android-Tool zur Erkennung potenzieller ANRs während der Entwicklung. Aktivieren Sie es in Application.onCreate() mit Flags für Festplatten- und Netzwerkoperationen. Bei Verstoß wirft StrictMode eine Ausnahme oder schreibt in logcat.

if (BuildConfig.DEBUG) {
    StrictMode.ThreadPolicy.Builder()
        .detectDiskReads()
        .detectDiskWrites()
        .detectNetwork()
        .penaltyLog()
        .build()
        .let { StrictMode.setThreadPolicy(it) }
}

Asynchrone Muster: Coroutines und RxJava

Kotlin Coroutines — die Standardmethode für asynchrone Arbeit in modernen Android-Apps. Der grundlegende Ansatz: E/A-Operationen werden auf Dispatchers.IO ausgeführt, das Ergebnis wird über Dispatchers.Main an den Hauptthread für UI-Updates übergeben. Für Flow-ähnliche Szenarien verwenden Sie Dispatchers.Default für CPU-intensive Aufgaben.

RxJava bleibt in Legacy-Projekten beliebt. subscribeOn(Schedulers.io()) und observeOn(AndroidSchedulers.mainThread()) — die Mindestausstattung zur Vermeidung von ANR. Die Hauptregel ist dieselbe: Kein Observable oder Flowable sollte Daten vom Hauptthread emittieren.

Überwachung in der Produktion

Firebase Crashlytics unterstützt ab SDK-Version 18.4.0 die ANR-Überwachung standardmäßig. Für Android 11+ verwendet Crashlytics die System-API ApplicationExitInfo, die den genauen Beendigungsgrund liefert: ANR, Crash oder Systemabbruch. Aktivieren Sie benutzerdefinierte Schlüssel mit Bildschirm- und Zustandsparametern für die Kontextanalyse.

Tools zur ANR-Erkennung

Fünf Tools decken alle Phasen der Arbeit mit ANR ab: vom Debuggen an der Workstation bis zur Überwachung in der Produktion. Jedes Tool löst seine eigene Aufgabe und liefert Daten für verschiedene Szenarien.

Jedes Tool hat seine eigene Nische: StrictMode fängt offensichtliche Verstöße frühzeitig ab, Crashlytics zeigt die tatsächliche ANR-Häufigkeit bei Benutzern, und adb bugreport liefert das vollständigste Bild für komplexe Fälle. Kombinieren Sie sie für eine vollständige Abdeckung.

Firebase Performance Monitoring

Firebase Performance verfolgt die Reaktionszeit des UI-Threads und erstellt automatisch Traces für verdächtig lange Operationen. Wenn der Hauptthread länger als 500 ms blockiert ist, zeichnet Performance einen benutzerdefinierten Trace mit dem Namen der verursachenden Methode auf. Dies ermöglicht die Erkennung von ANR-Szenarien ohne Benutzereingriff und bevor sie kritisch werden.

Die Integration mit Firebase Crashlytics liefert ein vollständiges Bild: Performance zeigt Verlangsamungen vor dem ANR, und Crashlytics zeigt das Einfrieren selbst. Richten Sie in der Firebase Console Warnungen für eine ANR-Rate über 0,1% ein, und Sie erhalten Benachrichtigungen über neue Probleme, bevor es zu Massenbeschwerden von Benutzern kommt.