ANRs

Wenn der UI-Thread einer Android-App zu lange blockiert ist, wird ein ANR-Fehler (Application Not Responding) ausgelöst. Wenn sich die App im Vordergrund befindet, wird dem Nutzer ein Dialogfeld angezeigt, wie in Abbildung 1 dargestellt. Im ANR-Dialogfeld kann der Nutzer die App beenden.

Das ANR-Dialogfeld, das dem Nutzer angezeigt wird.
Abbildung 1. ANR-Dialogfeld, das dem Nutzer angezeigt wird

ANR-Fehler sind ein Problem, weil der Hauptthread der App, der für das Aktualisieren der Benutzeroberfläche zuständig ist, keine Nutzereingabeereignisse verarbeiten oder zeichnen kann, was zu Frustration beim Nutzer führt. Weitere Informationen zum Hauptthread der App finden Sie unter Prozesse und Threads – Übersicht.

Ein ANR-Fehler wird für Ihre App ausgelöst, wenn eine der folgenden Bedingungen eintritt:

  • Zeitüberschreitung bei der Eingabeübertragung: Wenn Ihre App nicht innerhalb von 5 Sekunden auf ein Eingabeereignis (z. B. einen Tastendruck oder eine Bildschirmberührung) reagiert hat.
  • Ausführung des Dienstes: Wenn ein von Ihrer App deklarierter Dienst die Ausführung von Service.onCreate und Service.onStartCommand/Service.onBind nicht innerhalb weniger Sekunden abschließen kann.
  • Service.startForeground nicht aufgerufen: Wenn Ihre App Context.startForegroundService verwendet, um einen neuen Dienst im Vordergrund zu starten der Dienst aber startForeground nicht innerhalb von 5 Sekunden aufruft.
  • Übertragung von Intents: Wenn die Ausführung eines BroadcastReceiver nicht innerhalb eines festgelegten Zeitraums abgeschlossen wurde. Wenn die App eine Aktivität im Vordergrund hat, beträgt dieses Zeitlimit 5 Sekunden.
  • JobScheduler Interaktionen: Wenn JobService nicht innerhalb weniger Sekunden von JobService.onStartJob oder JobService.onStopJob zurückgegeben wird oder wenn ein vom Nutzer initiierter Job gestartet wird und Ihre App JobService.setNotification nicht innerhalb weniger Sekunden nach dem Aufruf von JobService.onStartJob aufruft. Bei Apps, die auf Android 13 und niedriger ausgerichtet sind, werden die ANR-Fehler nicht gemeldet. Bei Apps, die auf Android 14 und höher ausgerichtet sind, werden die ANR-Fehler explizit gemeldet.

Wenn in Ihrer App ANR-Fehler auftreten, können Sie das Problem mithilfe der Informationen in diesem Dokument diagnostizieren und beheben.

Problem erkennen

Wenn Sie Ihre App bereits veröffentlicht haben, können Sie in Android Vitals Informationen zu ANR-Fehlern für Ihre App aufrufen. Sie können auch andere Tools verwenden, um ANR-Fehler zu erkennen. Im Gegensatz zu Android Vitals können Tools von Drittanbietern jedoch keine ANR-Fehler unter Android 10 und niedriger melden.

Android Vitals

Mit Android Vitals können Sie die ANR-Rate Ihrer App im Blick behalten und verbessern. In Android Vitals werden verschiedene ANR-Raten erfasst:

  • ANR-Rate: Prozentsatz der aktiven Nutzer pro Tag, bei denen ein ANR-Fehler aufgetreten ist.
  • Rate der vom Nutzer wahrgenommenen ANR-Fehler: Prozentsatz der aktiven Nutzer pro Tag, bei denen mindestens ein vom Nutzer wahrgenommener ANR-Fehler aufgetreten ist. Derzeit werden nur ANR-Fehler vom Typ Input dispatching timed out als vom Nutzer wahrgenommen betrachtet.
  • Mehrfach-ANR-Rate: Prozentsatz der aktiven Nutzer pro Tag, bei denen mindestens zwei ANR-Fehler aufgetreten sind.

