Crash Reporting v mobilním vývoji — co to je, služby a konfigurace

Co je Crash Reporting?

Crash Reporting — je proces automatického sběru technických informací o pádech aplikace a jejich centralizovaného odesílání na server k analýze. Na rozdíl od logování crash-reporting zaznamenává právě havarijní situace — okamžik, kdy byla aplikace násilně ukončena systémem nebo OS.

Každá crash zpráva obsahuje tři klíčové komponenty: typ výjimky (NullPointerException, SIGSEGV, NSInternalInconsistencyException), úplný zásobník volání s čísly řádků a informace o prostředí — verzi OS, model zařízení, množství volné paměti. Podle Sentry Engineering, 2024 právě kombinace těchto tří prvků umožňuje reprodukovat a opravit 85% kritických chyb.

Moderní crash-reporting systémy rozšiřují funkcionalitu nad rámec běžných crashů. Firebase Crashlytics automaticky seskupuje opakované pády do issues, Sentry sleduje regrese mezi verzemi a Bugsnag zobrazuje uživatelskou cestu k chybě. Všechny tři služby podporují iOS, Android, React Native a Flutter.

Podle Google I/O 2024 tráví aplikace bez crash-reportingu diagnostikou jedné kritické chyby v průměru 3–5 pracovních dnů, zatímco s Crashlytics — 15–30 minut. Úspora času činí více než 90% pro každý incident.

Jak funguje systém sběru crash zpráv

Architektura crash-reporting systému se skládá ze tří vrstev: klientský SDK nainstalovaný v aplikaci, serverové API pro příjem a zpracování zpráv a webový dashboard pro analýzu. Klientský SDK zachycuje neošetřené výjimky, serializuje je do JSON a odesílá na server při příštím spuštění aplikace.

Odeslání crash zprávy probíhá asynchronně po restartu aplikace. To je zásadní moment: v okamžiku crashu aplikace nemůže zaručit úspěšné odeslání dat po síti. SDK ukládá zprávu do lokálního úložiště a při příštím spuštění ji odesílá na pozadí. Podle Firebase Engineering, 2024 tento přístup zajišťuje doručení 99.7% crash zpráv.

Pro non-fatal výjimky (handled exceptions uvnitř try-catch) SDK odesílá zprávu okamžitě, protože aplikace pokračuje v činnosti. Non-fatal zprávy obsahují stejná data jako crash, ale nepřerušují uživatelskou relaci. To je užitečné zejména pro sledování chyb API požadavků, validace dat a business logiky.

Seskupování crashů — serverový algoritmus, který spojuje identické crashy na základě hashe posledních 5–10 rámců zásobníku. To umožňuje vývojáři vidět ne 1000 jednotlivých zpráv, ale jeden issue s 1000 výskyty, pokrývající různá zařízení a verze OS.

Firebase Crashlytics: integrace a možnosti

Firebase Crashlytics — nejoblíbenější služba crash-reportingu pro mobilní aplikace, používaná ve více než 3 milionech projektů po celém světě. Bezplatný tarif zahrnuje neomezený počet zpráv, integraci s Google Analytics a automatické seskupování crashů.

Integrace Crashlytics na Androidu

Připojení Crashlytics na Androidu je minimální: přidejte závislost do build.gradle a inicializujte SDK v Application.onCreate. Crashlytics automaticky nastaví vlastní Thread.setDefaultUncaughtExceptionHandler, zachycující všechny neošetřené výjimky.

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

Klíčová funkce Crashlytics — custom keys a logs. Vývojář může přidat až 64 párů klíč-hodnota ke každé crash zprávě: stav obrazovky, vybraný tarif, úroveň uživatele. K dispozici je také záznam vlastních log zpráv, které se dostávají do zprávy v chronologickém pořadí.

Velocity Alert — automatická detekce regresí

Velocity Alert — funkce Crashlytics, která sleduje prudký nárůst počtu crashů pro konkrétní issue. Pokud po nové verzi počet pádů překročí prahovou hodnotu, tým obdrží push notifikaci a e-mail 5–15 minut před hromadnými stížnostmi uživatelů.

Nastavení prahu spuštění: 2x za 1 hodinu pro kritické issues. Podle Google, 2024 týmy s aktivovaným Velocity Alert vydávají hotfix verze v průměru o 40% rychleji než týmy spoléhající na ruční monitorování dashboardu.

