Crash w tworzeniu aplikacji mobilnych: co to jest, rodzaje i metody zapobiegania

Co to jest Crash

Crash — to awaryjne zakończenie aplikacji spowodowane nieobsłużonym wyjątkiem lub krytycznym sygnałem systemowym, który nie został obsłużony w kodzie aplikacji. Gdy system lub maszyna wirtualna (JVM, ART) wykryje stan krytyczny — NullPointerException, IndexOutOfBoundsException, OutOfMemoryError — natychmiast zatrzymuje proces i usuwa go z pamięci. Użytkownik widzi nagłe zamknięcie aplikacji bez żadnego systemowego powiadomienia o błędzie. Według Google, aplikacje ze wskaźnikiem crash-free poniżej 99% tracą do 20% aktywnych użytkowników miesięcznie.

Na Androidzie mechanizm obsługi awarii różni się od systemów desktopowych. Zamiast okna debugowania ze stack trace, Android po prostu zabija proces i nie zapisuje szczegółowych informacji. Zbieranie informacji o awarii to zadanie bibliotek zewnętrznych (Crashlytics, Sentry, Bugsnag), które przechwytują wyjątki przez Thread.setDefaultUncaughtExceptionHandler zanim proces zostanie zakończony.

iOS używa podobnego mechanizmu z NSException i Mach exceptions do obsługi błędów krytycznych. W przypadku nieobsłużonego wyjątku system zamyka aplikację, a raport jest zapisywany w postaci pliku .crash. Zbieranie awarii na iOS wymaga integracji z Crashlytics lub wbudowanego raportu przez Xcode Organizer.

Główne typy awarii

Pięć kategorii awarii pokrywa 90% wszystkich awarii w aplikacjach mobilnych. Zrozumienie każdego typu pomaga szybciej diagnozować i naprawiać problemy w środowisku produkcyjnym.

NullPointerException — król awarii

NullPointerException (NPE) — najczęstszy typ awarii we wszystkich aplikacjach Java/Kotlin. Występuje przy próbie wywołania metody lub dostępu do pola obiektu, który ma wartość null. Typowe scenariusze: niezainicjalizowane pole Activity przy obrocie ekranu, null-odpowiedź z serwera przy deserializacji JSON, nieostrożna nawigacja po adapterze RecyclerView.

Kotlin rozwiązuje problem NPE na poziomie języka przez null-safe typy: String? nie może być użyty bez jawnego sprawdzenia. Jednak zgodność z Javą i Reflection nadal stwarzają ryzyko. Używaj adnotacji @NonNull i @Nullable oraz włącz strictNullChecks w narzędziach analizy statycznej.

fun safeLength(text: String?): Int {
    return text?.length ?: 0 // bezpieczna obsługa null
}

IndexOutOfBoundsException i błędy kolekcji

IndexOutOfBoundsException występuje przy dostępie do nieistniejącego indeksu listy lub tablicy. Częsty scenariusz: usunięcie elementu z RecyclerView bez synchronizacji z adapterem, wielowątkowa modyfikacja ArrayList bez blokady, nieprawidłowe obliczenie pozycji w ViewPager. ConcurrentModificationException — bliski krewny przy jednoczesnej iteracji i modyfikacji kolekcji.

Używaj CopyOnWriteArrayList do dostępu wielowątkowego lub kolekcji Lock-free z java.util.concurrent. Do synchronizacji z UI stosuj DiffUtil, który bezpiecznie i efektywnie oblicza różnicę między starą a nową listą.

ClassCastException — typowe problemy

ClassCastException występuje przy rzutowaniu obiektu na niekompatybilny typ. W Androidzie typowe przyczyny: nieprawidłowy typ ViewHolder w RecyclerView (różne typy komórek bez poprawnego getItemViewType), nieprawidłowe rzutowanie Fragment przy nawigacji, obiekty Serializable z różnymi wersjami klas.

Używaj bezpiecznego rzutowania Kotlin przez operator as?, który zwraca null przy niezgodności typów. W Javie — sprawdzenie przez instanceof przed rzutowaniem. Dla obiektów Parcelable obowiązkowo deklaruj CREATOR w każdej klasie.

IllegalStateException i błędy logiczne

IllegalStateException sygnalizuje wywołanie metody w nieodpowiednim stanie obiektu. Typowy przykład w Androidzie — getSupportFragmentManager() po onSaveInstanceState, gdy commit() fragmentu jest niedozwolony. Inny częsty przypadek — wywołanie dismiss() na już zamkniętym oknie dialogowym.

Sprawdzaj stan cyklu życia przed operacjami na FragmentManager. Używaj commitAllowingStateLoss() tylko gdy masz pewność, że utrata stanu nie jest krytyczna. W Kotlinie twórz budownicze podobne do DSL, które wykluczają nieprawidłowe stany na poziomie typów.

Native Crash (sygnały SIGSEGV, SIGABRT)

Native Crash występuje w natywnym kodzie C/C++ przy naruszeniu pamięci: dostęp przez null-wskaźnik, double-free, przepełnienie bufora stosu. W Androidzie takie awarie występują w bibliotekach NDK, silnikach gier (Unity, Unreal) i zależnościach systemowych. Native Crash NIE jest przechwytywany przez Thread.setDefaultUncaughtExceptionHandler — zabija proces natychmiast.

Do diagnostyki natywnych awarii używaj plików minidump (Breakpad) lub tombstone Androida. Firebase Crashlytics obsługuje zbieranie natywnych awarii przez NDK SDK. Na iOS podobny problem rozwiązuje PLCrashReporter.

Narzędzia do raportowania awarii

