Na pulpicie Crashlytics możesz kliknąć problem, aby uzyskać szczegółowy raport o wydarzeniu. Możesz dostosować te raporty, aby lepiej zrozumieć, co dzieje się w Twojej aplikacji i w jakich okolicznościach Crashlytics
Wyjątki wykryte i niewykryte zgłaszaj do Crashlytics.
Dołącz raporty GWP-ASan, aby debugować problemy z uszkodzeniem pamięci.
Dostosuj aplikację do rejestrowania kluczy niestandardowych, niestandardowe komunikaty dziennika i identyfikatory użytkowników.
Automatycznie pobieraj logi menu nawigacyjnego, jeśli aplikacja używa Pakiet SDK Firebase dla platformy Google Analytics. Logi te dają Ci wgląd w działań użytkownika, które doprowadziły 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 dla wszystkich użytkowników aplikacji.
Zgłoś wyjątki
Zgłaszanie wykrywanych wyjątków
Jeśli masz oczekiwane wyjątki, możesz skonfigurować SDK Crashlytics tak, aby zgłaszały je jako niekrytyczne zdarzenia. Te zdarzenia są rejestrowane na urządzeniu oraz jest wysyłana razem z następnym raportem o błędach krytycznych lub po ponownym uruchomieniu urządzenia przez użytkownika. w całej grze.
Możesz rejestrować wyjątki w języku C# przy użyciu następującej metody:
Crashlytics.LogException(Exception ex);
Spodziewane wyjątki możesz zapisać w blokach try/catch w grze:
try { myMethodThatThrows(); } catch (Exception e) { Crashlytics.LogException(e); // handle your exception here! }
Zgłaszanie niewykrytych wyjątków
Dotyczy niewykrytych wyjątków, które nie powodują awarii gry (na przykład
wyjątki od języka C# w logice gry), możesz je zgłosić przez pakiet Crashlytics SDK.
jako krytyczne przez ustawienie
usługę Crashlytics.ReportUncaughtExceptionsAsFatal
do true
, gdzie
zainicjuj Crashlytics w projekcie Unity
,
Te zdarzenia są zgłaszane do Crashlytics w czasie rzeczywistym bez konieczności
użytkownik może ponownie uruchomić grę.
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.
Pamiętaj, że awarie natywne są zawsze zgłaszane jako zdarzenia krytyczne. Te zdarzenia są rejestrowane na urządzeniu, a potem 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 uszkodzeniem pamięci
W przypadku aplikacji na Androida, które korzystają z IL2CPP, Crashlytics może pomóc w debugowaniu awarii spowodowanych przez błędy pamięci natywnej, zbierając raporty GWP-ASan. Te mogą występować błędy związane z uszkodzeniem pamięci w aplikacji, co jest główną przyczyną luk w zabezpieczeniach aplikacji.
Możesz wyświetlić te dane w nowej „zrzutach stosu pamięci” Tab. do szczegółów problemu Panel Crashlytics.
Można też skorzystać z nowego „raportu GWP-ASan” sygnału i filtra, aby szybko wyświetlić wszystkich problemów z tymi danymi.
Raporty o pamięci GWP-ASan możesz otrzymywać, jeśli Twoja aplikacja korzysta z najnowszej wersji pakietu SDK Crashlytics do Unity (10.7.0 lub nowszej) i GWP-ASan jest w niej wyraźnie włączona (musisz zmodyfikować plik manifestu aplikacji na Androida). Jeśli masz w aplikacji kod w języku C++, możesz przetestować konfigurację GWP-ASan za pomocą przykładowy kod natywny znajdziesz w dokumentacji Androida.
Dodawanie kluczy niestandardowych
Klucze niestandardowe pomagają uzyskać konkretny stan aplikacji, który doprowadził do awarii. Dowolne pary klucz-wartość możesz powiązać z raportami o awariach, a następnie użyć funkcji klucze niestandardowe 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
Zapisane wiadomości są powiązane z danymi awarii i są widoczne w Panel Firebase Crashlytics podczas wyświetlania konkretnej awarii.
Crashlytics.Log(string message);
Ustawianie identyfikatorów użytkowników
Aby jednoznacznie zidentyfikować użytkownika aplikacji, możesz użyć numeru identyfikacyjnego, tokena lub wartości zaszyfrowanej, bez ujawniania lub przesyłania jakichkolwiek danych osobowych. Możesz też wyczyścić wartość, ustawiając ją jako pusty ciąg znaków. Ta wartość jest wyświetlana w panelu Firebase Crashlytics, gdy wyświetlając konkretną awarię.
Crashlytics.SetUserId(string identifier);
Pobierz logi menu nawigacyjnego
Logi menu nawigacyjnego pozwalają lepiej poznać interakcje użytkownika do których doprowadziło do awarii, wystąpienia błędu niekrytycznego lub błędu 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
który pozwala w dziennikach menu nawigacyjnego wyświetlać listę ekranów wyświetlonych przed
awarii, niekrytycznego ani błędu ANR. Log menu nawigacyjnego screen_view
zawiera element
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 zdarzenia ANR.
Pamiętaj, że możesz kontrolować zbieranie i wykorzystywanie danych Google Analytics, w tym danych wypełniających logi ścieżek.
Włączanie raportowania zgody
Domyślnie Crashlytics automatycznie zbiera raporty o awariach dla wszystkich użytkowników aplikacji. Możesz dać użytkownikom większą kontrolę nad danymi, które wysyłają, umożliwiając im zgłaszanie awarii.
Aby wyłączyć automatyczne zbieranie i zainicjować Crashlytics tylko dla wybranych
dla użytkowników, wywołaj w czasie działania metodę zastępowania zbierania danych Crashlytics. Wartość zastąpienia jest zachowana przy każdym uruchomieniu aplikacji, dzięki czemu Crashlytics może automatycznie zbierać raporty. Aby zrezygnować z automatycznego raportowania awarii, prześlij wartość false
jako wartość zastępczą. Gdy ustawisz wartość false
, nowa wartość nie będzie
obowiązują do następnego uruchomienia aplikacji.
Crashlytics.IsCrashlyticsCollectionEnabled = true
Zarządzanie danymi analizy awarii
Analiza awarii pomaga rozwiązywać problemy przez porównywanie anonimowych zrzutów stosu z zrzutami z innych aplikacji Firebase i informowanie, czy 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.