Dostosowywanie raportów o awariach Firebase Crashlytics


Na panelu Crashlytics możesz kliknąć problem i uzyskać szczegółowy raport o zdarzeniu. Możesz dostosowywać te raporty, aby lepiej zrozumieć, co się dzieje w Twojej aplikacji, oraz okoliczności zdarzeń zgłaszanych do Crashlytics.

  • Automatyczne uzyskiwanie logów ścieżki, jeśli aplikacja korzysta z pakietu SDK Firebase w przypadku Google Analytics. Logi te zapewniają wgląd w działania użytkowników, które doprowadziły do zdarzenia zebranego przez Crashlytics w Twojej aplikacji.

  • Wyłącz automatyczne raportowanie awarii i włącz raportowanie za zgodą użytkowników. Pamiętaj, że domyślnie Crashlytics automatycznie zbiera raporty o awariach wszystkich użytkowników Twojej aplikacji.

Raportowanie wyjątków

Zgłaszanie wykrytych wyjątków

Jeśli masz wyjątki, których się spodziewasz, możesz skonfigurować pakiet SDK, aby zgłaszał je jako zdarzenia niekrytyczne.Crashlytics Te zdarzenia są rejestrowane na urządzeniu, a następnie wysyłane wraz z kolejnym raportem o błędzie krytycznym lub gdy użytkownik ponownie uruchomi grę.

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

Crashlytics.LogException(Exception ex);

Oczekiwane wyjątki możesz rejestrować 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 nieobsłużonych wyjątków, które nie powodują awarii gry (np. nieobsłużonych wyjątków C# w logice gry), możesz skonfigurować pakiet SDK Crashlytics tak, aby zgłaszał je jako zdarzenia krytyczne. W tym celu ustaw wartość właściwości Crashlytics.ReportUncaughtExceptionsAsFatal na true w miejscu, w którym inicjujesz pakiet SDK Crashlytics w projekcie Unity. Te zdarzenia są zgłaszane do Crashlytics w czasie rzeczywistym bez konieczności ponownego uruchamiania gry przez użytkownika.

Zgłaszanie tych nieobsłużonych wyjątków jako zdarzeń krytycznych oznacza, że będą one uwzględniane w statystykach użytkowników bez awarii i w alertach o szybkości.

Pamiętaj, że awarie natywne są zawsze zgłaszane jako zdarzenia krytyczne. Te zdarzenia są rejestrowane na urządzeniu, a następnie 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();
}

uwzględniać raporty GWP-ASan do debugowania problemów z uszkodzeniem 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ć spowodowane uszkodzeniem pamięci w aplikacji, co jest główną przyczyną luk w zabezpieczeniach aplikacji.

  • Te dane możesz wyświetlić na nowej karcie „Ślady stosu pamięci”, gdy klikniesz szczegóły problemu na Crashlyticspanelu.

  • Możesz też użyć nowego sygnału „Raport GWP-ASan” i filtra, aby szybko wyświetlić wszystkie problemy z tymi danymi.

Raporty o pamięci GWP-ASan możesz otrzymywać, jeśli Twoja aplikacja korzysta z najnowszego Crashlytics pakietu SDK do Unity (wersja 10.7.0 lub nowsza) i ma wyraźnie włączoną funkcję GWP-ASan (wymaga to zmodyfikowania pliku manifestu aplikacji na Androida). Jeśli w aplikacji masz kod w języku C++, możesz przetestować konfigurację GWP-ASan, korzystając z przykładowego kodu natywnego w dokumentacji Androida.

Dodawanie kluczy niestandardowych

Klucze niestandardowe pomagają uzyskać informacje o stanie aplikacji przed awarią. Z raportami o awariach możesz powiązać dowolne pary klucz-wartość, a potem używać kluczy niestandardowych do wyszukiwania i filtrowania raportów o awariach w Firebase konsoli.

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