Ein aktiver Nutzer pro Tag ist ein eindeutiger Nutzer, der Ihre App an einem Tag auf einem Gerät verwendet, möglicherweise in mehreren Sitzungen. Wenn ein Nutzer Ihre App an einem Tag auf mehreren Geräten verwendet, wird jedes Gerät zur Zahl der aktiven Nutzer an diesem Tag addiert.

Die Rate der vom Nutzer wahrgenommenen ANR-Fehler ist ein Vitalparameter, d. h., er beeinflusst die Sichtbarkeit Ihrer App bei Google Play. Er ist wichtig, weil die gezählten ANR-Fehler immer auftreten, während der Nutzer mit der App interagiert, und daher die größte Störung verursachen.

In Google Play sind für diesen Messwert zwei Grenzwerte für schlechtes Verhalten definiert:

  • Grenzwert zu unerwünschtem Verhalten: Bei mindestens 0, 47% der aktiven Nutzer pro Tag tritt auf allen Gerätemodellen ein vom Nutzer wahrgenommener ANR-Fehler auf.
  • Grenzwert zu unerwünschtem Verhalten pro Gerät: Bei mindestens 8% der täglichen Nutzer tritt bei einem einzelnen Gerätemodell ein vom Nutzer wahrgenommener ANR-Fehler auf.

Wenn Ihre App den Grenzwert zu unerwünschtem Verhalten überschreitet, ist sie wahrscheinlich auf allen Geräten weniger gut sichtbar. Wenn Ihre App den Grenzwert für schlechtes Verhalten auf einzelnen Geräten überschreitet, ist sie wahrscheinlich auf diesen Geräten weniger gut sichtbar und in Ihrem Store-Eintrag wird möglicherweise eine Warnung angezeigt.

Android Vitals kann Sie über die Play Console benachrichtigen, wenn in Ihrer App übermäßig viele ANR-Fehler auftreten.

Informationen dazu, wie Google Play Android Vitals-Daten erfasst, finden Sie in der Play Console Dokumentation.

ANR-Fehler diagnostizieren

Bei der Diagnose von ANR-Fehlern gibt es einige häufige Muster, nach denen Sie suchen können:

  • Die App führt langsame Vorgänge mit E/A im Hauptthread aus.
  • Die App führt eine lange Berechnung im Hauptthread aus.
  • Der Hauptthread führt einen synchronen Binder-Aufruf an einen anderen Prozess aus und die Rückgabe durch diesen Prozess dauert lange.
  • Der Hauptthread ist blockiert und wartet auf einen synchronisierten Block für einen langen Vorgang, der in einem anderen Thread ausgeführt wird.
  • Der Hauptthread befindet sich in einem Deadlock mit einem anderen Thread, entweder in Ihrem Prozess oder über einen Binder-Aufruf. Der Hauptthread wartet nicht nur auf den Abschluss eines langen Vorgangs, sondern befindet sich in einer Deadlock Situation.

Mit den folgenden Techniken können Sie die Ursache von ANR-Fehlern ermitteln.

HealthStats

HealthStats liefert Messwerte zum Zustand einer Anwendung, indem die Gesamtzeit für Nutzer und System, die CPU-Zeit, Netzwerk- und Funkstatistiken, die Zeit für das Ein- und Ausschalten des Bildschirms sowie Weckalarme erfasst werden. So können Sie die CPU-Gesamtauslastung und den Akkuverbrauch messen.

Fehler beheben

Debug hilft Ihnen, Android-Anwendungen während der Entwicklung zu untersuchen, einschließlich Tracing- und Zuweisungszahlen, um Ruckeln und Verzögerungen in den Apps zu erkennen. Sie können Debug auch verwenden, um Laufzeit- und native Speicherzähler sowie Speichermesswerte abzurufen, mit denen Sie den Speicherbedarf eines bestimmten Prozesses ermitteln können.

