Firebase Crashlytics — vad är det, krascher och feldiagnostik

Vad är Firebase Crashlytics

Firebase Crashlytics är en gratis Google-tjänst för övervakning av stabiliteten i mobilapplikationer, som förvärvades av Google 2017 tillsammans med företaget Fabric. Crashlytics samlar automatiskt in information om varje applikationsfel, grupperar identiska krascher efter stacksignatur och visar dem i Firebase-konsolen med prioritering baserat på antalet drabbade användare.

Historia och utveckling

Crashlytics lanserades 2011 som en del av Fabric-plattformen och blev snabbt de facto-standard för krashrapportering i iOS. Efter förvärvet av Google 2017 för uppskattningsvis 2 miljarder dollar (hela Fabric) integrerades Crashlytics i Firebase SDK. Version 18.0.0 (2021) lade till stöd för Kotlin Multiplatform, och version 19.0.0 (2024) — automatisk ANR-insamling på Android utan extra konfiguration. Enligt data från Google (2026) bearbetar Crashlytics över 10 miljarder krascher varje månad.

Crashlytics gratis gränser

Crashlytics erbjuds gratis med en gräns på 500 tusen sessioner per dag per Firebase-projekt. För de flesta applikationer är detta tillräckligt — enligt data från Google (2026) överskrider 95% av projekten inte gränsen. Vid överskridande stoppas inte datainsamlingen, men rapporterna uppdateras inte förrän nästa dag. För projekt med hög belastning finns Spark- och Blaze-taxorna för Firebase — Crashlytics förblir gratis på båda taxorna och sessionsgränsen beräknas separat.

Hur Crashlytics upptäcker och samlar in fel

Insamlingsmekanismen i Crashlytics bygger på att fånga undantag på plattforms- och körningsnivå. På Android implementerar SDK:n en UncaughtExceptionHandler som fångar alla ohanterade Kotlin- och Java-undantag. På iOS använder Crashlytics NSSetUncaughtExceptionHandler för Objective-C/Swift och en egen Mach-undantagshanterare för krascher i nativ kod.

Typer av infångade fel

Crashlytics skiljer på fem typer av fel: fatal (dödliga krascher), non-fatal (icke-dödliga undantag som skickas manuellt), ANR (Android — applikationen svarar inte), signal (OS-signaler — SIGSEGV, SIGABRT) och OOM (minnesbrist på iOS). Varje typ hanteras av en separat mekanism och visas i konsolen med en motsvarande etikett.

Format för felrapport

Varje Crashlytics-rapport innehåller uttömmande information: fullständig stackspårning med klassnamn och radnummer, appversion (versionName + versionCode), enhetsmodell, OS-version, mängden ledigt minne, skärmorientering och tid sedan start. Om Firebase Analytics är anslutet innehåller rapporten även vägen för användarens senaste 50 händelser före felet — detta är avgörande för att reproducera kraschen.

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

Integrera Crashlytics i Android-projekt

Anslutning av Crashlytics till en Android-app kräver att två beroenden läggs till i build.gradle och att Google Services-plugin konfigureras. SDK:n aktiverar automatiskt krashrapportering vid initiering av Firebase utan extra kod. För korrekt funktion krävs även google-services-plugin och filen google-services.json från Firebase-konsolen.

// build.gradle (project-level)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (app-level)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

Konfiguration av Crashlytics-plugin

Plugin com.google.firebase.crashlytics utför två uppgifter: genererar ett unikt build-ID för mappning av obfuskerade stackar och skapar automatiskt resurser för Crashlytics SDK. Utan plugin kommer krascher att markeras som “unmapped” — du ser bara obfuskerade klassnamn (a.b.c) utan möjlighet att hitta källkoden. Plugin läggs till i rotens build.gradle och i appmodulens build.gradle.

Kontroll av integration

För testning av Crashlytics-integrationen används den speciella metoden forceCrash() som genererar ett testundantag. I produktionsbyggen är denna metod inte tillgänglig. Efter att testkraschen har körts visas rapporten i Firebase-konsolen inom 1-5 minuter. Om rapporten inte visas — kontrollera att google-services.json motsvarar appens paket och att det inte finns några flaggor i AndroidManifest som inaktiverar datainsamling.

Analys av krascher och gruppering av rapporter

Crashlytics-konsolen ger två visningsnivåer: en lista över alla krascher (Issues) grupperade efter feltyp, och en detaljerad rapport för varje Issue med stackspårning, statistik och användardata. Varje Issue kombinerar alla krascher med samma signatur — samma undantagstyp och matchande stackspårning.

