Firebase Crashlytics — cos'è, crash e diagnosi degli arresti anomali

Cos'è Firebase Crashlytics

Firebase Crashlytics è un servizio gratuito di Google per il monitoraggio della stabilità delle applicazioni mobili, acquisito da Google nel 2017 insieme all'azienda Fabric. Crashlytics raccoglie automaticamente le informazioni su ogni arresto anomalo dell'applicazione, raggruppa i crash identici per firma dello stack e li visualizza nella console Firebase con priorità basata sul numero di utenti interessati.

Storia ed evoluzione

Crashlytics è stato lanciato nel 2011 come parte della piattaforma Fabric ed è diventato rapidamente lo standard de facto per il crash-reporting su iOS. Dopo l'acquisizione da parte di Google nel 2017 per circa 2 miliardi di dollari (l'intera Fabric), Crashlytics è stato integrato nell'SDK Firebase. La versione 18.0.0 (2021) ha aggiunto il supporto per Kotlin Multiplatform, e la versione 19.0.0 (2024) ha introdotto la raccolta automatica degli ANR su Android senza configurazione aggiuntiva. Secondo Google (2026), Crashlytics elabora oltre 10 miliardi di crash al mese.

Limiti gratuiti di Crashlytics

Crashlytics è gratuito con un limite di 500 mila sessioni al giorno per progetto Firebase. Per la maggior parte delle applicazioni questo è sufficiente — secondo Google (2026), il 95% dei progetti non supera il limite. In caso di superamento, la raccolta dati non si ferma, ma i report smettono di aggiornarsi fino al giorno successivo. Per i progetti ad alto carico sono disponibili i piani Spark e Blaze di Firebase — Crashlytics rimane gratuito su entrambi i piani e il limite di sessioni è conteggiato separatamente.

Come Crashlytics rileva e raccoglie gli arresti

Il meccanismo di raccolta di Crashlytics si basa sull'intercettazione delle eccezioni a livello di piattaforma e runtime. Su Android, l'SDK implementa UncaughtExceptionHandler, intercettando tutte le eccezioni non catturate Kotlin e Java. Su iOS, Crashlytics utilizza NSSetUncaughtExceptionHandler per Objective-C/Swift e un proprio gestore di eccezioni Mach per i crash del codice nativo.

Tipi di arresti intercettati

Crashlytics distingue cinque tipi di arresti: fatal (crash fatali), non-fatal (eccezioni non fatali trasmesse manualmente), ANR (Android — applicazione che non risponde), signal (segnali OS — SIGSEGV, SIGABRT) e OOM (out of memory su iOS). Ogni tipo viene elaborato da un meccanismo separato e visualizzato nella console con l'etichetta corrispondente.

Formato del report di arresto

Ogni report Crashlytics contiene informazioni complete: tracciamento completo dello stack con nomi delle classi e numeri di riga, versione dell'applicazione (versionName + versionCode), modello del dispositivo, versione del sistema operativo, quantità di memoria libera, orientamento dello schermo e tempo trascorso dall'avvio. Se Firebase Analytics è collegato, il report include anche il percorso degli ultimi 50 eventi utente prima dell'arresto — questo è fondamentale per riprodurre il crash.

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

Integrazione di Crashlytics in un progetto Android

La connessione di Crashlytics a un'applicazione Android richiede l'aggiunta di due dipendenze in build.gradle e la configurazione del plugin Google Services. L'SDK collega automaticamente il crash-reporting all'inizializzazione di Firebase senza codice aggiuntivo. Per un corretto funzionamento sono necessari anche il plugin google-services e il file google-services.json dalla console Firebase.

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

// build.gradle (livello applicazione)
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")
}

Configurazione del plugin Crashlytics

Il plugin com.google.firebase.crashlytics svolge due compiti: genera un identificatore univoco di build (build ID) per il mapping degli stack offuscati e crea automaticamente le risorse per l'SDK Crashlytics. Senza il plugin, i crash verranno contrassegnati come "non mappati" — vedrai solo nomi di classi offuscati (a.b.c) senza possibilità di trovare il codice sorgente. Il plugin viene aggiunto nel build.gradle root e nel build.gradle del modulo applicativo.

Verifica dell'integrazione

Per testare l'integrazione di Crashlytics si utilizza il metodo speciale forceCrash() che genera un'eccezione di test. Nelle build di produzione, questo metodo non è disponibile. Dopo l'esecuzione di un crash di test, il report appare nella console Firebase entro 1-5 minuti. Se il report non viene visualizzato, verifica che google-services.json corrisponda al package dell'applicazione e che AndroidManifest non contenga flag che disabilitano la raccolta dati.

Analisi dei crash e raggruppamento dei report