ApplicationExitInfo

ApplicationExitInfo ist unter Android 11 (API-Level 30) oder höher verfügbar und liefert Informationen zum Grund für das Beenden der Anwendung. Dazu gehören ANR-Fehler, wenig Speicher, App-Abstürze, übermäßige CPU-Auslastung, Nutzerunterbrechungen, Systemunterbrechungen und Änderungen der Laufzeitberechtigungen.

Strenger Modus

Mit StrictMode können Sie versehentliche E/A-Vorgänge im Haupt thread während der Entwicklung Ihrer App erkennen. Sie können StrictMode auf der Anwendungs- oder Aktivitätsebene verwenden.

ANR-Dialogfelder im Hintergrund aktivieren

Unter Android werden ANR-Dialogfelder für Apps, bei denen die Verarbeitung der Broadcast-Nachricht zu lange dauert, nur angezeigt, wenn in den Entwickleroptionen des Geräts die Option Alle ANR-Fehler anzeigen aktiviert ist. Aus diesem Grund werden ANR-Dialogfelder im Hintergrund nicht immer angezeigt, auch wenn in der App Leistungsprobleme auftreten.

Engpässe bei der Neuzusammensetzung

Verwenden Sie den Android Studio Profiler und den Layout Inspector, um Engpässe bei der Neukomposition zu finden. Weitere Informationen finden Sie unter Jetpack Compose Leistung.

Traces-Datei abrufen

Unter Android werden Trace-Informationen gespeichert, wenn ein ANR-Fehler auftritt. In älteren Betriebssystemversionen gibt es auf dem Gerät eine einzelne Datei /data/anr/traces.txt. In neueren Betriebssystemversionen gibt es mehrere Dateien /data/anr/anr_*. Sie können auf ANR Traces von einem Gerät oder Emulator aus zugreifen, indem Sie die Android Debug Bridge (ADB) als Root verwenden:

adb root
adb shell ls /data/anr
adb pull /data/anr/<filename>

Sie können einen Fehlerbericht von einem physischen Gerät erfassen, indem Sie entweder die Entwickleroption „Fehlerbericht abrufen“ auf dem Gerät oder den Befehl adb bugreport auf Ihrem Entwicklungscomputer verwenden. Weitere Informationen finden Sie unter Fehlerberichte erfassen und lesen.

Probleme beheben

Nachdem Sie das Problem erkannt haben, können Sie die Tipps in diesem Abschnitt verwenden, um häufige Probleme zu beheben.

Langsamer Code im Hauptthread

Ermitteln Sie die Stellen in Ihrem Code, an denen der Hauptthread der App länger als 5 Sekunden beschäftigt ist. Suchen Sie in Ihrer App nach verdächtigen Anwendungsfällen und versuchen Sie, den ANR-Fehler zu reproduzieren.

Ein häufiges Problem ist eine Aufgabe mit langer Ausführungszeit direkt in einer zusammensetzbaren Funktion:

@Composable
fun BadList(rawStrings: List<String>) {
    // Math or sorting inside the composable runs on EVERY recomposition pass!
    val heavilyProcessedList = rawStrings
        .filter { it.isNotBlank() }
        .map { it.uppercase().reversed() }
        .map { it.computationallyHeavyFunction() }
.sortedBy { it.length }
    LazyColumn { items(sortedList) { Text(it) } }
}

// Modern Compose-first fix
@Composable
fun GoodList(viewModel: MyViewModel = viewModel()) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    // UI simply renders state; no heavy processing allowed here
    LazyColumn { items(uiState.sortedData) { Text(it) } }
}

E/A im Hauptthread

