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.
Wyjątki wykryte i niewykryte zgłaszaj do Crashlytics.
Dołącz raporty GWP-ASan, aby debugować problemy z uszkodzoną pamięcią.
Zautomatyzuj swoją aplikację, aby rejestrować klucze niestandardowe, niestandardowe komunikaty logowania i identyfikatory użytkowników.
Automatycznie otrzymuj logi ścieżki, jeśli Twoja aplikacja korzysta z pakietu SDK Firebase w Google Analytics. Te logi zapewniają wgląd w działania użytkownika, które doprowadziły do zarejestrowania w Twojej aplikacji zdarzenia Crashlytics.
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łaszanie wyjątków
Zgłaszanie wykrytych 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, a następnie wysyłane wraz z kolejną wiadomością o krytycznym błędzie lub gdy użytkownik ponownie uruchomi grę.
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 nieprzechwyczonej wyjątków, które nie powodują awarii gry (np. nieprzechwyczonej wyjątków C# w logice gry), możesz skonfigurować pakiet SDK Crashlytics tak, aby zgłaszały je jako zdarzenia krytyczne. W tym celu ustaw właściwość Crashlytics.ReportUncaughtExceptionsAsFatal na true w miejscu, w którym inicjujeszCrashlytics 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 CrashlyticsPamiętaj, że wypadki natywnych aplikacji są zawsze zgłaszane jako krytyczne zdarzenia. 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 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 z tymi danymi.
Raporty o pamięci z GWP-ASan możesz otrzymywać, jeśli Twoja aplikacja używa najnowszego pakietu SDK Crashlytics do Unity (w wersji 10.7.0 lub nowszej) i GWP-ASan jest w niej wyraźnie włączona (musisz zmodyfikować plik 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 na temat Androida.
Dodawanie kluczy niestandardowych
Klucze niestandardowe pomagają uzyskać konkretny 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);
Dodawanie niestandardowych komunikatów z logów
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);
Konfigurowanie 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 podczas przeglądania konkretnej awarii.
Crashlytics.SetUserId(string identifier);
Pobieranie dzienników elementów menu nawigacyjnego
Dzięki dziennikom ścieżek 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żek breadcrumbs 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 breadcrumbs 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, co umożliwia wyświetlanie w logach informacji o ścieżce użytkownika przed wystąpieniem błędu aplikacji, błędu niekrytycznego lub zdarzenia ANR. Plik z logiem informacji o elementach nawigacyjnych screen_view zawiera parametr firebase_screen_class.
W logach ścieżek przechowywane są też wszystkie zdarzenia niestandardowe, które ręcznie rejestrujesz w sesji użytkownika, w tym dane 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 dzienniki ścieżek.
Włączanie raportowania zgodnego z wyrażeniem zgody
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 inicjować Crashlytics tylko w przypadku wybranych użytkowników, wywołaj zastąpienie zbierania danych Crashlytics w czasie wykonywania. Wartość zastąpienia jest zachowywana przy każdym uruchomieniu aplikacji, aby Crashlytics mogła automatycznie zbierać raporty. Aby zrezygnować z automatycznego raportowania awarii, prześlij wartość false jako wartość zastępczą. 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 błędów 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.