Crash Reporting w rozwoju mobilnym — co to jest, usługi i konfiguracja

Co to jest Crash Reporting?

Crash Reporting — to proces automatycznego zbierania informacji technicznych o awariach aplikacji i ich scentralizowanego przesyłania na serwer w celu analizy. W przeciwieństwie do logowania, crash-reporting rejestruje właśnie sytuacje awaryjne — moment, w którym aplikacja została przymusowo zakończona przez system lub OS.

Każdy raport crash zawiera trzy kluczowe komponenty: typ wyjątku (NullPointerException, SIGSEGV, NSInternalInconsistencyException), pełny stos wywołań z numerami wierszy oraz informacje o środowisku — wersję OS, model urządzenia, ilość wolnej pamięci. Według danych Sentry Engineering, 2024, właśnie połączenie tych trzech elementów pozwala odtworzyć i naprawić 85% krytycznych błędów.

Nowoczesne systemy crash-reportingu rozszerzają funkcjonalność poza zwykłe crash. Firebase Crashlytics automatycznie grupuje powtarzające się awarie w issues, Sentry śledzi regresje między wydaniami, a Bugsnag pokazuje ścieżkę użytkownika do błędu. Wszystkie trzy serwisy obsługują iOS, Android, React Native i Flutter.

Według danych Google I/O 2024, aplikacje bez crash-reportingu spędzają na diagnostyce jednego krytycznego błędu średnio 3–5 dni roboczych, podczas gdy z Crashlytics — 15–30 minut. Oszczędność czasu wynosi ponad 90% dla każdego incydentu.

Jak działa system zbierania raportów crash

Architektura systemu crash-reportingu składa się z trzech warstw: kliencki SDK zainstalowany w aplikacji, serwerowy API do odbierania i przetwarzania raportów oraz webowy dashboard do analizy. Kliencki SDK przechwytuje nieobsłużone wyjątki, serializuje je do JSON i wysyła na serwer przy następnym uruchomieniu aplikacji.

Wysyłanie raportu crash odbywa się asynchronicznie po restarcie aplikacji. To kluczowy moment: w momencie crash aplikacja nie może zagwarantować pomyślnego wysłania danych przez sieć. SDK zapisuje raport w lokalnym magazynie, a przy następnym uruchomieniu wysyła go w tle. Według danych Firebase Engineering, 2024, takie podejście zapewnia dostarczenie 99.7% raportów crash.

Dla wyjątków non-fatal (handled exceptions wewnątrz try-catch) SDK wysyła raport natychmiast, ponieważ aplikacja kontynuuje działanie. Raporty non-fatal zawierają te same dane co crash, ale nie przerywają sesji użytkownika. Jest to szczególnie przydatne do śledzenia błędów zapytań API, walidacji danych i logiki biznesowej.

Grupowanie crash — algorytm serwerowy, który łączy identyczne crash na podstawie hasha z ostatnich 5–10 ramek stosu. Pozwala to programiście widzieć nie 1000 pojedynczych raportów, ale jedno issue z 1000 wystąpień, obejmujących różne urządzenia i wersje OS.

Firebase Crashlytics: integracja i możliwości

Firebase Crashlytics — najpopularniejszy serwis crash-reportingu dla aplikacji mobilnych, używany w ponad 3 milionach projektów na całym świecie. Darmowy pakiet obejmuje nieograniczoną liczbę raportów, integrację z Google Analytics i automatyczne grupowanie crash.

Integracja Crashlytics na Android

Podłączenie Crashlytics na Android jest minimalne: dodaj zależność w build.gradle i zainicjuj SDK w Application.onCreate. Crashlytics automatycznie ustawia własny Thread.setDefaultUncaughtExceptionHandler, przechwytując wszystkie nieobsłużone wyjątki.

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

Kluczowa funkcja Crashlytics — custom keys i logs. Programista może dodać do 64 par klucz-wartość do każdego raportu crash: stan ekranu, wybrany abonament, poziom użytkownika. Dostępne jest również zapisywanie niestandardowych wiadomości log, które trafiają do raportu w porządku chronologicznym.

Velocity Alert — automatyczne wykrywanie regresji

Velocity Alert — funkcja Crashlytics, która śledzi gwałtowny wzrost liczby crash dla konkretnego issue. Jeśli po nowym wydaniu liczba awarii przekroczy wartość progową, zespół otrzymuje powiadomienie push i email na 5–15 minut przed masowymi skargami użytkowników.

Ustawienie progu zadziałania: 2x w ciągu 1 godziny dla krytycznych issues. Według danych Google, 2024, zespoły z włączonym Velocity Alert wypuszczają hotfix-y średnio o 40% szybciej niż zespoły polegające na ręcznym monitorowaniu dashboardu.

