Appkrasch: vad det är, orsaker till krascher och metoder för att fånga dem

Vad är en appkrasch

Krasch — oväntad avslutning av programmet orsakad av en exceptionell situation som koden inte hanterade. I mobila operativsystem leder en krasch till omedelbar stängning av appen och visning av skärmen “Appen har stoppats” eller återgång till startskärmen.

Krascher delas in i två stora klasser. Hanterade fel — try/catch-block fångar undantaget, appen fortsätter att fungera, möjligen med förlust av funktionalitet. Ohanterade krascher — undantaget sprider sig till operativsystemsnivå och systemet dödar processen. Den andra typen är särskilt farlig eftersom användaren inte kan spara data.

Ett system med två miljoner användare och 0,1% kraschfrekvens förlorar 2 000 användare vid varje release. Enligt Google Play Console (2024) utesluts appar med kraschfrekvens över 1,5% från rekommendationer och förlorar upp till 30% av organisk trafik.

Huvudorsaker till krascher i mobilappar

NullPointerException (NPE) — kungen av krascher i Java/Kotlin. Försök att anropa en metod på ett null-objekt. I Kotlin förekommer NPE mer sällan tack vare null safety, men är fortfarande möjligt vid användning av operatorn !! eller interaktion med Java-kod. Google (2024) uppskattar: NPE utgör 25% av alla krascher i Android-appar.

IndexOutOfBoundsException — åtkomst till ett listelement med ett obefintligt index. Vanlig orsak: data kommer från servern i ett oväntat format och UI försöker visa en position som inte finns. Lösning — kontrollera alltid samlingens storlek innan du kommer åt via index.

ANR (Application Not Responding) — Android-specifikt problem. UI-tråden blockeras i mer än 5 sekunder. Huvudorsaker: nätverksförfrågningar på huvudtråden, tunga beräkningar, synkronisering med databasen. StrictMode i Android hjälper till att upptäcka blockering av UI-tråden i utvecklingsfasen.

OutOfMemoryError (OOM) — appen har överskridit minnesgränsen. På mobila enheter med 2–4 GB RAM är OOM ett vanligt problem vid arbete med stora bilder eller oändliga listor utan paginering. Lösning — Glide/Coil för att ladda bilder, LruCache för cachning, ViewHolder i RecyclerView.

Körningsundantag och dödliga fel

Runtime exceptions — fel som kompilatorn inte kontrollerar i byggfasen. De visas bara vid körning av kod på en specifik enhet med specifik data. I Java är dessa RuntimeException och dess underklasser: NullPointerException, IllegalArgumentException, ArithmeticException.

Dödliga fel (FATAL) — inte körning, utan systemfel. Signal 11 (SIGSEGV) — minnessegmenteringsöverträdelse i native-kod. Signal 6 (SIGABRT) — nödavslutning orsakad av appen själv via abort(). Sådana krascher är svåra att diagnostisera eftersom stack trace ofta inte visar begripligt sammanhang.

I iOS är de främsta orsakerna NSInvalidArgumentException (oväntad nil i en parameter) och EXC_BAD_ACCESS (åtkomst till frigjort minne). Swift har minskat antalet krascher jämfört med Objective-C, men fel i ObjC runtime och C-bibliotek leder fortfarande till krascher.

Övervakning och insamling av kraschloggar

Firebase Crashlytics — standarden för mobilappar. Samlar automatiskt in stack trace, lägger till loggar, användar-ID och enhetsmetadata. Grupperar krascher efter signatur (felklass + rad). Real-time alerts — aviseringar när kraschfrekvensen överstiger ett inställt tröskelvärde (t.ex. >0,1% per timme).

Sentry — ett alternativ med mer flexibla möjligheter. Tillåter att skapa anpassade kontexter, lägga till breadcrumbs, konfigurera filtrering i appen för att utesluta oviktiga fel. Source maps för Kotlin och Swift gör det möjligt att se källkoden, inte fördunklade namn.

Best practices för loggar: skicka viktig metadata innan du utför en farlig operation. Lägg till anpassade nycklar (API-versionsnummer, senaste skärmen, storlek på indata). Detta förvandlar en oanvändbar stack trace till användbar information.

Exempel: konfigurera Crashlytics i 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 och null safety — i Kotlin använd `?` för nullable-typer, `let` och `?:` för säker null-hantering. I Swift — optionals och guard let. Modern Kotlin (2024) lade till Contract-annotationer: @ContractsDsl gör det möjligt att deklarera att en funktion inte returnerar null, och kompilatorn kontrollerar detta.

Error handling i nätverk — varje nätverksförfrågan måste hantera timeout, parsningsfel och serveravvisning. Retrofit med Result-typ — en sealed klass som garanterar att felet kommer att hanteras. No Exception-stil: använd sealed Result istället för try/catch för explicit hantering av framgång och fel.

Feature flags — inaktivera problematisk funktionalitet på distans utan att släppa en ny version. Firebase Remote Config gör det möjligt att ändra appens beteende utan publicering i butiken.

Gradvis utrullning — släpp den nya versionen för 5% av publiken och övervaka kraschfrekvensen. Om frekvensen förblir under målet (vanligtvis <0,1%), expandera till 25%, sedan 50%, sedan 100%. Google Play Console och App Store Connect stöder stegvis utrullning för automatisk stopp när tröskeln överskrids.

Handlingsplan vid upptäckt av fel

1: Klassificering — bestäm allvarlighetsgrad: Critical (krasch hos >1% av användarna), High (0,1–1%), Medium (<0,1%). För Critical-krascher — omedelbar respons. Google Play Console klassificerar automatiskt krascher efter antalet drabbade användare.

2: Stack trace-analys — öppna loggen i Crashlytics, se den exakta platsen för felet. Kontrollera anpassade nycklar: vilken skärm, vilken data, OS-version. Jämför med senaste driftsättningen — ofta orsakas kraschen av en nylig ändring i koden som påverkade ett oväntat användningsscenario.

3: Reproduktion — försök att reproducera kraschen på en enhet eller emulator med liknande parametrar. Om det inte lyckas, undersök kraschloggen efter mönster: specifika modeller (Samsung A10), Android-versioner (API < 26), locale. Lösning — lägg till ett skyddsvillkor som täcker scenariot.

4: Fix och övervakning — släpp en hotfix med prioritet. Efter releasen, säkerställ att kraschfrekvensen för denna typ sjunker till noll. Skriv ett regressionstest som täcker kraschscenariot. Utan test kan samma bugg återkomma vid nästa omfaktorisering.