Die Ausführung von E/A-Vorgängen im Hauptthread ist eine häufige Ursache für langsame Vorgänge im Hauptthread, die zu ANR-Fehlern führen können. In Compose lösen Entwickler oft versehentlich Festplattenlesevorgänge aus (z. B. SharedPreferences oder Datenbankaufrufe), wenn sie versuchen, den Anfangszustand abzuleiten.

Führen Sie E/A-Vorgänge mit langer Ausführungszeit außerhalb der UI-Ebene aus. Verwenden Sie withContext(Dispatchers.IO) in einem ViewModel oder noch besser ein Repository auf der Datenschicht.

Deadlocks

Ein Deadlock tritt auf, wenn ein Thread in einen Wartezustand wechselt, weil eine erforderliche Ressource von einem anderen Thread gehalten wird, der ebenfalls auf eine Ressource wartet, die vom ersten Thread gehalten wird. Wenn sich der Hauptthread der App in dieser Situation befindet, treten wahrscheinlich ANR-Fehler auf.

Deadlocks sind ein gut untersuchtes Phänomen in der Informatik und es gibt Algorithmen zur Vermeidung von Deadlocks, die Sie verwenden können, um Deadlocks zu vermeiden.

Weitere Informationen finden Sie unter Deadlock und Deadlock prevention algorithms auf Wikipedia.

Wenn Sie Kotlin und Compose verwenden, können Sie primitive Sperren durch nicht blockierende Coroutinen-Mutexe (Mutex.withLock) ersetzen, um zu verhindern, dass Threads blockiert werden. Stattdessen wird der Ausführungskontext angehalten , anstatt den UI Thread einzufrieren. Beispiel:

import kotlinx.coroutines.sync.Mutex
import kotlinx.coroutines.sync.withLock

// Modern non-blocking concurrency state architecture
class SecureDataRepository {
    private val mutex = Mutex()

    suspend fun safeUIAccess() {
        // If locked, the main thread suspends seamlessly, preventing an ANR
        mutex.withLock {
            performSafeOperation()
        }
    }
}

Langsame Broadcast-Empfänger

Apps können mithilfe von Broadcast-Empfängern auf Broadcast-Nachrichten reagieren, z. B. auf das Aktivieren oder Deaktivieren des Flugmodus oder auf eine Änderung des Verbindungsstatus. Ein ANR-Fehler tritt auf, wenn die Verarbeitung der Nachricht an alle durch eine App zu lange dauert.

Ein ANR-Fehler tritt in den folgenden Fällen auf:

  • Die Ausführung der Methode onReceive eines Broadcast-Empfängers dauert zu lange.
  • Ein Übertragungsempfänger ruft goAsync auf und ruft finish für das Objekt PendingResult nicht auf.

Ihre App sollte in der onReceive Methode eines BroadcastReceiver nur kurze Vorgänge ausführen. Wenn Ihre App jedoch aufgrund einer Nachricht an alle eine komplexere Verarbeitung erfordert, sollten Sie die Aufgabe an ein ViewModel (mit den Vorteilen von Kotlin-Koroutinen, -Scopes und -Dispatchern) delegieren, wenn die Aufgabe voraussichtlich höchstens einige Sekunden dauert, an einen beliebigen State Holder, oder an WorkManager für Aufgaben, die voraussichtlich länger als einige Sekunden dauern.

GameActivity

Die GameActivity-Bibliothek hat in Fallstudien zu Spielen und Apps, die in C oder C++ geschrieben wurden, die Anzahl der ANR-Fehler reduziert. Wenn Sie Ihre vorhandene native Aktivität durch GameActivity ersetzen, können Sie die Blockierung des UI-Threads reduzieren und einige ANR-Fehler vermeiden.

Weitere Informationen zu ANR-Fehlern finden Sie unter App reaktionsschnell halten. Weitere Informationen zu Threads finden Sie unter Bessere Leistung durch Threading.

Zusätzliche Ressourcen

Inhalte ansehen