Integracja Crashlytics na iOS

Na iOS SDK Crashlytics integruje się przez CocoaPods lub Swift Package Manager. SDK przechwytuje zarówno wyjątki Objective-C (przez NSSetUncaughtExceptionHandler), jak i sygnały OS (SIGSEGV, SIGABRT) przez własny mach exception handler.

Według danych Apple Developer, 2024, Crashlytics dla iOS obsługuje do 98% wszystkich typów awarii, w tym niskopoziomowe błędy pamięci, które nie są przechwytywane przez standardowe mechanizmy. To czyni Crashlytics standardem de facto dla rozwoju na iOS.

Sentry i Bugsnag: alternatywne platformy

Sentry — platforma open-source do monitorowania błędów, obsługująca 80+ języków i frameworków. W przeciwieństwie do Crashlytics, Sentry jest skierowana do programistów backendu, ale oferuje pełny SDK dla iOS, Android, React Native i Flutter.

Kluczowa zaleta Sentry — Performance Monitoring w jednym dashboardzie. Programista widzi nie tylko crash, ale także transakcje, które do nich doprowadziły: wolne zapytania sieciowe, zawieszanie UI, długie operacje na bazie danych. Według danych Sentry, 2024, 40% crash ma poprzedzające problemy wydajnościowe, które pozostają niezauważone bez takiego podejścia.

Bugsnag wyróżnia się podejściem do grupowania błędów — zamiast stosu wywołań analizuje ścieżkę użytkownika (user journey). Każdy raport crash zawiera sekwencję ekranów i działań użytkownika, które doprowadziły do błędu. Jest to szczególnie przydatne w złożonych procesach biznesowych: składanie zamówienia, rejestracja, płatność.

Koszt usług jest zróżnicowany: Crashlytics jest darmowy w ramach Firebase, Sentry oferuje darmowy pakiet na 5000 zdarzeń miesięcznie, Bugsnag — od $29 miesięcznie. Wszystkie trzy platformy udostępniają SDK z otwartym kodem źródłowym. Wybór usługi zależy od wielkości zespołu, budżetu i wymagań dotyczących bezpieczeństwa danych.

Crash Reporting na iOS: cechy i NSException

Cecha iOS — wielowarstwowa architektura obsługi błędów. SDK crash-reportingu muszą przechwytywać wyjątki Objective-C (NSException), błędy Swift (Error), sygnały POSIX (SIGSEGV, SIGBUS) i mach-wyjątki. Każdy typ wymaga osobnego mechanizmu przechwytywania.

NSException — najprostszy typ do przechwycenia przez NSSetUncaughtExceptionHandler. Jednak według danych Apple, 2024, tylko 30% crash w nowoczesnych aplikacjach Swift to NSException. Pozostałe 70% to sygnały OS i błędy środowiska wykonawczego Swift, które wymagają mechanizmu mach exception handler.

Programiści iOS powinni testować crash-reporting przez lokalne generowanie crash różnych typów: __builtin_trap() dla sygnałów, [NSException raise:...] dla wyjątków, fatalError() dla Swift. Tylko w ten sposób można upewnić się, że SDK pokrywa wszystkie typy awarii.

Crash Reporting na Android: ANR i native crashes

Android dodaje dwa specyficzne typy awarii, których nie ma na iOS: ANR (Application Not Responding) i native crash w kodzie C/C++. ANR występuje, gdy wątek UI jest zablokowany na ponad 5 sekund — system pokazuje okno „Aplikacja nie odpowiada” i proponuje jej zamknięcie.

Standardowy Thread.setDefaultUncaughtExceptionHandler nie przechwytuje ANR, ponieważ nie jest to wyjątek, a sygnał z ActivityManager. Do śledzenia ANR Crashlytics i Sentry używają wątku watchdog w tle, który sprawdza responsywność wątku UI co 5 sekund. Według danych Firebase, 2024, 15% wszystkich problemów na Android to ANR, a nie crash.

Native crash na Android występują w kodzie C/C++ uruchomionym przez JNI (Java Native Interface). Te awarie nie są wyjątkami Java i nie są przechwytywane przez Thread.setDefaultUncaughtExceptionHandler. Do ich obsługi używa się Google Breakpad lub Crashpad, które ustawiają handlery sigaction dla sygnałów SIGSEGV, SIGABRT, SIGBUS.

Według danych Google I/O 2024, liczba native crash rośnie wraz z rozpowszechnieniem silników gier (Unity, Unreal Engine) i bibliotek widzenia komputerowego (ML Kit, OpenCV). Programistom aplikacji hybrydowych zaleca się zawsze podłączać native crash-reporting.