Firebase Crashlytics — co to je, crashy a diagnostika selhání

Co je Firebase Crashlytics

Firebase Crashlytics je bezplatná služba Google pro monitorování stability mobilních aplikací, kterou Google koupil v roce 2017 spolu se společností Fabric. Crashlytics automaticky shromažďuje informace o každém selhání aplikace, seskupuje identické crashy podle podpisu zásobníku a zobrazuje je v konzoli Firebase s prioritizací podle počtu postižených uživatelů.

Historie a vývoj

Crashlytics byl spuštěn v roce 2011 jako součást platformy Fabric a rychle se stal de facto standardem pro hlášení crashů v iOS. Po akvizici Googlem v roce 2017 za odhadovaných 2 miliardy dolarů (celý Fabric) byl Crashlytics integrován do Firebase SDK. Verze 18.0.0 (2021) přidala podporu pro Kotlin Multiplatform a verze 19.0.0 (2024) — automatický sběr ANR na Androidu bez dodatečné konfigurace. Podle údajů Google (2026) Crashlytics zpracovává více než 10 miliard crashů měsíčně.

Bezplatné limity Crashlytics

Crashlytics je poskytován zdarma s limitem 500 tisíc relací denně na jeden projekt Firebase. Pro většinu aplikací to stačí — podle údajů Google (2026) 95% projektů limit nepřekračuje. Při překročení se sběr dat nezastaví, ale zprávy se přestanou aktualizovat do následujícího dne. Pro projekty s vysokým zatížením jsou k dispozici tarify Spark a Blaze Firebase — Crashlytics zůstává zdarma na obou tarifech a limit relací se počítá samostatně.

Jak Crashlytics detekuje a sbírá selhání

Mechanismus sběru Crashlytics je založen na zachycování výjimek na úrovni platformy a běhového prostředí. Na Androidu SDK implementuje UncaughtExceptionHandler, který zachycuje všechny neošetřené výjimky Kotlin a Java. Na iOS Crashlytics používá NSSetUncaughtExceptionHandler pro Objective-C/Swift a vlastní handler výjimek Mach pro crashy nativního kódu.

Typy zachycených selhání

Crashlytics rozlišuje pět typů selhání: fatal (fatální crashy), non-fatal (nefatální výjimky předané ručně), ANR (Android — aplikace neodpovídá), signal (signály OS — SIGSEGV, SIGABRT) a OOM (nedostatek paměti na iOS). Každý typ je zpracováván samostatným mechanismem a v konzoli je zobrazen s odpovídajícím štítkem.

Formát zprávy o selhání

Každá zpráva Crashlytics obsahuje vyčerpávající informace: úplné sledování zásobníku s názvy tříd a čísly řádků, verzi aplikace (versionName + versionCode), model zařízení, verzi OS, množství volné paměti, orientaci obrazovky a čas od spuštění. Pokud je připojeno Firebase Analytics, zpráva také obsahuje cestu posledních 50 událostí uživatele před selháním — to je kritické pro reprodukci crashu.

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

Integrace Crashlytics do projektu Android

Připojení Crashlytics k aplikaci pro Android vyžaduje přidání dvou závislostí v build.gradle a konfiguraci pluginu Google Services. SDK automaticky aktivuje hlášení crashů při inicializaci Firebase bez dalšího kódu. Pro správnou funkci jsou také vyžadovány plugin google-services a soubor google-services.json z konzole 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")
}

Konfigurace pluginu Crashlytics

Plugin com.google.firebase.crashlytics provádí dva úkoly: generuje jedinečný identifikátor sestavení (build ID) pro mapování zatemněných zásobníků a automaticky vytváří zdroje pro Crashlytics SDK. Bez pluginu budou crashy označeny jako "unmapped" — uvidíte pouze zatemněné názvy tříd (a.b.c) bez možnosti najít zdrojový kód. Plugin se přidává do kořenového build.gradle a do build.gradle modulu aplikace.

Kontrola integrace

Pro testování integrace Crashlytics se používá speciální metoda forceCrash(), která generuje testovací výjimku. V produkčních sestaveních tato metoda není k dispozici. Po spuštění testovacího crashu se zpráva objeví v konzoli Firebase během 1-5 minut. Pokud se zpráva nezobrazí — zkontrolujte, zda google-services.json odpovídá balíčku aplikace a zda v AndroidManifest nejsou příznaky vypínající sběr dat.

Analýza crashů a seskupování zpráv

Konzole Crashlytics poskytuje dvě úrovně zobrazení: seznam všech crashů (Issues) seskupených podle typu selhání a podrobnou zprávu pro každý Issue se sledováním, statistikami a uživatelskými daty. Každý Issue spojuje všechny crashy se stejným podpisem — stejným typem výjimky a odpovídajícím sledováním zásobníku.

