Firebase Crashlytics — ce este, crash-uri și diagnosticarea defecțiunilor

Ce este Firebase Crashlytics

Firebase Crashlytics este un serviciu gratuit Google pentru monitorizarea stabilității aplicațiilor mobile, achiziționat de Google în 2017 împreună cu compania Fabric. Crashlytics colectează automat informații despre fiecare defecțiune a aplicației, grupează crash-urile identice după semnătura stivei și le afișează în consola Firebase cu prioritizare după numărul de utilizatori afectați.

Istorie și evoluție

Crashlytics a fost lansat în 2011 ca parte a platformei Fabric și a devenit rapid standardul de facto pentru raportarea crash-urilor în iOS. După achiziționarea de către Google în 2017 pentru o sumă estimată la 2 miliarde de dolari (întregul Fabric), Crashlytics a fost integrat în Firebase SDK. Versiunea 18.0.0 (2021) a adăugat suport pentru Kotlin Multiplatform, iar versiunea 19.0.0 (2024) — colectarea automată a ANR pe Android fără configurare suplimentară. Conform datelor Google (2026), Crashlytics procesează peste 10 miliarde de crash-uri lunar.

Limitele gratuite ale Crashlytics

Crashlytics este oferit gratuit cu o limită de 500 de mii de sesiuni pe zi per proiect Firebase. Pentru majoritatea aplicațiilor acest lucru este suficient — conform datelor Google (2026), 95% dintre proiecte nu depășesc limita. La depășire, colectarea datelor nu se oprește, dar rapoartele nu se mai actualizează până a doua zi. Pentru proiectele cu încărcare mare sunt disponibile tarifele Spark și Blaze Firebase — Crashlytics rămâne gratuit pe ambele tarife, iar limita de sesiuni se calculează separat.

Cum detectează și colectează Crashlytics defecțiunile

Mecanismul de colectare Crashlytics se bazează pe interceptarea excepțiilor la nivel de platformă și runtime. Pe Android, SDK-ul implementează UncaughtExceptionHandler, care interceptează toate excepțiile neprinse Kotlin și Java. Pe iOS, Crashlytics folosește NSSetUncaughtExceptionHandler pentru Objective-C/Swift și propriul handler de excepții Mach pentru crash-urile codului nativ.

Tipuri de defecțiuni interceptate

Crashlytics diferențiază cinci tipuri de defecțiuni: fatal (crash-uri fatale), non-fatal (excepții nefatale transmise manual), ANR (Android — aplicația nu răspunde), signal (semnale OS — SIGSEGV, SIGABRT) și OOM (memorie insuficientă pe iOS). Fiecare tip este procesat de un mecanism separat și este afișat în consolă cu o etichetă corespunzătoare.

Formatul raportului de defecțiune

Fiecare raport Crashlytics conține informații exhaustive: urmărirea completă a stivei cu nume de clase și numere de linii, versiunea aplicației (versionName + versionCode), modelul dispozitivului, versiunea OS, cantitatea de memorie liberă, orientarea ecranului și timpul de la pornire. Dacă Firebase Analytics este conectat, raportul include și calea ultimelor 50 de evenimente ale utilizatorului înainte de defecțiune — acest lucru este esențial pentru reproducerea crash-ului.

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")
    }
}

Integrarea Crashlytics în proiectul Android

Conectarea Crashlytics la o aplicație Android necesită adăugarea a două dependențe în build.gradle și configurarea plugin-ului Google Services. SDK-ul activează automat raportarea crash-urilor la inițializarea Firebase fără cod suplimentar. Pentru funcționarea corectă sunt necesare, de asemenea, plugin-ul google-services și fișierul google-services.json din consola Firebase.

// 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")
}

Configurarea plugin-ului Crashlytics

Plugin-ul com.google.firebase.crashlytics îndeplinește două sarcini: generează un identificator unic de build (build ID) pentru maparea stivelor ofuscate și creează automat resurse pentru Crashlytics SDK. Fără plugin, crash-urile vor fi marcate ca „unmapped" — veți vedea doar nume de clase ofuscate (a.b.c) fără posibilitatea de a găsi codul sursă. Plugin-ul se adaugă în build.gradle rădăcină și în build.gradle al modulului aplicației.

Verificarea integrării

Pentru testarea integrării Crashlytics se folosește metoda specială forceCrash(), care generează o excepție de test. În build-urile de producție această metodă nu este disponibilă. După rularea crash-ului de test, raportul apare în consola Firebase în 1-5 minute. Dacă raportul nu se afișează — verificați dacă google-services.json corespunde pachetului aplicației și dacă în AndroidManifest nu există flaguri care dezactivează colectarea datelor.

Analiza crash-urilor și gruparea rapoartelor

Consola Crashlytics oferă două niveluri de vizualizare: lista tuturor crash-urilor (Issues) cu grupare după tipul defecțiunii și raportul detaliat pentru fiecare Issue cu urmărire, statistici și datele utilizatorului. Fiecare Issue combină toate crash-urile cu aceeași semnătură — același tip de excepție și urmărirea stivei corespunzătoare.

