Crash Reporting i mobilutveckling — vad det är, tjänster och konfiguration

Vad är Crash Reporting?

Crash Reporting — är processen för automatisk insamling av teknisk information om applikationskrascher och centraliserad överföring till en server för analys. Till skillnad från loggning registrerar crash-reporting endast nödsituationer — ögonblicket när applikationen tvångsavslutades av systemet eller operativsystemet.

Varje kraschrapport innehåller tre nyckelkomponenter: undantagstyp (NullPointerException, SIGSEGV, NSInternalInconsistencyException), en fullständig anropsstack med radnummer och miljöinformation — OS-version, enhetsmodell, mängden ledigt minne. Enligt Sentry Engineering, 2024 gör kombinationen av dessa tre element det möjligt att återskapa och åtgärda 85% av kritiska fel.

Moderna crash-reporting-system utökar funktionaliteten bortom vanliga krascher. Firebase Crashlytics grupperar automatiskt återkommande krascher i issues, Sentry spårar regressioner mellan releaser och Bugsnag visar användarens väg till felet. Alla tre tjänsterna stödjer iOS, Android, React Native och Flutter.

Enligt Google I/O 2024 lägger applikationer utan crash-reporting i genomsnitt 3–5 arbetsdagar på att diagnostisera ett enda kritiskt fel, medan det med Crashlytics tar 15–30 minuter. Tidsbesparingen är över 90% för varje incident.

Hur fungerar systemet för insamling av kraschrapporter

Arkitekturen för ett crash-reporting-system består av tre lager: klient-SDK installerad i applikationen, server-API för att ta emot och bearbeta rapporter och en webbdashboard för analys. Klient-SDK fångar ohanterade undantag, serialiserar dem till JSON och skickar dem till servern vid nästa start av applikationen.

Att skicka en kraschrapport sker asynkront efter omstart av applikationen. Detta är en avgörande punkt: vid kraschögonblicket kan applikationen inte garantera att data skickas framgångsrikt över nätverket. SDK sparar rapporten i lokal lagring och skickar den vid nästa start via en bakgrundstråd. Enligt Firebase Engineering, 2024 säkerställer detta tillvägagångssätt leverans av 99.7% av kraschrapporterna.

För icke-fatala undantag (hanterade undantag inom try-catch) skickar SDK rapporten omedelbart, eftersom applikationen fortsätter att fungera. Icke-fatala rapporter innehåller samma data som krascher, men avbryter inte användarsessionen. Detta är särskilt användbart för att spåra API-fel, datavalidering och affärslogik.

Kraschgruppering — en serveralgoritm som kombinerar identiska krascher baserat på hash av de senaste 5–10 stackramarna. Detta gör att utvecklaren kan se inte 1000 enskilda rapporter, utan ett issue med 1000 förekomster som täcker olika enheter och OS-versioner.

Firebase Crashlytics: integration och möjligheter

Firebase Crashlytics — den populäraste crash-reporting-tjänsten för mobilapplikationer, som används i över 3 miljoner projekt världen över. Den kostnadsfria planen inkluderar obegränsade rapporter, integration med Google Analytics och automatisk kraschgruppering.

Integrera Crashlytics på Android

Anslutning av Crashlytics på Android är minimal: lägg till beroendet i build.gradle och initiera SDK i Application.onCreate. Crashlytics ställer automatiskt in sin egen Thread.setDefaultUncaughtExceptionHandler, som fångar alla ohanterade undantag.

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

Nyckelfunktion i Crashlytics — anpassade nycklar och loggar. Utvecklaren kan lägga till upp till 64 nyckel-värde-par till varje kraschrapport: skärmstatus, vald plan, användarnivå. Det går också att spela in anpassade loggmeddelanden som kommer in i rapporten i kronologisk ordning.

Velocity Alert — automatisk regressionsdetektering

Velocity Alert — en Crashlytics-funktion som övervakar en plötslig ökning av antalet krascher för ett specifikt issue. Om antalet krascher efter en ny release överstiger tröskelvärdet får teamet ett push-meddelande och e-post 5–15 minuter innan massiva användarklagom.

Inställning av utlösningströskel: 2x på 1 timme för kritiska issues. Enligt Google, 2024 släpper team med aktiverat Velocity Alert hotfix-versioner i genomsnitt 40% snabbare än team som förlitar sig på manuell övervakning av dashboarden.

