Monitoring awarii aplikacji mobilnej — Crashlytics, Sentry i Android vitals w praktyce

Większość użytkowników nie zgłasza błędów. Aplikacja zamyka się przy płatności, więc użytkownik próbuje drugi raz, a potem ją odinstalowuje albo zostawia jedną gwiazdkę bez komentarza. Jeśli o awariach dowiadujesz się z recenzji w sklepie, dowiadujesz się o nich ostatni.

Monitoring awarii to najtańszy element utrzymania aplikacji mobilnej, a jednocześnie ten, który najczęściej okazuje się niedziałający w projektach, które przejmujemy: SDK jest dodane, ale raporty są nieczytelne, nikt nie dostaje alertów i nikt nie zagląda do panelu. Ten tekst opisuje, jak ustawić go tak, żeby rzeczywiście działał.

Dlaczego to ważne także dla sklepu

Monitoring to nie tylko wygoda zespołu. Google Play mierzy stabilność aplikacji w Android vitals i ma progi tzw. złego zachowania:

Aplikacja, która przekracza te progi, może być słabiej widoczna w Google Play, a użytkownicy mogą zobaczyć na jej stronie ostrzeżenie o problemach ze stabilnością. Przekroczenie progu dla jednego modelu telefonu dotyczy użytkowników tego modelu. Innymi słowy: niestabilna aplikacja traci nie tylko obecnych użytkowników, ale i nowych.

App Store nie publikuje podobnych progów, ale recenzje i oceny działają tak samo — a dane o awariach dostępne w Xcode Organizer są uboższe niż te z dedykowanych narzędzi.

Narzędzia: co wybrać

W praktyce: Crashlytics jest dobrym wyborem domyślnym dla aplikacji natywnych i we Flutterze. Sentry warto rozważyć w React Native i tam, gdzie zależy Ci na jednym narzędziu dla aplikacji i backendu. Android vitals i Xcode Organizer traktuj jako źródło prawdy — nawet z najlepszym SDK warto co jakiś czas porównać liczby, bo część awarii (np. zabicie aplikacji przez system z braku pamięci albo za długie blokowanie wątku głównego na iOS) nie trafia do zewnętrznych narzędzi.

Raport bez symboli jest bezużyteczny

Najczęstszy problem, który widzimy: raporty awarii są w panelu, ale zamiast nazw klas i numerów linii zawierają adresy pamięci albo zaciemnione nazwy w stylu a.b.c. Powód jest zawsze ten sam — nie są wysyłane pliki potrzebne do odczytania stosu wywołań.

• Android — jeśli wydanie jest zaciemniane przez R8, do narzędzia musi trafić plik mapping.txt z każdego wydania. Wtyczka Crashlytics do Gradle robi to automatycznie, jeśli jest poprawnie skonfigurowana.
• iOS — pliki dSYM z każdego builda. Trzeba je wysyłać w procesie budowania; ręczne wgrywanie zawsze w końcu ktoś pominie.
• Flutter — przy budowaniu z --obfuscate --split-debug-info trzeba wysłać wygenerowane symbole (dla Crashlytics służy do tego Firebase CLI).
• React Native — mapy źródeł (source maps) JavaScriptu, a przy Hermesie także mapy dla kodu bajtowego. Bez nich błąd JavaScriptu wskazuje na jedną gigantyczną linię spakowanego kodu.

Najpewniejszy sposób to wysyłanie symboli jako krok w automatycznym procesie wydań. Wtedy każde wydanie ma komplet i nie zależy to od pamięci jednej osoby.

Co mierzyć

• Crash-free users — odsetek użytkowników, którzy w danym okresie nie doświadczyli awarii. To główny wskaźnik. Orientacyjnie: poniżej 99% jest źle, 99,5% to przyzwoity poziom, dojrzałe aplikacje celują w 99,9%.
• Crash-free sessions — to samo dla sesji. Przydatne do porównywania wersji.
• ANR i zawieszenia — aplikacja, która nie odpowiada przez kilka sekund, jest dla użytkownika równie zepsuta jak ta, która się zamyka. Na Androidzie liczą się do Android vitals osobno.
• Błędy niekrytyczne — wyjątki złapane w kodzie, nieudane wywołania API, błędy płatności. Aplikacja się nie zamyka, ale użytkownik nie może zrobić tego, po co przyszedł. Warto je raportować świadomie, w kluczowych miejscach, a nie każdy wyjątek.

