Dostosowywanie raportów o awariach Firebase Crashlytics


Na pulpicie Crashlytics możesz kliknąć problem, aby uzyskać szczegółowy raport o wydarzeniu. Możesz dostosowywać te raporty, aby lepiej rozumieć, co dzieje się w aplikacji, i jakie są okoliczności związane ze zgłoszonymi zdarzeniami w Crashlytics.

  • Automatycznie otrzymuj logi ścieżki, jeśli Twoja aplikacja korzysta z pakietu SDK Firebase w Google Analytics. Logi te dają wgląd w działania użytkowników, które prowadzą do zdarzenia zebranego przez Crashlytics w Twojej aplikacji.

  • Wyłącz automatyczne raportowanie awarii i włącz raportowanie z wyrażeniem zgody dla użytkowników. Pamiętaj, że domyślnie Crashlytics automatycznie zbiera raporty o awariach dotyczące wszystkich użytkowników aplikacji.

Zgłaszanie wyjątków

Zgłaszanie wykrytych wyjątków

Jeśli masz oczekiwane wyjątki, możesz skonfigurować Crashlytics SDK tak, aby zgłaszało je jako niekrytyczne zdarzenia. Zdarzenia te są rejestrowane na urządzeniu, a następnie wysyłane razem z następnym raportem o błędach krytycznych lub po ponownym uruchomieniu gry przez użytkownika.

Wyjątki możesz rejestrować w C# za pomocą tej metody:

Crashlytics.LogException(Exception ex);

Możesz rejestrować oczekiwane wyjątki w blokach try/catch w grze:

try {
    myMethodThatThrows();
} catch (Exception e) {
   Crashlytics.LogException(e);
   // handle your exception here!
}

Zgłaszanie niewykrytych wyjątków

