App-Absturz: Was ist das, Ursachen für Abstürze und Erkennungsmethoden

Was ist ein App-Absturz

Absturz — eine unerwartete Beendigung des Programms, die durch eine Ausnahmesituation verursacht wird, die der Code nicht behandelt hat. In mobilen Betriebssystemen führt ein Absturz zum sofortigen Schließen der App und zeigt einen Bildschirm „App gestoppt“ an oder kehrt zum Startbildschirm zurück.

Abstürze werden in zwei große Klassen unterteilt. Behandelte Fehler — try/catch-Blöcke fangen die Ausnahme ab, die App läuft weiter, möglicherweise mit Funktionsverlust. Unbehandelte Abstürze — die Ausnahme steigt bis zur Betriebssystemebene auf, und das System beendet den Prozess. Der zweite Typ ist besonders gefährlich, da der Benutzer keine Daten speichern kann.

Ein System mit zwei Millionen Nutzern und einer Absturzrate von 0,1% verliert bei jedem Release 2.000 Nutzer. Laut Google Play Console (2024) werden Apps mit einer Absturzrate über 1,5% aus den Empfehlungen ausgeschlossen und verlieren bis zu 30% des organischen Traffics.

Hauptursachen für Abstürze in mobilen Apps

NullPointerException (NPE) — der König der Abstürze in Java/Kotlin. Versuch, eine Methode auf einem null-Objekt aufzurufen. In Kotlin ist NPE dank null safety seltener, aber bei Verwendung des !!-Operators oder bei Interaktion mit Java-Code immer noch möglich. Google (2024) schätzt, dass NPE 25% aller Android-App-Abstürze ausmacht.

IndexOutOfBoundsException — Zugriff auf ein Listenelement mit einem nicht vorhandenen Index. Häufige Ursache: Daten kommen vom Server in einem unerwarteten Format, und die UI versucht, eine nicht vorhandene Position anzuzeigen. Lösung — Überprüfe immer die Größe der Sammlung vor dem Zugriff per Index.

ANR (Application Not Responding) — ein Android-spezifisches Problem. Der UI-Thread wird für mehr als 5 Sekunden blockiert. Hauptursachen: Netzwerkanfragen im Hauptthread, schwere Berechnungen, Datenbanksynchronisation. StrictMode in Android hilft, UI-Thread-Blockierungen während der Entwicklung zu erkennen.

OutOfMemoryError (OOM) — die App hat das Speicherlimit überschritten. Auf mobilen Geräten mit 2–4 GB RAM ist OOM ein häufiges Problem bei der Arbeit mit großen Bildern oder unendlichen Listen ohne Paginierung. Lösung — Glide/Coil zum Laden von Bildern, LruCache zum Caching, ViewHolder in RecyclerView.

Laufzeitausnahmen und fatale Fehler

Laufzeitausnahmen — Fehler, die der Compiler zur Build-Zeit nicht prüft. Sie treten nur auf, wenn der Code auf einem bestimmten Gerät mit bestimmten Daten ausgeführt wird. In Java sind dies RuntimeException und ihre Unterklassen: NullPointerException, IllegalArgumentException, ArithmeticException.

Fatale Fehler (FATAL) — keine Laufzeit-, sondern Systemfehler. Signal 11 (SIGSEGV) — Speichersegmentierungsverletzung in nativem Code. Signal 6 (SIGABRT) — abnormale Beendigung, die von der App selbst durch abort() ausgelöst wird. Solche Abstürze sind schwer zu diagnostizieren, da der Stack-Trace oft keinen klaren Kontext zeigt.

In iOS sind die Hauptursachen NSInvalidArgumentException (unerwartetes nil in einem Parameter) und EXC_BAD_ACCESS (Zugriff auf freigegebenen Speicher). Swift hat die Anzahl der Abstürze im Vergleich zu Objective-C reduziert, aber Fehler in der ObjC-Laufzeit und C-Bibliotheken führen immer noch zu Abstürzen.

Absturzüberwachung und Protokollsammlung

Firebase Crashlytics — der Standard für mobile Apps. Sammelt automatisch Stack-Traces, fügt Protokolle, Benutzer-IDs und Gerätemetadaten hinzu. Gruppiert Abstürze nach Signatur (Fehlerklasse + Zeile). Echtzeitwarnungen — Benachrichtigungen, wenn die Absturzrate einen festgelegten Schwellenwert überschreitet (z.B. >0,1% pro Stunde).