Trzy narzędzia dominują na rynku raportowania awarii mobilnych. Każde zapewnia zbieranie stack trace, agregację według wersji aplikacji i powiadomienia o nowych awariach.

Firebase Crashlytics

Crashlytics — najpopularniejszy raport awarii dla aplikacji mobilnych, wchodzący w skład ekosystemu Firebase. Automatycznie zbiera stack trace, dane o urządzeniu, wersję systemu operacyjnego i niestandardowe klucze użytkownika. Integracja zajmuje 10 minut przez Firebase Console i Gradle Plugin. Crashlytics obsługuje również rzeczywiste logi (Logcat) i niestandardowe śledzenie.

FirebaseCrashlytics.getInstance()
    .setCustomKey("current_screen", "ProfileFragment")

FirebaseCrashlytics.getInstance()
    .log("User tapped login button")

Sentry

Sentry — alternatywa dla Crashlytics z bardziej elastycznym systemem filtrowania i obsługą 90+ platform. W przeciwieństwie do Firebase, Sentry udostępnia serwer do samodzielnego hostowania (self-hosted) dla firm z rygorystycznymi wymaganiami dotyczącymi danych. Sentry obsługuje śledzenie dystrybucji, breadcrumbs i integrację z pipeline CI/CD.

Bugsnag i AppCenter

Bugsnag wyróżnia się obsługą alertów opartych na ważności: dzieli awarie na krytyczne, błędy i ostrzeżenia. AppCenter od Microsoft — bezpłatne narzędzie z podstawową funkcjonalnością dla małych projektów. Oba obsługują Android, iOS, React Native i Flutter.

Jak analizować awarię

Analiza awarii to proces odtwarzania pełnego obrazu zdarzenia. Stack trace pokazuje tylko ostatni punkt awarii, ale nie daje kontekstu, który doprowadził do problemu. Profesjonalne podejście obejmuje cztery etapy.

Pierwszy etap — czytanie stack trace. Określ klasę, metodę i linię kodu, w której wystąpił wyjątek. Prześledź łańcuch wywołań od górnej ramki do dolnej: ostatnia linia w stosie to miejsce awarii, a górne linie to sekwencja wywołań. Deobfuskacja (mapowanie ProGuard/R8) jest obowiązkowa dla kompilacji produkcyjnych.

Drugi etap — kontekst urządzenia. Crashlytics pokazuje model urządzenia, wersję systemu operacyjnego, dostępną pamięć i wersję aplikacji. Na przykład awaria tylko na Samsung Galaxy S10 z Androidem 11 wskazuje na problem z konkretną wersją One UI, a nie ogólny błąd kodu.

Trzeci etap — odtworzenie na urządzeniu testowym. Jeśli awaria nie odtwarza się stabilnie, zapytaj użytkownika o dokładne kroki lub użyj Remote Config do logowania przed problematycznym fragmentem kodu. Testowanie AB poprawki na części odbiorców pomaga potwierdzić rozwiązanie.

Czwarty etap — monitorowanie po poprawce. Po opublikowaniu poprawki obserwuj częstotliwość awarii przez 3–5 dni. Jeśli awaria całkowicie zniknęła — poprawka zadziałała. Jeśli częstotliwość spadła, ale nie spadła do zera — istnieje drugi scenariusz wymagający osobnej analizy.

Praktyki zapobiegania awariom

Systematyczne podejście do zapobiegania awariom obejmuje narzędzia analizy statycznej, obowiązkowe testowanie przypadków brzegowych i właściwą obsługę błędów na wszystkich poziomach aplikacji.

Analiza statyczna kodu

Detekt (Kotlin) i Lint (Android) znajdują potencjalne problemy na etapie kompilacji: nieużywane zmienne, potencjalne NPE, nieprawidłowe użycie API. Włącz te narzędzia w pipeline CI z progiem błędów. Na przykład Detekt z konfiguracją na 30+ warning lub dowolne error-blocking nie przepuszcza kompilacji.

Testy jednostkowe i testy UI

Pokrycie kluczowych scenariuszy użycia testami jednostkowymi to podstawowa ochrona przed regresyjnymi awariami. Testuj modele danych, ViewModel i warstwy UseCase z przypadkami brzegowymi: wartości null, puste listy, nieprawidłowe JSON. Testy UI przez Espresso lub Compose Test pokrywają krytyczne flowy: autoryzacja, płatność, onboarding.

Graceful Degradation

Projektuj aplikację tak, aby awaria w jednym module nie powodowała upadku całego ekranu. Używaj bloków catch na poziomie ViewModel z zwracaniem stanu zastępczego: wyświetlanie zastępnika zamiast listy, dane z pamięci podręcznej przy braku sieci, zapasowy obraz przy błędzie ładowania. To zamienia potencjalną awarię w kontrolowany scenariusz UX.

Płynne wdrażanie z monitorowaniem

Staged rollouts — standardowa praktyka Google Play i App Store: nowa wersja jest rozpowszechniana na 5%, następnie na 20% i na 100% odbiorców w odstępie 1–3 dni. Na każdym etapie monitorowana jest częstotliwość awarii: jeśli wskaźnik crash-free spadnie poniżej 99,5%, wdrażanie jest automatycznie zatrzymywane. Firebase Remote Config pozwala wyłączać problematyczne funkcje bez publikowania nowej wersji.

Kontrola wersji zależności

Renovate lub Dependabot w CI automatycznie sprawdzają biblioteki pod kątem znanych podatności i krytycznych błędów. Aktualizacja jednej zależności może wyeliminować całą klasę awarii. Jednak testuj aktualizacje w środowisku staging przed wdrożeniem do produkcji — nowa wersja biblioteki może zawierać niekompatybilne zmiany.