App-crash: wat het is, oorzaken van crashes en opsporingsmethoden

Wat is een app-crash

Crash — onverwachte beëindiging van het programma veroorzaakt door een uitzonderlijke situatie die de code niet heeft afgehandeld. In mobiele besturingssystemen leidt een crash tot onmiddellijke sluiting van de app en weergave van het scherm „App gestopt“ of terugkeer naar het startscherm.

Crashes vallen in twee grote klassen uiteen. Afgehandelde fouten — try/catch-blokken vangen de uitzondering op, de app blijft werken, mogelijk met verlies van functionaliteit. Onverwerkte crashes — de uitzondering propagateert naar het niveau van het besturingssysteem en het systeem doodt het proces. Het tweede type is bijzonder gevaarlijk omdat de gebruiker geen gegevens kan opslaan.

Een systeem met twee miljoen gebruikers en een crash rate van 0,1% verliest 2.000 gebruikers bij elke release. Volgens Google Play Console (2024) worden apps met een crash rate boven 1,5% uitgesloten van aanbevelingen en verliezen ze tot 30% van het organische verkeer.

Belangrijkste oorzaken van crashes in mobiele apps

NullPointerException (NPE) — de koning van crashes in Java/Kotlin. Poging om een methode aan te roepen op een null-object. In Kotlin komt NPE minder vaak voor dankzij null safety, maar is nog steeds mogelijk bij gebruik van de operator !! of interactie met Java-code. schat: NPE is goed voor 25% van alle crashes van Android-apps.

IndexOutOfBoundsException — toegang tot een lijstelement met een niet-bestaande index. Veelvoorkomende oorzaak: gegevens komen van de server in een onverwacht formaat en de UI probeert een positie weer te geven die niet bestaat. Oplossing — controleer altijd de grootte van de collectie voordat je via index opent.

ANR (Application Not Responding) — Android-specifiek probleem. De UI-thread wordt meer dan 5 seconden geblokkeerd. Belangrijkste oorzaken: netwerkverzoeken op de hoofdthread, zware berekeningen, synchronisatie met de database. StrictMode in Android helpt bij het detecteren van UI-threadblokkades in de ontwikkelingsfase.

OutOfMemoryError (OOM) — de app heeft de geheugenlimiet overschreden. Op mobiele apparaten met 2–4 GB RAM is OOM een veelvoorkomend probleem bij het werken met grote afbeeldingen of oneindige lijsten zonder paginering. Oplossing — Glide/Coil voor het laden van afbeeldingen, LruCache voor caching, ViewHolder in RecyclerView.

Runtime-uitzonderingen en fatale fouten

Runtime exceptions — fouten die de compiler niet controleert tijdens de bouwfase. Ze verschijnen alleen bij het uitvoeren van code op een specifiek apparaat met specifieke gegevens. In Java zijn dit RuntimeException en zijn subklassen: NullPointerException, IllegalArgumentException, ArithmeticException.

Fatale fouten (FATAL) — geen runtime, maar systeemstoringen. Signal 11 (SIGSEGV) — geheugensegmentatieschending in native code. Signal 6 (SIGABRT) — abnormale beëindiging veroorzaakt door de app zelf via abort(). Zulke crashes zijn moeilijk te diagnosticeren omdat de stack trace vaak geen begrijpelijke context toont.

In iOS zijn de belangrijkste oorzaken NSInvalidArgumentException (onverwachte nil in een parameter) en EXC_BAD_ACCESS (toegang tot vrijgegeven geheugen). Swift heeft het aantal crashes verminderd in vergelijking met Objective-C, maar fouten in ObjC-runtime en C-bibliotheken leiden nog steeds tot crashes.

Monitoring en verzameling van crashlogs

Firebase Crashlytics — de standaard voor mobiele apps. Verzamelt automatisch stack trace, voegt logs, gebruikers-ID en apparaatmetadata toe. Groepeert crashes op handtekening (foutklasse + regel). Real-time alerts — meldingen wanneer de crash rate een ingestelde drempel overschrijdt (bijv. >0,1% per uur).

Sentry — een alternatief met flexibelere mogelijkheden. Maakt het mogelijk om custom contexts aan te maken, breadcrumbs toe te voegen, in-app filtering te configureren om onbelangrijke fouten uit te sluiten. Source maps voor Kotlin en Swift maken het mogelijk om de broncode te zien, niet de verduisterde namen.

Best practices voor logs: stuur belangrijke metadata voordat je een gevaarlijke bewerking uitvoert. Voeg custom keys toe (API-versienummer, laatste scherm, grootte van invoergegevens). Dit verandert een nutteloze stack trace in bruikbare informatie.

Voorbeeld: Crashlytics instellen 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)
        }
    }
}

undefined

Optional binding en null safety — gebruik in Kotlin `?` voor nullable types, `let` en `?:` voor veilige null-afhandeling. In Swift — optionals en guard let. Modern Kotlin (2024) heeft Contract-annotaties toegevoegd: @ContractsDsl maakt het mogelijk om te declareren dat een functie geen null retourneert, en de compiler controleert dit.

Error handling in netwerk — elk netwerkverzoek moet timeouts, parseerfouten en serverweigering afhandelen. Retrofit met Result-type — een sealed class die garandeert dat de fout wordt afgehandeld. No Exception-stijl: gebruik in plaats van try/catch sealed Result voor expliciete afhandeling van succes en fout.

Feature flags — schakel problematische functionaliteit op afstand uit zonder een nieuwe versie uit te brengen. Firebase Remote Config maakt het mogelijk om het gedrag van de app te wijzigen zonder publicatie in de winkel.

Geleidelijke uitrol — breng de nieuwe versie uit voor 5% van het publiek en monitor de crash rate. Als de rate onder het doel blijft (meestal <0,1%), breid dan uit naar 25%, dan 50%, dan 100%. Google Play Console en App Store Connect ondersteunen gefaseerde uitrol voor automatische stopzetting bij overschrijding van de drempel.

Actieplan bij detectie van een fout

1: Classificatie — bepaal de ernst: Critical (crash bij >1% gebruikers), High (0,1–1%), Medium (<0,1%). Voor Critical crashes — onmiddellijke reactie. Google Play Console classificeert crashes automatisch op basis van het aantal getroffen gebruikers.

2: Stack trace-analyse — open het logboek in Crashlytics, zie de exacte locatie van de crash. Controleer custom keys: welk scherm, welke gegevens, OS-versie. Vergelijk met de laatste implementatie — vaak wordt de crash veroorzaakt door een recente wijziging in de code die een onverwacht gebruiksscenario heeft getroffen.

3: Reproductie — probeer de crash te reproduceren op een apparaat of emulator met vergelijkbare parameters. Als dit niet lukt, controleer dan het crashlog op patronen: specifieke modellen (Samsung A10), Android-versies (API < 26), locale. Oplossing — voeg een beschermende voorwaarde toe die het scenario dekt.

4: Fix en monitoring — breng een hotfix uit met prioriteit. Zorg ervoor dat de crash rate voor dit type na de release naar nul daalt. Schrijf een regressietest die het crashscenario dekt. Zonder test kan dezelfde bug terugkeren bij de volgende refactoring.