Crash i mobilutveckling: vad det är, typer och förebyggandemetoder

Vad är en Crash

Crash — är oväntad avslutning av en applikation orsakad av ett ohanterat undantag eller en allvarlig systemsignal som inte hanterades i applikationskoden. När systemet eller den virtuella maskinen (JVM, ART) upptäcker ett allvarligt tillstånd — NullPointerException, IndexOutOfBoundsException, OutOfMemoryError — stoppar den omedelbart processen och tar bort den från minnet. Användaren ser applikationen plötsligt stängas utan något systemfelmeddelande. Enligt Google förlorar applikationer med en crash-free-rate under 99% upp till 20% av sina aktiva användare per månad.

På Android skiljer sig mekanismen för kraschhantering från stationära system. Istället för en felsökningsdialog med stacktrace dödar Android helt enkelt processen och sparar inte detaljerad information. Insamling av kraschinformation är uppgiften för tredjepartsbibliotek (Crashlytics, Sentry, Bugsnag), som fångar undantag via Thread.setDefaultUncaughtExceptionHandler innan processen avslutas.

iOS använder en liknande mekanism med NSException och Mach exceptions för att hantera allvarliga fel. Vid ett ohanterat undantag avslutar systemet applikationen och rapporten sparas som en .crash-fil. Insamling av krascher på iOS kräver integrering med Crashlytics eller inbyggd rapport via Xcode Organizer.

Huvudtyper av krascher

Fem kategorier av krascher täcker 90% av alla krascher i mobila applikationer. Att förstå varje typ hjälper till att snabbare diagnostisera och åtgärda problem i produktionsmiljön.

NullPointerException — kraschkungen

NullPointerException (NPE) — den vanligaste typen av krasch i alla Java/Kotlin-applikationer. Uppstår vid försök att anropa en metod eller komma åt ett fält i ett objekt som är null. Typiska scenarier: oinitierat Activity-fält vid skärmrotation, null-svar från servern vid JSON-deserialisering, oaktsam navigering genom RecyclerView-adaptern.

Kotlin löser NPE-problemet på språknivå genom null-säkra typer: String? kan inte användas utan explicit kontroll. Java-kompatibilitet och Reflection skapar dock fortfarande risker. Använd @NonNull- och @Nullable-annotationer och aktivera strictNullChecks i verktyg för statisk analys.

fun safeLength(text: String?): Int {
    return text?.length ?: 0 // säker null-hantering
}

IndexOutOfBoundsException och samlingsfel

IndexOutOfBoundsException uppstår vid åtkomst av ett obefintligt index i en lista eller array. Vanligt scenario: borttagning av ett element från RecyclerView utan synkronisering med adaptern, flertrådig modifiering av ArrayList utan låsning, felaktig positionsberäkning i ViewPager. ConcurrentModificationException — en nära släkting vid samtidig iteration och modifiering av samlingar.

Använd CopyOnWriteArrayList för flertrådig åtkomst eller låsfria samlingar från java.util.concurrent. För synkronisering med UI, använd DiffUtil, som säkert och effektivt beräknar skillnaden mellan gamla och nya listan.

ClassCastException — typiska problem

ClassCastException uppstår vid konvertering av ett objekt till en inkompatibel typ. I Android typiska orsaker: felaktig ViewHolder-typ i RecyclerView (olika celltyper utan korrekt getItemViewType), felaktig Fragment-konvertering vid navigering, Serializable-objekt med olika klassversioner.

Använd Kotlins säkra konvertering via operatorn as?, som returnerar null vid typinkompatibilitet. I Java — kontroll via instanceof före konvertering. För Parcelable-objekt måste CREATOR deklareras i varje klass.

IllegalStateException och logiska fel

IllegalStateException signalerar anrop av en metod i ett olämpligt objektillstånd. Typiskt exempel i Android — getSupportFragmentManager() efter onSaveInstanceState, när commit() av fragmentet inte är tillåten. Ett annat vanligt fall — anrop av dismiss() på en redan stängd dialogruta.

Kontrollera livscykelns tillstånd före operationer med FragmentManager. Använd commitAllowingStateLoss() endast när du är säker på att tillståndsförlust inte är kritisk. I Kotlin, skapa DSL-liknande byggare som utesluter felaktiga tillstånd på typnivå.

Native Crash (SIGSEGV, SIGABRT-signaler)

Native Crash uppstår i nativ C/C++-kod vid minnesöverträdelse: åtkomst via null-pekare, double-free, stack buffer overflow. I Android uppstår sådana krascher i NDK-bibliotek, spelmotorer (Unity, Unreal) och systemberoenden. Native Crash fångas INTE av Thread.setDefaultUncaughtExceptionHandler — den dödar processen omedelbart.

För diagnos av nativa krascher, använd minidump-filer (Breakpad) eller Android tombstone. Firebase Crashlytics stöder insamling av nativa krascher via NDK SDK. På iOS löses liknande problem via PLCrashReporter.