Sentry — eine Alternative mit flexibleren Möglichkeiten. Ermöglicht das Erstellen benutzerdefinierter Kontexte, das Hinzufügen von Breadcrumbs (vorausgehende Ereignisse) und das Konfigurieren von In-App-Filtern zum Ausschließen unwichtiger Fehler. Source Maps für Kotlin und Swift ermöglichen es, den Quellcode anstelle von verschleierten Namen zu sehen.

Best Practices für Protokolle: Sende wichtige Metadaten vor der Ausführung einer gefährlichen Operation — so ist im Protokoll sichtbar, was der Benutzer vor dem Absturz getan hat. Füge benutzerdefinierte Schlüssel hinzu (API-Versionsnummer, letzter Bildschirm, Eingabedatengröße). Dies verwandelt einen nutzlosen Stack-Trace in umsetzbare Informationen.

Beispiel: Einrichten von Crashlytics in Android

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

Strategien zur Absturzprävention

Optionale Bindung und null safety — in Kotlin verwende `?` für nullable Typen, `let` und `?:` für die sichere Null-Behandlung. In Swift — Optionals und guard let. Modernes Kotlin (2024) hat Contract-Annotationen hinzugefügt: `@ContractsDsl` ermöglicht die Deklaration, dass eine Funktion nicht null zurückgibt, und der Compiler prüft dies.

Fehlerbehandlung bei Netzwerken — jede Netzwerkanfrage muss Timeout, Parsing-Fehler und Serverausfälle behandeln. Retrofit mit Result-Typ — eine versiegelte Klasse, die garantiert, dass der Fehler behandelt wird. No-Exception-Stil: Verwende anstelle von try/catch versiegelte Result für die explizite Behandlung von Erfolg und Fehler.

Feature Flags — deaktiviere problematische Funktionalität remote, ohne eine neue Version zu veröffentlichen. Wenn ein serverseitiger Vorgang auf älteren Geräten einen Absturz verursacht, deaktiviert das Flag ihn für diese Gruppe. Firebase Remote Config ermöglicht die Änderung des App-Verhaltens ohne Veröffentlichung im Store.

Schrittweiser Rollout — veröffentliche eine neue Version für 5% der Zielgruppe und überwache die Absturzrate. Bleibt die Rate unter dem Zielwert (normalerweise <0,1%), erweitere auf 25%, dann 50%, dann 100%. Google Play Console und App Store Connect unterstützen gestaffelte Rollouts zum automatischen Stopp bei Überschreitung des Schwellenwerts.

Aktionsplan bei Fehlererkennung

Schritt 1: Klassifizierung — bestimme den Schweregrad: Kritisch (Absturz bei >1% der Nutzer), Hoch (0,1–1%), Mittel (<0,1%). Bei kritischen Abstürzen — sofortige Reaktion. Bei anderen — standardmäßiger Fehlerbehebungsprozess im aktuellen Sprint. Google Play Console klassifiziert Abstürze automatisch nach der Anzahl der betroffenen Nutzer.

Schritt 2: Stack-Trace-Analyse — öffne das Protokoll in Crashlytics, überprüfe den genauen Ort des Absturzes. Prüfe benutzerdefinierte Schlüssel: welcher Bildschirm, welche Daten, OS-Version. Vergleiche mit dem letzten Deployment — oft wird ein Absturz durch eine kürzliche Codeänderung verursacht, die ein unerwartetes Nutzungsszenario betroffen hat.

Schritt 3: Reproduktion — versuche, den Absturz auf einem Gerät oder Emulator mit ähnlichen Parametern zu reproduzieren. Wenn nicht erfolgreich, überprüfe das Absturzprotokoll auf Muster: bestimmte Modelle (Samsung A10), Android-Versionen (API < 26), Gebietsschemata. Lösung — füge eine defensive Bedingung hinzu, die das Szenario abdeckt.

Schritt 4: Behebung und Überwachung — veröffentliche einen Hotfix mit Priorität. Stelle nach dem Release sicher, dass die Absturzrate für diesen Typ auf Null fällt. Schreibe einen Regressionstest, der das Absturzszenario abdeckt. Ohne Test kann derselbe Fehler beim nächsten Refactoring zurückkehren.