Crash aplikace: co to je, příčiny pádů a metody odhalování

Co je crash aplikace

Crash — neočekávané ukončení programu způsobené výjimečnou situací, kterou kód neošetřil. V mobilních OS vede crash k okamžitému zavření aplikace a zobrazení obrazovky „Aplikace byla zastavena“ nebo návratu na domovskou obrazovku.

Crashe se dělí do dvou velkých tříd. Ošetřené chyby — bloky try/catch zachytí výjimku, aplikace pokračuje v činnosti, možná se ztrátou funkčnosti. Neošetřené crashe — výjimka se propaguje až na úroveň OS a systém zabije proces. Druhý typ je obzvláště nebezpečný, protože uživatel nemůže uložit data.

Systém se dvěma miliony uživatelů a 0,1% crash rate ztrácí 2 000 uživatelů při každém vydání. Podle Google Play Console (2024) jsou aplikace s crash rate nad 1,5 % vyloučeny z doporučení a ztrácejí až 30 % organické návštěvnosti.

Hlavní příčiny pádů v mobilních aplikacích

NullPointerException (NPE) — král crashů v Java/Kotlin. Pokus o volání metody na null objektu. V Kotlinu se NPE vyskytuje méně často díky null safety, ale je stále možný při použití operátoru !! nebo interakci s Java kódem. Google (2024) odhaduje: NPE tvoří 25 % všech crashů Android aplikací.

IndexOutOfBoundsException — přístup k prvku seznamu s neexistujícím indexem. Častá příčina: data přicházejí ze serveru v neočekávaném formátu a UI se snaží zobrazit pozici, která neexistuje. Řešení — vždy zkontroluj velikost kolekce před přístupem přes index.

ANR (Application Not Responding) — problém specifický pro Android. UI vlákno je blokováno déle než 5 sekund. Hlavní příčiny: síťové požadavky na hlavním vlákně, těžké výpočty, synchronizace s databází. StrictMode v Androidu pomáhá odhalit blokování UI vlákna ve fázi vývoje.

OutOfMemoryError (OOM) — aplikace překročila limit paměti. Na mobilních zařízeních s 2–4 GB RAM je OOM častý problém při práci s velkými obrázky nebo nekonečnými seznamy bez stránkování. Řešení — Glide/Coil pro načítání obrázků, LruCache pro cache, ViewHolder v RecyclerView.

Runtime výjimky a fatální chyby

Runtime exceptions — chyby, které kompilátor nekontroluje ve fázi sestavení. Projevují se pouze při provádění kódu na konkrétním zařízení s konkrétními daty. V Javě jsou to RuntimeException a jeho podtřídy: NullPointerException, IllegalArgumentException, ArithmeticException.

Fatální chyby (FATAL) — ne runtime, ale systémové poruchy. Signal 11 (SIGSEGV) — porušení segmentace paměti v nativním kódu. Signal 6 (SIGABRT) — nouzové ukončení způsobené samotnou aplikací pomocí abort(). Takové crashe je obtížné diagnostikovat, protože stack trace často neukazuje srozumitelný kontext.

V iOS jsou hlavními příčinami NSInvalidArgumentException (neočekávané nil v parametru) a EXC_BAD_ACCESS (přístup k uvolněné paměti). Swift snížil počet crashů ve srovnání s Objective-C, ale chyby v ObjC runtime a C knihovnách stále vedou k pádům.

Monitorování a sběr crash logů

Firebase Crashlytics — standard pro mobilní aplikace. Automaticky sbírá stack trace, přidává logy, ID uživatele a metadata zařízení. Seskupuje crashe podle signatury (třída chyby + řádek). Real-time alerts — upozornění, když crash rate překročí nastavenou hranici (např. >0,1 % za hodinu).

Sentry — alternativa s flexibilnějšími možnostmi. Umožňuje vytvářet vlastní kontexty, přidávat breadcrumbs, konfigurovat filtrování v aplikaci pro vyloučení nedůležitých chyb. Source maps pro Kotlin a Swift umožňují vidět zdrojový kód, ne obfuskovaná jména.

Best practices pro logy: posílejte klíčová metadata před provedením nebezpečné operace. Přidejte custom keys (číslo verze API, poslední obrazovka, velikost vstupních dat). Tím se zbytečný stack trace promění v použitelné informace.

Příklad: nastavení Crashlytics v Androidu

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

undefined

Optional binding a null safety — v Kotlinu použij `?` pro nullable typy, `let` a `?:` pro bezpečné zpracování null. Ve Swiftu — optionals a guard let. Modern Kotlin (2024) přidal anotace Contract: @ContractsDsl umožňuje deklarovat, že funkce nevrací null, a kompilátor to kontroluje.

Error handling v síti — každý síťový požadavek musí zpracovat timeout, chyby parsování a odmítnutí serveru. Retrofit s typem Result — sealed třída, která zaručuje, že chyba bude zpracována. Styl No Exception: místo try/catch použij sealed Result pro explicitní zpracování úspěchu a chyby.

Feature flags — deaktivujte problematickou funkčnost na dálku bez vydání nové verze. Firebase Remote Config umožňuje změnit chování aplikace bez publikace v obchodě.

Postupné zavádění — vydávejte novou verzi pro 5 % publika a sledujte crash rate. Pokud rate zůstává pod cílem (obvykle <0,1 %), rozšiřte na 25 %, poté 50 %, poté 100 %. Google Play Console a App Store Connect podporují fázové zavádění pro automatické zastavení při překročení prahu.

Akční plán při detekci chyby

1: Klasifikace — určete závažnost: Critical (crash u >1 % uživatelů), High (0,1–1 %), Medium (<0,1 %). Pro Critical crashe — okamžitá reakce. Google Play Console automaticky klasifikuje crashe podle počtu postižených uživatelů.

2: Analýza stack trace — otevřete log v Crashlytics, podívejte se na přesné místo pádu. Zkontrolujte custom keys: jaká obrazovka, jaká data, verze OS. Porovnejte s posledním nasazením — často je crash způsoben nedávnou změnou v kódu, která ovlivnila neočekávaný scénář použití.

3: Reprodukce — zkuste reprodukovat crash na zařízení nebo emulátoru s podobnými parametry. Pokud se nedaří, zkontrolujte crash log na vzory: konkrétní modely (Samsung A10), verze Android (API < 26), locale. Řešení — přidejte ochrannou podmínku, která pokrývá scénář.

4: Oprava a monitorování — vydajte hotfix s prioritou. Po vydání se ujistěte, že crash rate pro tento typ klesne na nulu. Napište regresní test který pokrývá scénář crashu. Bez testu se stejná chyba může vrátit při příštím refaktoringu.