Dostosowywanie raportów o awariach w Unity

Wybierz platformę: iOS+ Android Flutter Unity


Możesz kliknąć problem i wyświetlić szczegółowy raport Zdarzenia w Firebase konsoli na panelu DevOps i zaangażowanie > Crashlytics. Możesz dostosowywać te raporty, aby lepiej zrozumieć, co dzieje się w aplikacji i jakie są okoliczności zdarzeń zgłaszanych do Crashlytics.

Zgłaszanie wyjątków

Zgłaszaj wykryte wyjątki

Jeśli masz wyjątki, które są oczekiwane, 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 następnym 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);

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

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

Zgłaszanie niewykrytych wyjątków

W przypadku nieprzechwyconych wyjątków, które nie powodują awarii gry (np. nieprzechwyconych wyjątków C# w logice gry), możesz skonfigurować pakiet SDK Crashlytics, aby zgłaszał je jako zdarzenia krytyczne. W tym celu ustaw właściwość Crashlytics.ReportUncaughtExceptionsAsFatal na true w miejscu, w którym inicjujesz pakiet 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ługiwanych wyjątków jako zdarzeń krytycznych oznacza, że będą one uwzględniane w statystykach użytkowników bez awarii i w alertach dotyczących szybkości.

Pamiętaj, że awarie systemowe są zawsze zgłaszane jako błędy 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ędnianie raportów GWP-ASan w celu debugowania problemów z uszkodzeniem pamięci

W przypadku aplikacji na Androida, które używają 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ć powiązane z uszkodzeniem pamięci w aplikacji, co jest główną przyczyną luk w zabezpieczeniach aplikacji.

W panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase możesz wykonać 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 i filtra „Raport GWP-ASan”, aby szybko wyświetlić wszystkie problemy z tymi danymi.

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

Dodawanie kluczy niestandardowych

Klucze niestandardowe pomagają poznać konkretny stan aplikacji, który doprowadził do awarii. Z raportami o awariach możesz powiązać dowolne pary klucz-wartość, a następnie używać kluczy niestandardowych do wyszukiwania i filtrowania raportów o awariach w panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase.

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

Jeśli metoda jest wywoływana wielokrotnie, nowe wartości istniejących kluczy będą aktualizować wartość, a podczas rejestrowania awarii będzie rejestrowana tylko najbardziej aktualna wartość.

Crashlytics.SetCustomKey(string key, string value);

Dodawanie niestandardowych komunikatów logu

Aby uzyskać więcej informacji o zdarzeniach, które doprowadziły do awarii, możesz dodać do aplikacji niestandardowe dzienniki Crashlytics. Crashlytics powiąże dzienniki z danymi o awariach i wyświetli je na karcie Dzienniki, gdy będziesz przeglądać szczegóły problemu (wszystkie problemy możesz zobaczyć w Firebase Console na panelu DevOps i zaangażowanie > Crashlytics).

Crashlytics.Log(string message);

Ustawianie identyfikatorów użytkowników

Możesz użyć numeru identyfikacyjnego, tokena lub wartości skrótu, aby jednoznacznie zidentyfikować użytkownika aplikacji bez ujawniania lub 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 wyświetlania konkretnej awarii w panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase.

Crashlytics.SetUserId(string identifier);

Pobieranie logów działań użytkownika

Logi działań użytkownika pozwalają lepiej zrozumieć interakcje użytkownika z aplikacją, które doprowadziły do awarii, błędu niekrytycznego lub błędu ANR. Te dzienniki mogą być przydatne podczas prób odtworzenia i debugowania problemu.

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

Pakiet SDK Analytics automatycznie rejestruje zdarzenie screen_view, dzięki czemu logi działań użytkownika mogą wyświetlać listę ekranów wyświetlonych przed awarią, błędem niekrytycznym lub zdarzeniem ANR. Log działań użytkownika screen_view zawiera parametr firebase_screen_class.

Logi działań użytkownika są też wypełniane wszelkimi zdarzeniami niestandardowymi, które ręcznie rejestrujesz 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 działań użytkownika.

Włączanie raportowania o wyrażeniu zgody

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

Aby wyłączyć automatyczne zbieranie danych tylko w przypadku wybranych użytkowników, wywołaj w czasie działania aplikacji zastąpienie zbierania danych Crashlytics. 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ępującą false, która zostanie 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 ze zrzutami z innych aplikacji w Firebase i informując, czy problem jest częścią większego trendu. W przypadku wielu problemów Crash Insights udostępnia nawet zasoby, które pomagają w debugowaniu awarii.

Statystyki awarii wykorzystują zbiorcze dane o awariach do identyfikowania typowych trendów dotyczących stabilności. Jeśli nie chcesz udostępniać danych aplikacji, możesz zrezygnować ze Statystyk awarii w menu Statystyki awarii u góry listy problemów w panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase.

Dalsze kroki