Dostosowywanie raportów o awariach w Unity

Wybierz platformę: iOS+ Android Flutter Unity


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

Zgłaszanie wyjątków

Zgłaszanie przechwyconych wyjątków

Jeśli masz wyjątki, które są oczekiwane, możesz skonfigurować Crashlytics SDK tak, 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 zdarzeniu krytycznym lub gdy użytkownik ponownie uruchomi grę.

Wyjątki w języku C# możesz rejestrować 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 nieprzechwyconych 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 Crashlytics tak, aby zgłaszał je jako zdarzenia krytyczne. W tym celu ustaw właściwość Crashlytics.ReportUncaughtExceptionsAsFatal na true w miejscu, w którym inicjujesz 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 nieprzechwyconych 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();
}

Dołączanie raportów 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ć powią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 "Ślady stosu pamięci", gdy klikniesz szczegóły problemu w Crashlytics panelu.

  • 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 uzyskać, jeśli Twoja aplikacja korzysta z najnowszego Crashlytics SDK dla Unity (w wersji 10.7.0 lub nowszej) i ma 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ą uzyskać informacje o konkretnym stanie aplikacji, który doprowadził do awarii. Możesz powiązać dowolne pary klucz-wartość z raportami o awariach, a następnie użyć kluczy niestandardowych do wyszukiwania i filtrowania raportów o awariach w Firebase konsoli.

  • W panelu Crashlyticsdashboard możesz wyszukiwać problemy pasujące do klucza niestandardowego.
  • Gdy przeglądasz konkretny problem w konsoli, możesz wyświetlić powiązane klucze niestandardowe dla każdego zdarzenia (podkarta Klucze) oraz filtrować zdarzenia według kluczy niestandardowych (menu Filtr u góry strony).

Gdy funkcja jest wywoływana wielokrotnie, nowe wartości istniejących kluczy aktualizują wartość, a podczas rejestrowania awarii zapisywana jest tylko najnowsza wartość.

Crashlytics.SetCustomKey(string key, string value);

Dodawanie niestandardowych komunikatów w logach

Zarejestrowane komunikaty są powiązane z danymi o awariach i są widoczne w panelu Firebase Crashlytics podczas wyświetlania konkretnej awarii.

Crashlytics.Log(string message);

Ustawianie identyfikatorów użytkowników

Możesz użyć numeru identyfikacyjnego, tokena lub zaszyfrowanej wartości, aby jednoznacznie zidentyfikować użytkownika 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 widoczna w panel0/} podczas wyświetlania konkretnej awarii.Firebase Crashlytics

Crashlytics.SetUserId(string identifier);

Pobieranie logów ścieżki

Logi ścieżki pozwalają lepiej zrozumieć interakcje użytkownika z aplikacją, które doprowadziły do awarii, zdarzenia niekrytycznego lub zdarzenia 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 te wymagania zostaną spełnione, logi ścieżki będą automatycznie dołączane do danych zdarzenia na karcie Logi podczas wyświetlania szczegółów problemu.

Pakiet SDK Analytics Analytics automatycznie rejestruje zdarzenie screen_view które umożliwia wyświetlanie w logach ścieżki listy ekranów wyświetlanych przed awarią, zdarzeniem niekrytycznym lub zdarzeniem ANR. Log ścieżki screen_view zawiera parametr firebase_screen_class.

Logi ścieżki są też wypełniane wszystkimi 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, zdarzenia niekrytycznego lub zdarzenia ANR.

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

Włączanie raportowania, na które użytkownicy muszą wyrazić zgodę

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

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

Crashlytics.IsCrashlyticsCollectionEnabled = true

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

Zarządzanie danymi statystyk awarii

Statystyki awarii pomagają rozwiązywać problemy, porównując zanonimizowane ślady stosu z innymi aplikacjami Firebase i informując, czy Twój problem jest częścią większego trendu. W przypadku wielu problemów statystyki awarii udostępniają też zasoby, które pomagają w debugowaniu awarii.

Statystyki awarii używają zagregowanych danych o awariach do identyfikowania typowych trendów 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ówCrashlytics w konsoli Firebase.

Dalsze kroki