ANR in Android: Was es ist, Ursachen und Lösungsmethoden

Was ist ANR in Android

ANR (Application Not Responding) ist ein Benutzerschutzmechanismus in Android, der ausgelöst wird, wenn die App nicht mehr auf Eingaben reagiert. Das System verfolgt die Ereignisverarbeitungszeit: Wenn BroadcastReceiver onReceive nicht innerhalb von 10 Sekunden abschließt, Service nicht innerhalb von 20 Sekunden von onCreate zurückkehrt oder ContentProvider nicht innerhalb von 15 Sekunden antwortet — generiert Android einen ANR.

Wie ANR für den Benutzer aussieht

Wenn ein ANR auftritt, zeigt Android einen Systemdialog über allen Fenstern an: „App antwortet nicht. Möchten Sie sie schließen oder warten?“ Der Benutzer kann die App schließen oder auf ihre Wiederherstellung warten. Wenn ANRs häufig auftreten, deinstalliert der Benutzer die App. Google Play berücksichtigt die ANR-Rate — den Prozentsatz der Sitzungen mit ANR — in seinen Ranking-Algorithmen.

Unterschied zwischen ANR und iOS-Freezes

iOS hat kein Äquivalent zu ANR mit einem Systemdialog. Stattdessen verwendet Apple Watchdog, der den Prozess mit dem Exit-Code 0x8badf00d beendet. Der Benutzer sieht keinen Dialog — die App wird einfach zum Startbildschirm geschlossen. Dies macht ANR auf Android für den Benutzer sichtbarer, gibt dem System aber mehr Diagnoseinformationen.

Hauptursachen von ANR

ANR tritt auf, wenn das System ein Timeout für einen der vier Komponententypen verfolgt. Jede Komponente hat ihr eigenes Zeitlimit.

Blockierung in BroadcastReceiver

BroadcastReceiver wird im Hauptthread ausgeführt. Wenn onReceive eine synchrone Netzwerkanfrage, einen langen Datenbank-Schreibvorgang startet oder auf eine Sperre wartet — tritt innerhalb von 10 Sekunden ein ANR auf. Lösung: Verwenden Sie goAsync() und WorkManager für die Hintergrundverarbeitung. Ein typisches Szenario ist der Empfang einer Push-Benachrichtigung von FCM und das synchrone Speichern in Room.

Lange Operation in Service

Service.onCreate und Service.onStartCommand haben ein Limit von 20 Sekunden. Wenn der Dienst eine schwere Initialisierung (Laden von Bibliotheken, Lesen der Konfiguration aus dem Netzwerk) im Hauptthread startet — ist ANR unvermeidlich. Verwenden Sie IntentService (veraltet) oder WorkManager für eine garantierte Ausführung im Hintergrund.

ContentProvider mit langsamer Initialisierung

ContentProvider.onCreate wird vor Application.onCreate ausgeführt und hat ein Limit von 15 Sekunden. Wenn der Provider eine Datenbankmigration durchführt, Wörterbücher lädt oder das SDK aus dem Netzwerk initialisiert — verursacht dies ANR beim App-Start. Lösung: Lazy-Initialisierung, Auslagern schwerer Operationen an WorkManager.

• BroadcastReceiver — 10 Sekunden für onReceive; verwenden Sie goAsync() für die Hintergrundverarbeitung
• Service — 20 Sekunden für onCreate/onStartCommand; verwenden Sie WorkManager oder CoroutineWorker
• ContentProvider — 15 Sekunden für onCreate; verschieben Sie die Initialisierung in Application.onCreate mit verzögertem Start
• UI-Thread — 5 Sekunden ohne Ereignisverarbeitung; jede Blockierung länger als 5 Sekunden löst ANR aus

Wie man ANR diagnostiziert

Android bietet mehrere Tools für die ANR-Analyse: von Systemprotokollen bis zu spezialisierten Bibliotheken.

Analyse von traces.txt

Bei jedem ANR speichert Android die Datei /data/anr/traces.txt mit einem Stack-Dump aller App-Threads. Suchen Sie den Thread „main“ — die letzte Methode im Stack gibt die Ursache an. Typische Muster: Thread.sleep(), InputStream.read(), BinderProxy.transact(). Zum Extrahieren der Datei vom Gerät verwenden Sie adb mit Superuser-Rechten.

Firebase Crashlytics mit ANR-Berichten