Jeśli wywołasz tę funkcję kilka razy, nowe wartości istniejących kluczy zaktualizują wartość, a w przypadku zarejestrowania awarii zapisywana jest tylko najnowsza wartość.

Crashlytics.SetCustomKey(string key, string value);

Dodawanie niestandardowych wiadomości dziennika

Zalogowane komunikaty są powiązane z danymi o awariach i są widoczne na Firebase Crashlyticspanelu, gdy wyświetlasz konkretną awarię.

Crashlytics.Log(string message);

Ustawianie identyfikatorów użytkowników

Możesz użyć numeru identyfikacyjnego, tokena lub wartości zaszyfrowanej, aby jednoznacznie zidentyfikować użytkownika końcowego aplikacji bez ujawniania ani przesyłania jego danych osobowych. Możesz też wyczyścić wartość, ustawiając ją na 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żki możesz lepiej poznać interakcje użytkownika z aplikacją, które doprowadziły do awarii, błędu niekrytycznego lub błędu ANR. Te logi mogą być przydatne podczas odtwarzania i debugowania problemu.

Dzienniki ś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 na platformę Google Analytics. Gdy spełnisz te wymagania, dzienniki ścieżki będą automatycznie dołączane do danych zdarzenia na karcie Dzienniki, gdy wyświetlasz szczegóły problemu.

Pakiet SDK Analyticsautomatycznie rejestruje screen_view zdarzenie, dzięki czemu logi ścieżki mogą wyświetlać listę ekranów wyświetlonych przed awarią, błędem niekrytycznym lub zdarzeniem ANR. Dziennik ścieżki screen_view zawiera parametr firebase_screen_class.

Dzienniki ścieżki są też wypełniane zdarzeniami niestandardowymi, które rejestrujesz ręcznie w sesji użytkownika, w tym danymi parametrów zdarzenia. Te dane mogą pokazywać serię działań użytkownika, które doprowadziły do awarii, błędu niekrytycznego lub błędu ANR.

Pamiętaj, że możesz kontrolować zbieranie i wykorzystywanie danych Google Analytics, w tym danych, które wypełniają dzienniki ścieżki.

Włącz raportowanie na podstawie zgody użytkowników

Domyślnie Crashlytics automatycznie zbiera raporty o awariach wszystkich użytkowników Twojej aplikacji. Możesz zapewnić użytkownikom większą kontrolę nad wysyłanymi danymi, umożliwiając im wyrażenie zgody na przesyłanie raportów o awariach.

Aby wyłączyć automatyczne zbieranie danych tylko w przypadku wybranych użytkowników, wywołaj w czasie działania programu Crashlyticszastąpienie zbierania danych. Wartość zastąpienia jest zachowywana we wszystkich kolejnych uruchomieniach aplikacji, dzięki czemu Crashlytics może automatycznie zbierać raporty dotyczące tego użytkownika.

Crashlytics.IsCrashlyticsCollectionEnabled = true

Jeśli użytkownik później zrezygnuje ze zbierania danych, możesz przekazać wartość zastępczą false. Zostanie ona zastosowana przy następnym uruchomieniu aplikacji przez użytkownika i będzie obowiązywać przy wszystkich kolejnych uruchomieniach.

Zarządzanie danymi statystyk awarii

Analiza awarii pomaga rozwiązywać problemy, porównując zanonimizowane zrzuty stosu z zrzutami z innych aplikacji Firebase i informując, czy problem jest częścią większego trendu. W przypadku wielu problemów statystyki awarii udostępniają nawet zasoby, które pomagają w debugowaniu awarii.

Crash Insights korzysta z zagregowanych danych o awariach, aby identyfikować typowe trendy dotyczące stabilności. Jeśli nie chcesz udostępniać danych aplikacji, możesz zrezygnować z korzystania z funkcji Statystyki awarii. Aby to zrobić, otwórz menu Statystyki awarii u góry Crashlyticslisty problemów w Firebasekonsoli.