Integrace Crashlytics na iOS

Na iOS se Crashlytics SDK integruje přes CocoaPods nebo Swift Package Manager. SDK zachycuje jak Objective-C výjimky (přes NSSetUncaughtExceptionHandler), tak OS signály (SIGSEGV, SIGABRT) přes vlastní mach exception handler.

Podle Apple Developer, 2024 Crashlytics pro iOS zpracovává až 98% všech typů pádů, včetně nízkoúrovňových chyb paměti, které nejsou zachyceny standardními mechanismy. To činí Crashlytics de facto standardem pro iOS vývoj.

Sentry a Bugsnag: alternativní platformy

Sentry — open-source platforma pro monitorování chyb podporující 80+ jazyků a frameworků. Na rozdíl od Crashlytics je Sentry zaměřena na backendové vývojáře, ale poskytuje plnohodnotný SDK pro iOS, Android, React Native a Flutter.

Klíčová výhoda Sentry — Performance Monitoring v jediném dashboardu. Vývojář vidí nejen crash, ale také transakce, které k nim vedly: pomalé síťové požadavky, zamrzání UI, dlouhé operace s databází. Podle Sentry, 2024 má 40% crashů předchozí problémy s výkonem, které zůstávají bez tohoto přístupu nepovšimnuty.

Bugsnag se odlišuje přístupem k seskupování chyb — místo zásobníku volání analyzuje uživatelskou cestu (user journey). Každá crash zpráva obsahuje sekvenci obrazovek a akcí uživatele, které vedly k chybě. To je užitečné zejména pro složité business procesy: objednávka, registrace, platba.

Cena služeb se liší: Crashlytics je zdarma v rámci Firebase, Sentry nabízí bezplatný tarif na 5000 událostí měsíčně, Bugsnag od $29 měsíčně. Všechny tři platformy poskytují SDK s otevřeným zdrojovým kódem. Výběr služby závisí na velikosti týmu, rozpočtu a požadavcích na bezpečnost dat.

Crash Reporting na iOS: vlastnosti a NSException

Vlastnost iOS — vícevrstvá architektura zpracování chyb. Crash-reporting SDK musí zachycovat Objective-C výjimky (NSException), Swift chyby (Error), POSIX signály (SIGSEGV, SIGBUS) a mach-výjimky. Každý typ vyžaduje samostatný mechanismus zachycení.

NSException — nejjednodušší typ k zachycení přes NSSetUncaughtExceptionHandler. Podle Apple, 2024 je však pouze 30% crashů v moderních Swift aplikacích NSException. Zbývajících 70% tvoří OS signály a Swift runtime chyby, které vyžadují mechanismus mach exception handler.

Vývojáři iOS by měli testovat crash-reporting pomocí lokálního generování crashů různých typů: __builtin_trap() pro signály, [NSException raise:...] pro výjimky, fatalError() pro Swift. Jen tak lze zajistit, že SDK pokrývá všechny typy pádů.

Crash Reporting na Androidu: ANR a native crashes

Android přidává dva specifické typy pádů, které na iOS neexistují: ANR (Application Not Responding) a native crash v C/C++ kódu. ANR nastává, když je UI vlákno zablokováno déle než 5 sekund — systém zobrazí dialog „Aplikace neodpovídá" a nabídne její zavření.

Standardní Thread.setDefaultUncaughtExceptionHandler nezachycuje ANR, protože se nejedná o výjimku, ale signál z ActivityManager. Pro sledování ANR používají Crashlytics a Sentry watchdog vlákno na pozadí, které kontroluje odezvu UI vlákna každých 5 sekund. Podle Firebase, 2024 je 15% všech problémů na Androidu ANR, nikoli crash.

Native crash na Androidu vznikají v C/C++ kódu spuštěném přes JNI (Java Native Interface). Tyto pády nejsou Java výjimkami a nejsou zachyceny Thread.setDefaultUncaughtExceptionHandler. Pro jejich zpracování se používají Google Breakpad nebo Crashpad, které instalují sigaction obsluhy pro signály SIGSEGV, SIGABRT, SIGBUS.

Podle Google I/O 2024 počet native crashů roste s rozšířením herních enginů (Unity, Unreal Engine) a knihoven počítačového vidění (ML Kit, OpenCV). Vývojářům hybridních aplikací se doporučuje vždy připojit native crash-reporting.