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 Firebase konsoli. 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 systemowe 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, aby debugować problemy 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.

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

  • Te dane możesz wyświetlić w nowej karcie „Ślady 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 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ć konkretny stan 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 DevOps i zaangażowanie > Crashlytics panelu w Firebase konsoli.

  • 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 (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 rejestrowana jest tylko najnowsza wartość.

Crashlytics.SetCustomKey(string key, string value);

Dodawanie niestandardowych wiadomości z dziennika

Aby uzyskać więcej kontekstu dotyczącego zdarzeń, które doprowadziły do awarii, możesz dodać niestandardowe Crashlytics dzienniki do aplikacji. Crashlytics powiąże dzienniki z danymi o awarii i wyświetli je na karcie Dzienniki , gdy wyświetlisz szczegóły problemu (wszystkie problemy znajdziesz w panelu DevOps i zaangażowanie > Crashlytics dashboard w konsoli Firebase).

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 wyświetlana podczas przeglądania konkretnej awarii w panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase.

Crashlytics.SetUserId(string identifier);

Pobieranie dzienników ścieżki

Dzienniki ścieżki pozwalają lepiej zrozumieć interakcje użytkownika z aplikacją, które doprowadziły do awarii, zdarzenia niekrytycznego lub zdarzenia ANR. Te dzienniki mogą być przydatne podczas próby odtworzenia 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 dla Google Analytics. Gdy te wymagania zostaną spełnione, dzienniki ścieżki będą automatycznie dołączane do danych zdarzenia na karcie Dzienniki , gdy wyświetlisz szczegóły problemu (wszystkie problemy znajdziesz w panelu DevOps i zaangażowanie > Crashlytics w konsoli Firebase).

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

Dzienniki ś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ą pomóc w pokazaniu serii działań użytkownika, które doprowadziły do awarii, zdarzenia niekrytycznego lub zdarzenia ANR.

Pamiętaj, że możesz kontrolować zbieranie i wykorzystywanie danychGoogle Analytics, w tym danych, które wypełniają dzienniki ś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 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, która zostanie 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ą nawet 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ów w panelu DevOps i zaangażowanie > Crashlytics konsoli Firebase.

Dalsze kroki