Firebase Crashlytics sammelt ANRs automatisch und zeigt sie im Dashboard mit Traces an. Für Android 11+ enthalten ANR-Berichte den vollständigen Stack des Hauptthreads. Die Integration erfordert das Hinzufügen einer Abhängigkeit und die Initialisierung von FirebaseApp in Application.onCreate.

Android Studio Profiler mit Thread-Tracing

CPU Profiler in Android Studio ermöglicht es Ihnen, App-Traces aufzuzeichnen und zu sehen, welche Methoden CPU-Zeit beanspruchen. Aktivieren Sie „Record with method traces“ und reproduzieren Sie das Szenario, das den ANR verursacht. Die Zeitleiste zeigt, welche Methoden zum Zeitpunkt des Einfrierens im Hauptthread ausgeführt wurden.

Beispiel für die Integration von Firebase Crashlytics zur ANR-Erfassung auf 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 zur Behebung von ANR

ANR zu beheben bedeutet in erster Linie, alle langlaufenden Operationen vom Hauptthread in Hintergrundthreads zu verlagern. Sehen wir uns spezifische Techniken für jeden Komponententyp an.

Verwendung von WorkManager für Hintergrundaufgaben

WorkManager ist Googles empfohlene Lösung für Hintergrundarbeit. Er garantiert die Aufgabenausführung in einem Hintergrundthread unter Berücksichtigung des Gerätezustands. Im Gegensatz zu Service blockiert WorkManager den Hauptthread nicht und ist resistent gegen App-Neustarts. Für BroadcastReceiver verwenden Sie goAsync() und übergeben das PendingResult an WorkManager.

Kotlin Coroutines mit den richtigen Dispatchern

Führen Sie alle Netzwerkanfragen, Datenbankoperationen und Datei-E/A mit Dispatchers.IO aus. Der Hauptthread sollte nur die UI aktualisieren. Verwenden Sie viewModelScope für die automatische Kündigung von Coroutinen beim Zerstören der Activity. Vermeiden Sie runBlocking() in jedem Kontext — es blockiert den aktuellen Thread synchron.

Lazy-Initialisierung von ContentProvider

Wenn ContentProvider eine langsame Initialisierung durchführt, verwenden Sie einen Lazy-Loading-Mechanismus: Erstellen Sie einen Provider, der sofort Daten zurückgibt, und starten Sie die schwere Initialisierung über WorkManager mit einer Verzögerung. Dies verhindert ANR beim App-Start, wenn das System am empfindlichsten auf Verzögerungen reagiert.

Beispiel für die korrekte Verwendung von BroadcastReceiver mit 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()
    }
}

Prävention von ANR in der Entwicklung

Der beste Weg, ANRs zu bekämpfen, ist, sie während der Entwicklung durch Tools und architektonische Entscheidungen zu verhindern.

StrictMode zur Erkennung von Hauptthread-Blockierungen

StrictMode mit aktivierten Richtlinien detectNetwork() und detectDiskReads()/detectDiskWrites() identifiziert potenzielle ANRs während der Entwicklung. Setzen Sie in Debug-Builds penaltyDeath — jeder Verstoß führt zu einem sofortigen Absturz, und der Entwickler sieht das Problem vor dem Commit.

Firebase Performance Monitoring für Produktionsmetriken

Firebase Performance verfolgt die Ausführungszeit wichtiger Operationen und zeigt, welche Szenarien den ANR-Schwellenwert überschreiten. Richten Sie benutzerdefinierte Traces für jeden Bildschirm und jede Netzwerkanfrage ein. Wenn die Ausführungszeit 3 Sekunden überschreitet — handelt es sich um einen potenziellen ANR, der optimiert werden muss.

Tests mit Netzwerk- und Datenträgerverzögerung

Simulieren Sie langsame Bedingungen: Begrenzen Sie die Netzwerkgeschwindigkeit mit Network Link Conditioner auf iOS oder Android Emulator. Verlangsamen Sie das Lesen von der Festplatte durch Emulation langsamen Speichers. ANR treten oft gerade unter solchen Bedingungen auf; auf schnellen Entwicklergeräten sind sie unsichtbar.

• BroadcastReceiver — verwenden Sie immer goAsync() für Verarbeitung länger als 1 Sekunde
• Service — ersetzen Sie durch WorkManager oder CoroutineWorker mit einem Hintergrunddispatcher
• ContentProvider — vermeiden Sie Netzwerk und Datenbank in onCreate, verwenden Sie lazy-init mit WorkManager
• UI-Thread — StrictMode mit penaltyDeath im Debug, Firebase Performance für Produktionsüberwachung