Issues och gruppering

Gruppering av krascher — en nyckelfunktion i Crashlytics. Istället för att visa tusentals enskilda krascher kombinerar tjänsten dem i Issues baserat på fingerprint — kontrollsumman av stackspårningen. En Issue kan innehålla från 1 till flera miljoner krascher. För varje Issue visas: antalet dödliga fall, antalet unika användare, appversionen där kraschen uppstod och procentandelen användare som stötte på problemet.

Enligt data från Google (2026) utgör i genomsnitt 20% av Issues 80% av alla dödliga krascher i appen (Paretoprincipen). Crashlytics sorterar automatiskt Issues efter allvarlighetsgrad — ju fler användare som påverkas, desto högre prioritet. Detta gör att utvecklaren kan åtgärda de mest omfattande problemen först.

Statistik per version

Crashlytics övervakar stabiliteten för varje appversion separat. Diagrammet crash-free users visar andelen användare som inte har stött på en dödlig krasch i varje version. Om procentandelen vid en uppdatering sjunker under tröskelvärdet (standard 99%) skickar Crashlytics en avisering via e-post och i Firebase Console. Detta gör det möjligt att snabbt dra tillbaka den problematiska versionen eller släppa en hotfix.

Anpassade nycklar, loggar och Breadcrumbs

Crashlytics tillhandahåller tre mekanismer för att berika rapporter med sammanhang: anpassade nycklar (keys) för strukturerad data, loggar (logs) för textspårning och Breadcrumbs från Analytics för användarens väg. Alla tre datatyper bifogas till krashrapporten och är synliga i dess detaljkort.

Anpassade nycklar

Custom Keys — är nyckel-värdepar som skickas med varje krasch. Maximalt 64 nycklar per app, varje nyckel — en sträng med en längd på upp till 1024 tecken. Nycklar är praktiska för att markera appens tillstånd: prenumerationsnivå, autentiseringsstatus, senaste skärmen, om VPN är aktiverat. Värden skrivs över — en ny nyckel med samma namn ersätter den gamla.

Loggning av händelser

Custom Logs — är textmeddelanden som Crashlytics lagrar i en cirkulär buffert på 64 KB. Loggar bifogas automatiskt till nästa krasch. Om ingen krasch inträffar — skickas inte loggarna till servern (ingen dataförbrukning). Loggning används för att registrera användarens steg före felet: “payment_processing_started”, “api_call_initiated”, “response_received_200”.

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

Breadcrumbs från Analytics

Om Firebase Analytics är anslutet i projektet får Crashlytics automatiskt Breadcrumbs — de senaste 50 analytiska händelserna före kraschen. Varje breadcrumb innehåller händelsens namn och dess parametrar. Detta gör det möjligt att rekonstruera den exakta sekvensen av åtgärder som ledde till felet: användaren öppnade skärmen → lade till produkt → gick till betalning → krasch inträffade. Breadcrumbs visas i Issue-kortet på en separat flik “Logs”.

Bästa praxis för arbete med fel

Crashlytics är mest effektivt med korrekt konfiguration av sammanhang och process för Issues-hantering. Praxisen visar att team som har infört regler för arbete med krascher minskar tiden för att åtgärda kritiska buggar med 60% (data Google, 2026).

Prioritering av Issues

Alla krascher är inte lika viktiga. Prioritering baserat på antalet användare och förekomstfrekvens hjälper till att fokusera på de mest kritiska problemen. Regel: åtgärda Issues som påverkar mer än 0.1% av användarna inom 24 timmar. Issues med enstaka förekomster (< 0.01%) kan skjutas upp till nästa planerade release. Crashlytics markerar automatiskt regressioner — Issues som har åtgärdats men har dykt upp igen i en ny version.

Integration med CI/CD

Crashlytics API möjliggör integration av felrapporter i CI/CD-pipeline via REST API eller Firebase CLI. Vid varje ny release kan du automatiskt kontrollera om procentandelen crash-free users överstiger tröskelvärdet. Om tröskeln överskrids — blockerar CI/CD utrullningen och skickar en avisering till teamet. Firebase CLI stöder kommandot firebase crashlytics:builds:upload för uppladdning av ProGuard/R8-mappningsfiler — utan dem blir stackar oläsliga.

Enligt data från Google (2026) släpper appar som använder automatisk kontroll av crash-free-trösklar i CI/CD 40% färre regressioner till produktion. Rekommenderad tröskel: crash-free users >= 99.5% för kritiska releaser och >= 99.0% för vanliga releaser.