Do każdej awarii dołączaj kontekst: wersję aplikacji, ekran, ostatnie akcje użytkownika (breadcrumbs) i — jeśli to możliwe — identyfikator, który pozwala powiązać awarię z logami backendu.

Dane osobowe w raportach awarii

Raport awarii łatwo zamienić w niekontrolowany zbiór danych osobowych: e-mail jako identyfikator użytkownika, numer telefonu w kluczu kontekstowym, treść formularza w logu. Kilka zasad:

• jako identyfikator użytkownika używaj wewnętrznego, pseudonimowego ID — nie e-maila ani numeru telefonu;
• nie zapisuj w breadcrumbs i logach treści wpisywanych przez użytkownika;
• uwzględnij narzędzie do raportowania awarii w polityce prywatności, w deklaracji App Privacy w App Store i w sekcji Bezpieczeństwo danych w Google Play;
• jeśli raporty przegląda zewnętrzny wykonawca, powinien być objęty umową powierzenia przetwarzania danych.

Alerty i rytm pracy

Monitoring, do którego nikt nie zagląda, nie istnieje. Dwie rzeczy sprawiają, że działa:

Alerty, które ktoś czyta. Ustaw powiadomienia o nowym typie awarii w najnowszym wydaniu i o nagłym wzroście liczby istniejącej awarii (velocity alert). Kieruj je do kanału, który zespół rzeczywiście obserwuje — nie na skrzynkę, której nikt nie otwiera. Nie ustawiaj alertu na każdą awarię: po tygodniu wszyscy przestaną na nie reagować.

Regularny przegląd. Raz w tygodniu (albo po każdym wydaniu) przegląd największych awarii według liczby dotkniętych użytkowników. Każda dostaje decyzję: naprawiamy teraz, naprawiamy w następnym wydaniu, ignorujemy (bo np. dotyczy jednego egzotycznego urządzenia). Ten przegląd dobrze wpisać w zakres i priorytety umowy na utrzymanie aplikacji.

Stopniowe wydania: monitoring w praktyce

Monitoring najwięcej daje w połączeniu ze stopniowym udostępnianiem nowych wersji:

• Google Play — staged rollout. Wydajesz wersję np. dla 5% użytkowników, obserwujesz awarie przez dzień lub dwa, potem zwiększasz udział. Jeśli pojawi się problem, wstrzymujesz udostępnianie, zanim dotknie wszystkich.
• App Store — phased release. Automatyczne aktualizacje są rozkładane na siedem dni, z rosnącym odsetkiem użytkowników. Udostępnianie można wstrzymać. Pamiętaj, że dotyczy to tylko aktualizacji automatycznych — każdy użytkownik może ręcznie pobrać nową wersję od razu.

Najważniejsza metryka w tym procesie to crash-free users nowej wersji w porównaniu z poprzednią. Jeśli nowa wersja jest wyraźnie gorsza, wstrzymaj udostępnianie i sprawdź, co się zmieniło.

Szybka checklista

• SDK do raportowania awarii działa w wersji produkcyjnej (sprawdzone testową awarią).
• Symbole (mapping, dSYM, debug symbols, source maps) wysyłane automatycznie przy każdym wydaniu.
• Raporty zawierają wersję aplikacji, ekran i breadcrumbs, ale nie zawierają danych osobowych.
• Alerty o nowych awariach i skokach trafiają do kanału, który ktoś czyta.
• Ktoś raz w tygodniu przegląda największe awarie i podejmuje decyzje.
• Nowe wersje wydawane stopniowo, z porównaniem stabilności do poprzedniej.
• Android vitals sprawdzane co miesiąc pod kątem progów złego zachowania.

Podsumowanie

Monitoring awarii aplikacji mobilnej kosztuje niewiele — narzędzia są tanie albo darmowe, a konfiguracja to kilka dni pracy. Działa jednak tylko wtedy, gdy raporty są czytelne, alerty trafiają do ludzi, a ktoś regularnie podejmuje decyzje. Bez tego o problemach dowiadujesz się z recenzji, a Google Play — z Android vitals, i to on decyduje wtedy o widoczności aplikacji.

Konfiguracja monitoringu, symboli i stopniowych wydań to jedna z pierwszych rzeczy, które robimy w ramach utrzymania aplikacji mobilnych. Jeśli chcesz wiedzieć, jak wygląda stabilność Twojej aplikacji i czego brakuje w jej konfiguracji, zacznij od bezpłatnej analizy aplikacji.