La console Crashlytics offre due livelli di visualizzazione: l'elenco di tutti i crash (Issues) raggruppati per tipo di arresto e il report dettagliato per ogni Issue con tracciamento, statistiche e dati personalizzati. Ogni Issue raggruppa tutti i crash con la stessa firma — lo stesso tipo di eccezione e lo stesso tracciamento dello stack.

Issues e raggruppamento

Il raggruppamento dei crash è una caratteristica chiave di Crashlytics. Invece di mostrare migliaia di crash individuali, il servizio li raggruppa in Issues sulla base di un'impronta digitale (fingerprint) — checksum del tracciamento dello stack. Un Issue può contenere da 1 a diversi milioni di crash. Per ogni Issue vengono visualizzati: numero di casi fatali, numero di utenti unici, versione dell'applicazione in cui il crash è apparso e percentuale di utenti che hanno riscontrato il problema.

Secondo Google (2026), in media il 20% degli Issues rappresenta l'80% di tutti i crash fatali di un'applicazione (principio di Pareto). Crashlytics ordina automaticamente gli Issues per gravità — più utenti sono interessati, maggiore è la priorità. Questo permette allo sviluppatore di correggere prima i problemi più massicci.

Statistiche per versione

Crashlytics monitora la stabilità di ogni versione dell'applicazione separatamente. Il grafico crash-free users mostra la percentuale di utenti che non hanno riscontrato crash fatali in ogni versione. Se durante un aggiornamento la percentuale scende sotto la soglia (default 99%), Crashlytics invia una notifica via email e nella Firebase Console. Ciò consente di tornare rapidamente a una versione stabile o pubblicare un hotfix.

Chiavi personalizzate, log e Breadcrumbs

Crashlytics fornisce tre meccanismi per arricchire i report con contesto: chiavi personalizzate (keys) per dati strutturati, log (logs) per tracciamento testuale e Breadcrumbs da Analytics per il percorso utente. Tutti e tre i tipi di dati vengono allegati al report di crash e sono visibili nella sua scheda dettagliata.

Chiavi personalizzate

Le Custom Keys sono coppie "chiave-valore" trasmesse con ogni crash. Massimo 64 chiavi per applicazione, ogni chiave è una stringa lunga fino a 1024 caratteri. Le chiavi sono utili per marcare lo stato dell'applicazione: livello di abbonamento, stato di autenticazione, ultima schermata, VPN attiva o meno. I valori vengono sovrascritti — una nuova chiave con lo stesso nome sostituisce la precedente.

Registrazione eventi

I Custom Logs sono messaggi testuali che Crashlytics conserva in un buffer circolare di 64 KB. I log vengono automaticamente allegati al crash successivo. Se non si verifica alcun crash, i log non vengono trasmessi al server (nessun consumo di traffico). La registrazione viene utilizzata per tracciare i passi dell'utente prima dell'arresto: "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 da Analytics

Se Firebase Analytics è collegato al progetto, Crashlytics riceve automaticamente i Breadcrumbs — gli ultimi 50 eventi di analisi prima del crash. Ogni breadcrumb contiene il nome dell'evento e i suoi parametri. Ciò consente di ricostruire la sequenza esatta di azioni che hanno portato all'arresto: l'utente ha aperto la schermata → aggiunto un prodotto → è passato al pagamento → si è verificato il crash. I Breadcrumbs vengono visualizzati nella scheda Issue nella scheda "Logs".

Buone pratiche per la gestione degli arresti

Crashlytics è più efficace con una corretta configurazione del contesto e un processo di gestione degli Issues. La pratica dimostra che i team che hanno implementato un regolamento per la gestione dei crash riducono il tempo di correzione dei bug critici del 60% (dati Google, 2026).

Prioritizzazione degli Issues

Non tutti i crash sono ugualmente importanti. La prioritizzazione per numero di utenti e frequenza aiuta a concentrarsi sui problemi più critici. Regola: correggere gli Issues che interessano più dello 0,1% degli utenti entro 24 ore. Gli Issues con occorrenze singole (< 0,01%) possono essere rimandati alla prossima versione pianificata. Crashlytics contrassegna automaticamente le regressioni — Issues che sono stati corretti ma ricompaiono in una nuova versione.

Integrazione con CI/CD

L'API Crashlytics consente di integrare i report di crash nel pipeline CI/CD tramite REST API o Firebase CLI. Ad ogni nuovo rilascio, puoi verificare automaticamente se la percentuale di utenti senza crash supera la soglia. Se la soglia viene superata, il CI/CD blocca il deploy e invia una notifica al team. Firebase CLI supporta il comando firebase crashlytics:builds:upload per il caricamento dei file di mapping ProGuard/R8 — senza di essi, gli stack saranno illeggibili.

Secondo Google (2026), le applicazioni che utilizzano la verifica automatica delle soglie crash-free in CI/CD pubblicano il 40% in meno di regressioni in produzione. Soglia raccomandata: crash-free users >= 99,5% per i rilasci critici e >= 99,0% per i rilasci normali.