Verktyg för kraschrapportering

Tre verktyg dominerar marknaden för mobil kraschrapportering. Varje erbjuder insamling av stacktrace, aggregering efter applikationsversion och aviseringar om nya krascher.

Firebase Crashlytics

Crashlytics — den mest populära kraschrapporteraren för mobila applikationer, en del av Firebase-ekosystemet. Den samlar automatiskt in stacktrace, enhetsdata, OS-version och anpassade användarnycklar. Integration tar 10 minuter via Firebase Console och Gradle Plugin. Crashlytics stöder också verkliga loggar (Logcat) och anpassad spårning.

FirebaseCrashlytics.getInstance()
    .setCustomKey("current_screen", "ProfileFragment")

FirebaseCrashlytics.getInstance()
    .log("User tapped login button")

Sentry

Sentry — ett alternativ till Crashlytics med ett mer flexibelt filtreringssystem och stöd för 90+ plattformar. Till skillnad från Firebase erbjuder Sentry en självhostad server (self-hosted) för företag med strikta datakrav. Sentry stöder distributiv spårning, breadcrumbs och integration med CI/CD-pipelines.

Bugsnag och AppCenter

Bugsnag utmärker sig med stöd för allvarlighetsbaserade aviseringar: delar in krascher i kritiska, fel och varningar. AppCenter från Microsoft — ett gratis verktyg med grundläggande funktionalitet för små projekt. Båda stöder Android, iOS, React Native och Flutter.

Hur man analyserar en krasch

Analys av en krasch är processen att rekonstruera den fullständiga bilden av händelsen. Stacktrace visar bara den sista felpunkten men ger inte kontexten som ledde till problemet. En professionell metod omfattar fyra steg.

Första steget — läsa stacktrace. Bestäm klassen, metoden och kodraden där undantaget inträffade. Följ anropskedjan från den övre ramen till den nedre: den sista raden i stacken är kraschplatsen, och de övre raderna är anropssekvensen. Deobfuskering (ProGuard/R8-mappning) är obligatorisk för produktionsbyggen.

Andra steget — enhetskontext. Crashlytics visar enhetsmodell, OS-version, tillgängligt minne och applikationsversion. Till exempel, en krasch endast på Samsung Galaxy S10 med Android 11 indikerar ett problem med en specifik version av One UI, inte ett allmänt kodfel.

Tredje steget — reproduktion på en testenhet. Om kraschen inte reproduceras stabilt, fråga användaren om exakta steg eller använd Remote Config för loggning före den problematiska kodsektionen. AB-testning av fixen på en del av publiken hjälper till att bekräfta lösningen.

Fjärde steget — övervakning efter fixen. Efter publicering av fixen, observera kraschfrekvensen i 3–5 dagar. Om kraschen helt försvann — fungerade fixen. Om frekvensen minskade men inte gick till noll — finns ett andra scenario som kräver separat analys.

Metoder för att förebygga krascher

Systematisk metod för att förebygga krascher omfattar verktyg för statisk analys, obligatorisk testning av kantfall och korrekt felhantering på alla nivåer i applikationen.

Statisk kodanalys

Detekt (Kotlin) och Lint (Android) hittar potentiella problem i kompileringsfasen: oanvända variabler, potentiella NPE, felaktig API-användning. Aktivera dessa verktyg i CI-pipelinen med en feltröskel. Till exempel, Detekt med konfiguration på 30+ varningar eller något error-blocking släpper inte igenom bygget.

Enhetstester och UI-tester

Täckning av viktiga användningsscenarier med enhetstester är grundläggande skydd mot regressionskrascher. Testa datamodeller, ViewModel och UseCase-lager med kantfall: null-värden, tomma listor, ogiltig JSON. UI-tester via Espresso eller Compose Test täcker kritiska flöden: autentisering, betalning, introduktion.

Graceful Degradation

Designa applikationen så att ett fel i en modul inte kraschar hela skärmen. Använd catch-block på ViewModel-nivå med returnering av reservtillstånd: visa en placeholder istället för lista, cachad data vid nätverksbrist, reservbild vid laddningsfel. Detta förvandlar en potentiell krasch till ett kontrollerat UX-scenario.

Stegrad utrullning med övervakning

Staged rollouts — standardpraxis för Google Play och App Store: en ny version distribueras till 5%, sedan 20% och slutligen 100% av publiken med 1–3 dagars intervall. I varje steg övervakas kraschfrekvensen: om crash-free-raten faller under 99,5% stoppas utrullningen automatiskt. Firebase Remote Config gör det möjligt att inaktivera problematiska funktioner utan att publicera en ny version.

Versionskontroll av beroenden

Renovate eller Dependabot i CI kontrollerar automatiskt bibliotek för kända sårbarheter och kritiska buggar. Uppdatering av ett enda beroende kan eliminera en hel klass av krascher. Testa dock uppdateringar i en staging-miljö före utrullning till produktion — den nya versionen av biblioteket kan innehålla inkompatibla ändringar.