Issues și gruparea

Gruparea crash-urilor — caracteristica cheie a Crashlytics. În loc să afișeze mii de crash-uri individuale, serviciul le combină în Issues pe baza fingerprint — suma de control a urmăririi stivei. Un Issue poate conține de la 1 până la câteva milioane de crash-uri. Pentru fiecare Issue se afișează: numărul de cazuri fatale, numărul de utilizatori unici, versiunea aplicației în care a apărut crash-ul și procentul de utilizatori care s-au confruntat cu problema.

Conform datelor Google (2026), în medie 20% dintre Issues reprezintă 80% din toate crash-urile fatale ale aplicației (principiul Pareto). Crashlytics sortează automat Issues după severitate — cu cât mai mulți utilizatori sunt afectați, cu atât prioritatea este mai mare. Acest lucru permite dezvoltatorului să remedieze mai întâi cele mai masive probleme.

Statistici pe versiuni

Crashlytics urmărește stabilitatea fiecărei versiuni a aplicației separat. Graficul crash-free users arată procentul de utilizatori care nu s-au confruntat cu un crash fatal în fiecare versiune. Dacă la actualizare procentul scade sub prag (implicit 99%), Crashlytics trimite o notificare prin e-mail și în Firebase Console. Acest lucru permite retragerea rapidă a versiunii problematice sau lansarea unui hotfix.

Chei personalizate, loguri și Breadcrumbs

Crashlytics oferă trei mecanisme pentru îmbogățirea rapoartelor cu context: chei personalizate (keys) pentru date structurate, loguri (logs) pentru urmărire textuală și Breadcrumbs din Analytics pentru calea utilizatorului. Toate cele trei tipuri de date sunt atașate raportului de crash și sunt vizibile în cardul său detaliat.

Chei personalizate

Custom Keys — sunt perechi „cheie-valoare" care sunt transmise împreună cu fiecare crash. Maximum 64 de chei per aplicație, fiecare cheie — un șir de caractere de până la 1024 de caractere. Cheile sunt convenabile pentru marcarea stării aplicației: nivelul abonamentului, starea de autentificare, ultimul ecran, dacă VPN-ul este activat. Valorile se suprascriu — o cheie nouă cu același nume o înlocuiește pe cea veche.

Logarea evenimentelor

Custom Logs — sunt mesaje text pe care Crashlytics le stochează într-un buffer circular de 64 KB. Logurile sunt atașate automat la următorul crash. Dacă nu apare niciun crash — logurile nu sunt transmise pe server (nu consumă trafic). Logarea este utilizată pentru înregistrarea pașilor utilizatorului înainte de defecțiune: „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 din Analytics

Dacă în proiect este conectat Firebase Analytics, Crashlytics primește automat Breadcrumbs — ultimele 50 de evenimente analitice înainte de crash. Fiecare breadcrumb conține numele evenimentului și parametrii săi. Acest lucru permite reconstituirea secvenței exacte de acțiuni care au dus la defecțiune: utilizatorul a deschis ecranul → a adăugat produsul → a trecut la plată → a avut loc un crash. Breadcrumbs sunt afișate în cardul Issue pe o filă separată „Logs".

Cele mai bune practici de lucru cu defecțiunile

Crashlytics este cel mai eficient atunci când contextul și procesul de procesare a Issues sunt configurate corect. Practica arată că echipele care au implementat un regulament de lucru cu crash-urile reduc timpul de remediere a bug-urilor critice cu 60% (date Google, 2026).

Prioritizarea Issues

Nu toate crash-urile sunt la fel de importante. Prioritizarea după numărul de utilizatori și frecvența de apariție ajută la concentrarea asupra celor mai critice probleme. Regula: remediați Issues care afectează mai mult de 0.1% dintre utilizatori în decurs de 24 de ore. Issues cu apariții unice (< 0.01%) pot fi amânate până la următoarea lansare planificată. Crashlytics marchează automat regresiile — Issues care au fost remediate, dar au reapărut într-o versiune nouă.

Integrarea cu CI/CD

Crashlytics API permite integrarea rapoartelor de defecțiuni în pipeline-ul CI/CD prin REST API sau Firebase CLI. La fiecare lansare nouă se poate verifica automat dacă procentul crash-free users nu depășește pragul. Dacă pragul este depășit — CI/CD blochează implementarea și trimite o notificare echipei. Firebase CLI suportă comanda firebase crashlytics:builds:upload pentru încărcarea fișierelor de mapare ProGuard/R8 — fără ele, stivele vor fi ilizibile.

Conform datelor Google (2026), aplicațiile care folosesc verificarea automată a pragurilor crash-free în CI/CD lansează cu 40% mai puține regresii în producție. Pragul recomandat: crash-free users >= 99.5% pentru lansările critice și >= 99.0% pentru cele obișnuite.