W przypadku niezarejestrowanych wyjątków, które nie powodują awarii gry (np. niewyłapane wyjątki C# w logice gry), pakiet SDK Crashlytics może zgłaszać je jako zdarzenia krytyczne. W tym celu ustaw właściwość Crashlytics.ReportUncaughtExceptionsAsFatal na true i zainicjuj Crashlytics w projekcie Unity. Te zdarzenia są zgłaszane do usługi Crashlytics w czasie rzeczywistym bez konieczności ponownego uruchamiania gry przez użytkownika.

Raportowanie tych niewykrytych wyjątków jako krytycznych zdarzeń oznacza, że będą one uwzględniane w statystykach dotyczących użytkowników, którzy nie mieli żadnych awarii, oraz w alertach dotyczących szybkości.

Firebase Crashlytics

Pamiętaj, że awarie natywne są zawsze zgłaszane jako zdarzenia krytyczne. Te zdarzenia są logowane na urządzeniu i wysyłane, gdy użytkownik ponownie uruchomi grę.

void Start() {
    // Since there is no try-block surrounding this call, if an exception is thrown,
    // it is considered unexpected.
    // Setting `Crashlytics.ReportUncaughtExceptionsAsFatal = true`
    // will ensure that such cases are reported as fatals.
    thirdPartyMethodThatMayThrow();
}

Dołącz raporty GWP-ASan, aby debugować problemy z uszkodzoną pamięcią

W przypadku aplikacji na Androida, które korzystają z IL2CPP, Crashlytics może pomóc w debugowaniu awarii spowodowanych błędami pamięci natywnej, zbierając raporty GWP-ASan. Te błędy związane z pamięcią mogą być związane z uszkodzeniem pamięci w aplikacji, co jest główną przyczyną luk w zabezpieczeniach aplikacji.

  • Te dane możesz wyświetlić na nowej karcie „Śledzenie zrzutu stosu pamięci” po kliknięciu szczegółów problemu na Crashlytics panelu.

  • Możesz też użyć nowego sygnału „Raport GWP-ASan” i odpowiedniego filtra, aby szybko wyświetlić wszystkie problemy dotyczące tych danych.

Możesz otrzymywać raporty dotyczące pamięci GWP-ASan, jeśli Twoja aplikacja używa najnowszego pakietu SDK Crashlytics dla Unity (w wersji 10.7.0 lub nowszej) i ma jawnie włączone GWP-ASan (wymaga zmodyfikowania pliku manifestu aplikacji na Androida). Jeśli w aplikacji jest kod C++, możesz przetestować konfigurację GWP-ASan, korzystając z przykładowego kodu natywnego w dokumentacji Androida.

Dodawanie kluczy niestandardowych

Klucze niestandardowe pomagają określić stan aplikacji, który doprowadził do awarii. Możesz powiązać z raportami o awariach dowolne pary klucz-wartość, a następnie używać niestandardowych kluczy do wyszukiwania i filtrowania raportów o awariach w konsoli Firebase.

  • W panelu Crashlytics możesz wyszukiwać problemy pasujące do klucza niestandardowego.
  • Podczas sprawdzania konkretnego problemu w konsoli możesz wyświetlić powiązane klucze niestandardowe dla każdego zdarzenia (podkarta Klucze) i nawet je filtrować według kluczy niestandardowych (menu Filtr u góry strony).

Gdy funkcja jest wywoływana wielokrotnie, nowe wartości dla istniejących kluczy będą aktualizować wartość, a w przypadku zarejestrowania awarii zostanie uwzględniona tylko najnowsza wartość.

Crashlytics.SetCustomKey(string key, string value);

Dodaj niestandardowe komunikaty logu

Zalogowane wiadomości są powiązane z danymi o awarii i widoczne w panelu Firebase Crashlytics podczas wyświetlania konkretnej awarii.

Crashlytics.Log(string message);

Ustawianie identyfikatorów użytkowników

Możesz użyć numeru identyfikacyjnego, tokena lub zahaszowanej wartości, aby jednoznacznie zidentyfikować użytkownika aplikacji bez ujawniania ani przesyłania żadnych jego danych osobowych. Możesz też usunąć wartość, ustawiając ją jako pusty ciąg. Ta wartość jest wyświetlana w panelu Firebase Crashlytics podczas wyświetlania konkretnej awarii.

Crashlytics.SetUserId(string identifier);

Pobieranie dzienników elementów menu nawigacyjnego

Dzięki dziennikom śladów możesz lepiej poznać interakcje użytkownika z aplikacją, które doprowadziły do awarii, niekrytycznego błędu lub zdarzenia ANR. Te logi mogą być przydatne podczas próby odtworzenia i debugowania problemu.

Logi ścieżki są obsługiwane przez Google Analytics, więc aby je uzyskać, musisz włączyć Google Analytics w projekcie Firebase i dodać do aplikacji pakiet SDK Firebase dla Google Analytics. Gdy spełnisz te wymagania, ścieżki będą automatycznie uwzględniane w danych zdarzenia na karcie Logi, gdy wyświetlisz szczegóły problemu.

Pakiet SDK Analytics automatycznie rejestruje zdarzenie screen_view, dzięki czemu logi ścieżki pokazują listę ekranów wyświetlonych przed zdarzeniem ANR, niekrytycznym lub niefatalnym. Dziennik menu nawigacyjnego screen_view zawiera parametr firebase_screen_class.

Logi ścieżek chleba pomarańczowego są też wypełniane zdarzeniami niestandardowymi, które rejestrujesz ręcznie w sesji użytkownika, w tym danymi parametrów zdarzenia. Te dane mogą pomóc w określeniu sekwencji działań użytkownika, które doprowadziły do awarii, niekrytycznego błędu lub błędu ANR.

Pamiętaj, że możesz kontrolować zbieranie i wykorzystywanie danych Google Analytics, w tym danych wypełniających logi ścieżek.

Włącz raportowanie akceptacji

Domyślnie Crashlytics automatycznie zbiera raporty o awariach dla wszystkich użytkowników aplikacji. Możesz dać użytkownikom większą kontrolę nad przesyłanymi danymi, pozwalając im na zgłaszanie awarii.

Aby wyłączyć automatyczne zbieranie danych i zainicjować Crashlytics tylko dla wybranych użytkowników, wywołaj zastąpienie zbierania danych Crashlytics w czasie działania. Wartość zastąpienia będzie widoczna po uruchomieniu aplikacji, więc funkcja Crashlytics może automatycznie zbierać raporty. Aby zrezygnować z automatycznego zgłaszania awarii, podaj wartość false jako wartość zastąpienia. Jeśli ustawisz wartość false, nowa wartość zacznie obowiązywać dopiero po ponownym uruchomieniu aplikacji.

Crashlytics.IsCrashlyticsCollectionEnabled = true

Zarządzanie danymi z Raportu o awariach

Analiza awarii pomaga rozwiązywać problemy przez porównywanie anonimowych zrzutów stosu z zrzutami z innych aplikacji Firebase i informowanie, czy Twój problem jest częścią większego trendu. W przypadku wielu problemów statystyki awarii udostępniają nawet zasoby, które pomogą Ci w debugowaniu awarii.

Raport Crash Insights korzysta z zagregowanych danych o wypadkach, aby identyfikować wspólne trendy dotyczące stabilności. Jeśli nie chcesz udostępniać danych aplikacji, możesz zrezygnować ze statystyk awarii w menu Statystyki awarii u góry listy Crashlytics problemów w konsoli Firebase.