Dostosowywanie raportów o awariach w Unity

Wybierz platformę: iOS+ Android Flutter Unity


Możesz kliknąć problem i uzyskać szczegółowy raport o zdarzeniu w panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase. Możesz dostosowywać te raporty, aby lepiej rozumieć, co się dzieje w Twojej aplikacji, i okoliczności zdarzeń zgłaszanych do Crashlytics.

Raportowanie wyjątków

Zgłaszanie wykrytych wyjątków

Jeśli masz wyjątki, których się spodziewasz, możesz skonfigurować pakiet SDK Crashlytics, aby zgłaszał je jako zdarzenia niekrytyczne. 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 w C# możesz rejestrować za pomocą tej metody:

Crashlytics.LogException(Exception ex);

Oczekiwane wyjątki możesz rejestrować w blokach try/catch w swojej 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żone wyjątki 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.

Raportowanie 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 błędy 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 zawartości pamięci w aplikacji, co jest główną przyczyną luk w zabezpieczeniach aplikacji.

W panelu Crashlytics DevOps i zaangażowanie w konsoli Firebase możesz wykonywać te czynności:

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

  • Możesz 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 Crashlyticspakietu 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 na panelu DevOps i zaangażowanie > Crashlytics w Firebase konsoli.

  • 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 (karta Klucze), a nawet filtrować zdarzenia według kluczy niestandardowych (menu Filtruj u góry strony).

Jeśli funkcja jest wywoływana wielokrotnie, nowe wartości istniejących kluczy aktualizują wartość, a w przypadku zarejestrowania awarii zapisywana jest tylko najnowsza wartość.

Crashlytics.SetCustomKey(string key, string value);

Dodawanie niestandardowych wiadomości w logach

Aby uzyskać więcej informacji o zdarzeniach poprzedzających awarię, możesz dodać do aplikacji niestandardowe Crashlyticsdzienniki. Crashlyticspowiąże dzienniki z danymi o awarii i wyświetli je na karcie Dzienniki, gdy będziesz przeglądać szczegóły problemu (wszystkie problemy znajdziesz na panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase).

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 podczas przeglądania konkretnej awarii na panelu DevOps i zaangażowanie > Crashlytics w konsoliFirebase.

Crashlytics.SetUserId(string identifier);

Pobieranie dzienników elementów menu nawigacyjnego

Dzienniki ścieżki pozwalają lepiej zrozumieć interakcje użytkownika z aplikacją, które doprowadziły do awarii, błędu niekrytycznego lub błędu ANR. Dzienniki te mogą być przydatne podczas odtwarzania i debugowania problemu.

Dzienniki ścieżki są obsługiwane przez Google Analytics, więc aby uzyskać logi działań użytkownika, musisz włączyć Google Analytics w projekcie w Firebase i dodać do aplikacji [pakiet] SDK Firebase na Google Analytics. Gdy spełnisz te wymagania, logi działań użytkownika będą automatycznie dołączane do danych zdarzenia na karcie Dzienniki, gdy wyświetlasz szczegóły problemu (wszystkie problemy znajdziesz na panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase).

Pakiet SDK Analyticsautomatycznie rejestruje screen_viewzdarzenie, co umożliwia wyświetlanie w logach ścieżki listy 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ą logi ś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 funkcję Crashlyticszastępowania 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 Crash Insights

Crash Insights 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 używa zagregowanych danych o awariach do identyfikowania typowych trendów dotyczących stabilności. Jeśli nie chcesz udostępniać danych aplikacji, możesz zrezygnować z Crash Insights w menu Crash Insights u góry listy problemów na panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase.

Dalsze kroki

  • Eksportuj dane do BigQuery lub Cloud Logging, aby korzystać z zaawansowanych analiz i funkcji, takich jak wysyłanie zapytań dotyczących danych, tworzenie niestandardowych paneli i konfigurowanie niestandardowych alertów.