Integrera Crashlytics på iOS

På iOS integreras Crashlytics SDK via CocoaPods eller Swift Package Manager. SDK fångar både Objective-C-undantag (via NSSetUncaughtExceptionHandler) och OS-signaler (SIGSEGV, SIGABRT) via sin egen mach exception handler.

Enligt Apple Developer, 2024 behandlar Crashlytics för iOS upp till 98% av alla kraschtyper, inklusive lågnivåminnesfel som inte fångas av standardmekanismer. Detta gör Crashlytics till de facto-standard för iOS-utveckling.

Sentry och Bugsnag: alternativa plattformar

Sentry — en öppen källkodsplattform för övervakning av fel som stödjer 80+ språk och ramverk. Till skillnad från Crashlytics är Sentry inriktat på backend-utvecklare, men erbjuder fullständiga SDK:er för iOS, Android, React Native och Flutter.

Den största fördelen med Sentry — Performance Monitoring i en enda dashboard. Utvecklaren ser inte bara krascher utan även de transaktioner som ledde till dem: långsamma nätverksförfrågningar, UI-frysningar, långa databasoperationer. Enligt Sentry, 2024 har 40% av krascherna föregående prestandaproblem som förblir oupptäckta utan ett sådant tillvägagångssätt.

Bugsnag utmärker sig genom sitt sätt att gruppera fel — istället för anropsstacken analyserar det användarens resa (user journey). Varje kraschrapport innehåller en sekvens av skärmar och användaråtgärder som ledde till felet. Detta är särskilt användbart för komplexa affärsprocesser: beställning, registrering, betalning.

Priserna för tjänsterna varierar: Crashlytics är gratis inom Firebase, Sentry erbjuder en gratisplan för 5000 händelser per månad, Bugsnag från $29 per månad. Alla tre plattformarna tillhandahåller SDK:er med öppen källkod. Valet av tjänst beror på teamets storlek, budget och dataskyddskrav.

Crash Reporting på iOS: egenskaper och NSException

Egenskapen för iOS — en flerskiktad arkitektur för felhantering. Crash-reporting SDK:er måste fånga Objective-C-undantag (NSException), Swift-fel (Error), POSIX-signaler (SIGSEGV, SIGBUS) och mach-undantag. Varje typ kräver en separat fångstmekanism.

NSException — den enklaste typen att fånga via NSSetUncaughtExceptionHandler. Men enligt Apple, 2024 är endast 30% av krascherna i moderna Swift-applikationer NSException. De återstående 70% är OS-signaler och Swift runtime-fel som kräver mekanismen mach exception handler.

iOS-utvecklare bör testa crash-reporting genom lokal generering av krascher av olika typer: __builtin_trap() för signaler, [NSException raise:...] för undantag, fatalError() för Swift. Endast på så sätt kan man säkerställa att SDK täcker alla kraschtyper.

Crash Reporting på Android: ANR och native-krascher

Android lägger till två specifika kraschtyper som inte finns på iOS: ANR (Application Not Responding) och native-krascher i C/C++-kod. ANR inträffar när UI-tråden är blockerad i mer än 5 sekunder — systemet visar en dialogruta ”Applikationen svarar inte” och erbjuder att stänga den.

Standard Thread.setDefaultUncaughtExceptionHandler fångar inte ANR, eftersom det inte är ett undantag utan en signal från ActivityManager. För att övervaka ANR använder Crashlytics och Sentry en watchdog-tråd i bakgrunden som kontrollerar UI-trådens responsivitet var 5:e sekund. Enligt Firebase, 2024 är 15% av alla problem på Android ANR, inte krascher.

Native-krascher på Android uppstår i C/C++-kod som körs via JNI (Java Native Interface). Dessa krascher är inte Java-undantag och fångas inte av Thread.setDefaultUncaughtExceptionHandler. För att hantera dem används Google Breakpad eller Crashpad, som installerar sigaction-hanterare för signalerna SIGSEGV, SIGABRT, SIGBUS.

Enligt Google I/O 2024 ökar antalet native-krascher med spridningen av spelmotorer (Unity, Unreal Engine) och bibliotek för datorseende (ML Kit, OpenCV). Utvecklare av hybridapplikationer rekommenderas att alltid ansluta native crash-reporting.