Issues a seskupování

Seskupování crashů — klíčová vlastnost Crashlytics. Místo zobrazování tisíců jednotlivých crashů je služba spojuje do Issues na základě fingerprint — kontrolního součtu sledování zásobníku. Jeden Issue může obsahovat 1 až několik milionů crashů. Pro každý Issue se zobrazuje: počet fatálních případů, počet jedinečných uživatelů, verze aplikace, ve které se crash objevil, a procento uživatelů, kteří se s problémem setkali.

Podle údajů Google (2026) v průměru 20% Issues tvoří 80% všech fatálních crashů aplikace (Paretův princip). Crashlytics automaticky řadí Issues podle závažnosti — čím více uživatelů je postiženo, tím vyšší je priorita. To umožňuje vývojáři opravovat nejprve nejmasivnější problémy.

Statistiky podle verzí

Crashlytics sleduje stabilitu každé verze aplikace samostatně. Graf crash-free users ukazuje procento uživatelů, kteří se nesetkali s fatálním crashem v každé verzi. Pokud při aktualizaci procento klesne pod práh (výchozí 99%), Crashlytics odešle upozornění e-mailem a v konzoli Firebase. To umožňuje rychlé stažení problematické verze nebo vydání hotfixu.

Vlastní klíče, protokoly a Breadcrumbs

Crashlytics poskytuje tři mechanismy pro obohacení zpráv o kontext: vlastní klíče (keys) pro strukturovaná data, protokoly (logs) pro textové sledování a Breadcrumbs z Analytics pro cestu uživatele. Všechny tři typy dat jsou připojeny ke zprávě o crashu a jsou viditelné v její podrobné kartě.

Vlastní klíče

Custom Keys — jsou páry "klíč-hodnota", které jsou přenášeny spolu s každým crashem. Maximálně 64 klíčů na aplikaci, každý klíč — řetězec o délce až 1024 znaků. Klíče jsou vhodné pro označování stavu aplikace: úroveň předplatného, stav autorizace, poslední obrazovka, zda je zapnutý VPN. Hodnoty se přepisují — nový klíč se stejným názvem nahrazuje starý.

Protokolování událostí

Custom Logs — jsou textové zprávy, které Crashlytics ukládá do kruhového bufferu o velikosti 64 KB. Protokoly se automaticky připojí k dalšímu crashu. Pokud k crashu nedojde — protokoly se neodesílají na server (nespotřebovávají přenos). Protokolování se používá k zaznamenávání kroků uživatele před selháním: "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 z Analytics

Pokud je v projektu připojeno Firebase Analytics, Crashlytics automaticky získává Breadcrumbs — posledních 50 analytických událostí před crashem. Každá breadcrumb obsahuje název události a její parametry. To umožňuje rekonstruovat přesnou posloupnost akcí, které vedly k selhání: uživatel otevřel obrazovku → přidal produkt → přešel k platbě → došlo k crashi. Breadcrumbs se zobrazují v kartě Issue na samostatné záložce "Logs".

Nejlepší postupy práce se selháními

Crashlytics je nejúčinnější při správné konfiguraci kontextu a procesu zpracování Issues. Praxe ukazuje, že týmy, které zavedly pravidla pro práci s crashe, zkracují dobu opravy kritických chyb o 60% (údaje Google, 2026).

Prioritizace Issues

Ne všechny crashy jsou stejně důležité. Prioritizace podle počtu uživatelů a frekvence výskytu pomáhá soustředit se na nejkritičtější problémy. Pravidlo: opravujte Issues postihující více než 0.1% uživatelů do 24 hodin. Issues s ojedinělými výskyty (< 0.01%) lze odložit do dalšího plánovaného vydání. Crashlytics automaticky označuje regrese — Issues, které byly opraveny, ale znovu se objevily v nové verzi.

Integrace s CI/CD

Crashlytics API umožňuje integraci hlášení o selháních do pipeline CI/CD prostřednictvím REST API nebo Firebase CLI. Při každém novém vydání lze automaticky zkontrolovat, zda procento crash-free users nepřekračuje prahovou hodnotu. Pokud je práh překročen — CI/CD blokuje nasazení a odešle upozornění týmu. Firebase CLI podporuje příkaz firebase crashlytics:builds:upload pro nahrávání mapovacích souborů ProGuard/R8 — bez nich budou zásobníky nečitelné.

Podle údajů Google (2026) aplikace používající automatickou kontrolu crash-free prahů v CI/CD vypouštějí o 40% méně regresí do produkce. Doporučený práh: crash-free users >= 99.5% pro kritická vydání a >= 99.0% pro běžná vydání.