Rozwiązywanie problemów z Crashlytics i najczęstsze pytania

W tabeli Problemy widoczne są różne formaty (a czasem „warianty”) w przypadku niektórych problemów

W tabeli Problemy w konsoli Firebase mogą pojawić się 2 różne formaty problemów. W niektórych problemach możesz też zauważyć funkcję o nazwie „Warianty”. Oto dlaczego.

Na początku 2023 r. wdrożyliśmy ulepszony mechanizm analizy grupowania zdarzeń, a także zaktualizowany wygląd i kilka zaawansowanych funkcji związanych z nowymi problemami (np. wariantami). Przeczytaj nasz najnowszy post na blogu, aby poznać wszystkie szczegóły. Możesz też przeczytać najważniejsze informacje poniżej.

Crashlytics analizuje wszystkie zdarzenia z aplikacji (takie jak awarie, błędy niekrytyczne czy błędy ANR) i tworzy grupy zdarzeń nazywane problemami. Wszystkie zdarzenia związane z problemem mają wspólny punkt awarii.

Aby grupować zdarzenia w te problemy, ulepszony mechanizm analizy analizuje wiele aspektów zdarzenia, w tym ramki w zrzucie stosu, komunikat o wyjątku, kod błędu i inne cechy platformy lub typu błędu.

Jednak w tej grupie zdarzeń zrzuty stosu prowadzące do niepowodzenia mogą być inne. Inny zrzut stosu może oznaczać inną przyczynę problemu. Aby odzwierciedlić tę możliwą różnicę w obrębie problemu, tworzymy teraz w obrębie problemu warianty – każdy wariant jest podgrupą zdarzeń związanych z problemem, które mają ten sam punkt błędu oraz podobny zrzut stosu. Dzięki wariantom możesz debugować najczęstsze zrzuty stosu w obrębie danego problemu i określić, czy różne główne przyczyny niepowodzenia prowadzą do problemów.

Oto, czego się spodziewać po wprowadzeniu tych ulepszeń:

• Odświeżone metadane wyświetlane w wierszu problemu
  Teraz łatwiej zrozumiesz i sprawdzisz problemy z aplikacją.

• Mniej zduplikowanych problemów
  Zmiana numeru wiersza nie powoduje utworzenia nowego problemu.

• Łatwiejsze debugowanie złożonych problemów o różnych przyczynach
  Używaj wariantów do debugowania najczęstszych zrzutów stosu w obrębie danego problemu.

• Bardziej przydatne alerty i sygnały
  Nowy problem w rzeczywistości oznacza nowy błąd.

• Bardziej zaawansowane wyszukiwanie
  Każdy numer zawiera metadane, które łatwiej wyszukać, takie jak typ wyjątku i nazwa pakietu.

Oto jak wprowadzamy te ulepszenia:

• Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy nie występują w nich jakieś problemy.

• Jeśli nie uda się dopasować danych, automatycznie zastosujemy do wydarzenia nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z odświeżonym wyglądem metadanych.

To pierwsza duża aktualizacja, w której wprowadzamy zmiany w naszej grupie wydarzeń. Jeśli masz uwagi lub masz problemy, skontaktuj się z nami, przesyłając zgłoszenie .

Brak alertów dotyczących braku awarii lub alertów o rosnącej liczbie problemów

Jeśli nie widzisz danych o braku awarii (takich jak liczba użytkowników, u których nie wystąpiła awaria) lub alerty o porcie

Nie widzę logów menu nawigacyjnego

Jeśli nie widzisz dzienników menu nawigacyjnego, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics. Upewnij się, że spełniasz te wymagania:

• W projekcie Firebase masz włączoną usługę Google Analytics.

• Masz włączone udostępnianie danych w Google Analytics. Więcej informacji o tym ustawieniu znajdziesz w artykule Zarządzanie ustawieniami udostępniania danych Analytics.

• Dodałeś pakiet SDK Firebase dla Google Analytics do swojej aplikacji. Ten pakiet musisz też dodatkowo dodać do Crashlytics SDK.

• Używasz najnowsze wersje pakietu Firebase SDK we wszystkich usługach, których używasz w swojej aplikacji.

Wyświetlanie niesymbolicznych zrzutów stosu aplikacji na Androida w panelu Crashlytics

Jeśli korzystasz z Unity IL2CPP i widzisz niesymboliczne zrzuty stosu, wykonaj te czynności:

1. Sprawdź, czy używasz pakietu SDK Crashlytics Unity w wersji 8.6.1 lub nowszej.

2. Upewnij się, że masz skonfigurowane polecenie crashlytics:symbols:upload interfejsu wiersza poleceń Firebase w celu wygenerowania i przesłania pliku symboli.

   Musisz uruchamiać to polecenie interfejsu wiersza poleceń za każdym razem, gdy tworzysz kompilację wersji lub dowolną kompilację, dla której chcesz wyświetlać w konsoli Firebase symbolizowane zrzuty stosu. Więcej informacji znajdziesz na stronie Uzyskiwanie czytelnych raportów o awariach.

Czy Crashlytics można używać z aplikacjami używającymi IL2CPP?

Tak. Crashlytics może wyświetlać symbolizowane zrzuty stosu aplikacji, które używają IL2CPP. Ta funkcja jest dostępna w przypadku aplikacji wydanych na platformy Android lub Apple. Oto co musisz zrobić:

1. Upewnij się, że używasz pakietu SDK Crashlytics Unity w wersji 8.6.0 lub nowszej.

2. Wykonaj czynności niezbędne dla swojej platformy:

   • W przypadku aplikacji na platformie Apple: nie jest wymagane żadne dodatkowe działanie. W przypadku aplikacji na platformie Apple wtyczka Firebase Unity Editor automatycznie konfiguruje projekt Xcode w celu przesyłania symboli.

   • W przypadku aplikacji na Androida: upewnij się, że masz skonfigurowane i uruchomisz polecenie interfejsu wiersza poleceń Firebase crashlytics:symbols:upload, aby wygenerować i przesłać plik symboli.

     Musisz uruchamiać to polecenie interfejsu wiersza poleceń za każdym razem, gdy tworzysz kompilację wersji lub dowolną kompilację, dla której chcesz wyświetlać w konsoli Firebase symbolizowane zrzuty stosu. Więcej informacji znajdziesz na stronie Uzyskiwanie czytelnych raportów o awariach.

Jak oblicza się liczbę użytkowników, u których nie wystąpiła awaria?

Wartość oznaczająca brak awarii to odsetek użytkowników, którzy korzystali z Twojej aplikacji, ale nie w określonym przedziale czasu jej wystąpiła.

Oto wzór do obliczania odsetka użytkowników, u których nie wystąpiła awaria. Jego wartości wejściowe są dostarczane przez Google Analytics.

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

• Gdy zdarzy się awaria, Google Analytics wysyła typ zdarzenia app_exception, a CRASHED_USERS reprezentuje liczbę użytkowników powiązanych z tym typem zdarzenia.

• ALL_USERS reprezentuje łączną liczbę użytkowników, którzy korzystali z Twojej aplikacji w okresie wybranym z menu w prawym górnym rogu panelu Crashlytics.

Odsetek użytkowników, u których nie wystąpiła awaria, to wartość zbiorcza w czasie, a nie średnia.

Załóżmy na przykład, że Twoja aplikacja ma 3 użytkowników, których nazwa zostanie określona jako Użytkownik A, Użytkownik B i C. Tabela poniżej pokazuje, którzy użytkownicy wchodzili w interakcje z Twoją aplikacją każdego dnia i którzy z nich mieli awarię tego dnia:

• W środę odsetek użytkowników, u których nie wystąpiła awaria, wynosi 50% (u 1 na 2 użytkowników nie wystąpiła awaria).
  Dwóch użytkowników korzystało w środę z Twojej aplikacji, ale tylko jeden z nich (Użytkownik B) nie miał żadnych awarii.

• W ciągu ostatnich 2 dni odsetek użytkowników, u których nie wystąpiła awaria, wynosi 33,3% (1 na 3 użytkowników nie wystąpiła u niej).
  Trzech Twoich użytkowników korzystało z Twojej aplikacji w ciągu ostatnich 2 dni, ale tylko jeden z nich (Użytkownik C) nie odnotował żadnych awarii.

• W ciągu ostatnich 3 dni odsetek użytkowników, u których nie wystąpiła awaria, wynosi 0% (0 na 3 użytkowników nie wystąpiło.
  Trzech Twoich użytkowników korzystało z Twojej aplikacji w ciągu ostatnich 3 dni, ale u żadnego z nich nie wystąpiła żadna awaria.

Nie należy porównywać wartości Użytkownicy, u których nie wystąpiła awaria, w różnych okresach. Prawdopodobieństwo awarii danego użytkownika rośnie, im częściej korzysta on z Twojej aplikacji, więc liczba użytkowników, u których nie wystąpiła awaria, będzie mniejsza w dłuższym okresie.

Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?

Notatki umożliwiają członkom projektu komentowanie konkretnych problemów związanych z pytaniami, aktualizacjami stanu itp.

Gdy członek projektu opublikuje notatkę, jest ona oznaczona etykietą z adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich użytkowników projektu, którzy mają uprawnienia do jej wyświetlania.

Poniżej znajdziesz opis uprawnień wymaganych do wyświetlania, pisania i usuwania notatek:

• Członkowie projektu z dowolną z poniższych ról mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.

  • Właściciel lub edytujący projekt, administrator Firebase, administrator jakości lub administrator Crashlytics

• Członkowie projektu z dowolną z poniższych ról mogą wyświetlać opublikowane notatki na temat problemu, ale nie mogą usuwać ani pisać notatek.

  • Wyświetlający projekt, Wyświetlający Firebase, Wyświetlający jakość lub Wyświetlający Crashlytics

Jak oblicza się liczbę użytkowników, u których nie wystąpiła awaria?

Zapoznaj się z sekcją Dane bez awarii.

Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?

Notatki umożliwiają członkom projektu komentowanie konkretnych problemów związanych z pytaniami, aktualizacjami stanu itp.

Gdy członek projektu opublikuje notatkę, jest ona oznaczona etykietą z adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich użytkowników projektu, którzy mają uprawnienia do jej wyświetlania.

Poniżej znajdziesz opis uprawnień wymaganych do wyświetlania, pisania i usuwania notatek:

• Członkowie projektu z dowolną z poniższych ról mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.

  • Właściciel lub edytujący projekt, administrator Firebase, administrator jakości lub administrator Crashlytics

• Członkowie projektu z dowolną z poniższych ról mogą wyświetlać opublikowane notatki na temat problemu, ale nie mogą usuwać ani pisać notatek.

  • Wyświetlający projekt, Wyświetlający Firebase, Wyświetlający jakość lub Wyświetlający Crashlytics

Aplikacja korzysta też z pakietu SDK do reklam mobilnych Google, ale nie ulega awarii

Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, prawdopodobnie zgłaszający awarie zakłócają proces rejestrowania modułów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie awarii w pakiecie SDK do reklam mobilnych, wywołując disableSDKCrashReporting.

Gdzie znajduje się mój zbiór danych BigQuery?

Gdy połączysz Crashlytics z BigQuery, nowe zbiory danych, które utworzysz, będą automatycznie znajdować się w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.

Co to jest problem, który pojawił się ponownie?

Po zamknięciu przez Ciebie wcześniej problemu powrócił on do normalnego stanu, ale Crashlytics otrzyma nowy raport o ponownym wystąpieniu problemu. Crashlytics automatycznie ponownie otwiera te problemy, aby można było je naprawić w sposób odpowiedni dla aplikacji.

Oto przykładowy scenariusz, który wyjaśnia, jak Crashlytics klasyfikuje problem jako regresję:

1. Po raz pierwszy Crashlytics otrzymuje raport o awarii „A”. Crashlytics otworzy odpowiedni problem związany z tą awarią (problem „A”).
2. Szybko naprawiasz ten błąd, zamykasz problem „A” i publikujesz nową wersję aplikacji.
3. Gdy go zamkniesz, Crashlytics otrzyma kolejny raport dotyczący problemu „A”.
   • Jeśli raport pochodzi z wersji aplikacji, o której usługa Crashlytics była znana w momencie zamknięcia problemu (co oznacza, że wysłała raport o awarii w przypadku każdej awarii), Crashlytics nie uzna go za problem ponownie występujący. Problem pozostanie zamknięty.
   • Jeśli raport dotyczy wersji aplikacji, o której usługa Crashlytics nie wiedziała w momencie zamknięcia problemu (co oznacza, że ta wersja nigdy w ogóle nie wysyłała żadnego raportu o awarii), Crashlytics uzna problem za niewystępujący i ponownie go otworzy.

Gdy problem wystąpi ponownie, wyślemy alert dotyczący wykrywania regresji i dodamy do niego sygnał, aby poinformować Cię, że Crashlytics ponownie uruchomiło problem. Jeśli nie chcesz, aby problem otwierał się ponownie z powodu naszego algorytmu regresji, zamiast go zamykać, możesz go „zignorować”.

Dlaczego w przypadku starszych wersji aplikacji pojawiają się problemy, które ponownie się pojawiły?

Jeśli raport pochodzi ze starej wersji aplikacji, która nigdy nie wysyłała żadnych raportów o awariach po zamknięciu problemu, Crashlytics uzna, że problem się powtarza, i ponownie go otworzy.

Może się tak zdarzyć w takiej sytuacji: naprawiono błąd i opublikowano nową wersję aplikacji, ale użytkownicy nadal korzystają ze starszych wersji bez tych poprawek. Jeśli przypadkiem jedna ze starszych wersji nigdy w ogóle nie wysłała żadnych raportów o awariach w momencie zamknięcia problemu, a użytkownicy zaczęli napotkać błąd, wtedy te raporty o awariach wywołałyby problem ponownie.

Jeśli nie chcesz, aby problem otwierał się ponownie z powodu naszego algorytmu regresji, zamiast go zamykać, „zignoruj” go.

Dlaczego aplikacja powinna zgłaszać niewykryte wyjątki jako błędy krytyczne?

Zgłaszając niewykryte wyjątki jako krytyczne, uzyskujesz bardziej realistyczne informacje o tym, które wyjątki mogą spowodować brak możliwości zagrania w grze nawet wtedy, gdy aplikacja nadal działa.

Pamiętaj, że jeśli zaczniesz zgłaszać błędy krytyczne, odsetek użytkowników, u których nie wystąpiła awaria, prawdopodobnie spadnie, ale dane dotyczące CFU będą bardziej reprezentatywne dla wygody użytkowników Twojej aplikacji.

Jakie wyjątki zostaną zgłoszone jako krytyczne?

Aby Crashlytics zgłosiło niewykryty wyjątek jako krytyczny, muszą być spełnione oba te 2 warunki:

• Podczas inicjowania aplikacji właściwość ReportUncaughtExceptionsAsFatal musi być ustawiona na true.

• Aplikacja (lub dołączona biblioteka) zgłasza wyjątek, który nie jest przechwycony. Wyjątek, który zostaje utworzony, ale nie został zgłoszony, nie jest uważany za nieprzechwycony.

Po włączeniu zgłaszania niewykrytych wyjątków jako błędów krytycznych mam teraz wiele nowych takich przypadków. Jak prawidłowo obsługiwać te wyjątki?

Gdy zaczniesz otrzymywać raporty o niewykrytych wyjątkach jako krytycznych, możesz skorzystać z tych niewykrytych wyjątków:

• Zastanów się, jak możesz zacząć wychwytywać i radzić sobie z tymi niewykrytymi wyjątkami.
• Rozważ różne opcje rejestrowania wyjątków w konsoli debugowania Unity i w Crashlytics.

Wykrywanie i obsługa zgłoszonych wyjątków

Wyjątki są tworzone i zgłaszane, by odzwierciedlić nieoczekiwane lub wyjątkowe stany. Rozwiązanie problemów wykrytych przez zgłoszony wyjątek obejmuje przywrócenie programu do znanego stanu (jest to proces nazywany obsługą wyjątków).

Sprawdzoną metodą jest wychwytywanie i obsługa wszystkich przewidywanych wyjątków, chyba że programu nie można przywrócić do znanego stanu.

Aby kontrolować, jakie wyjątki mają być wykrywane i obsługiwane przez jaki kod, zapakuj kod, który może generować wyjątek w bloku try-catch. Zadbaj o to, aby warunki w instrukcjach catch były możliwie jak najwęższe, aby można było odpowiednio uwzględnić konkretne wyjątki.

Rejestrowanie wyjątków w Unity lub Crashlytics

Aby ułatwić debugowanie problemu, możesz rejestrować wyjątki w Unity lub Crashlytics na kilka sposobów.

Jeśli używasz Crashlytics, masz do wyboru 2 najczęstsze i zalecane opcje:

• Opcja 1. Drukowanie w konsoli Unity, ale bez zgłaszania się do Crashlytics w trakcie programowania lub rozwiązywania problemów

  • Wydrukuj w konsoli Unity polecenie Debug.Log(exception), Debug.LogWarning(exception) i Debug.LogError(exception), które drukują zawartość wyjątku do konsoli Unity i nie powodują go ponownie.

• Opcja 2. Prześlij do Crashlytics, aby tworzyć skonsolidowane raporty w panelu Crashlytics i je przesyłać w tych sytuacjach:

  • Jeśli chcesz zarejestrować wyjątek, aby debugować możliwe kolejne zdarzenie Crashlytics, użyj zdarzenia Crashlytics.Log(exception.ToString()).
  • Jeśli wyjątek powinien być przesyłany do Crashlytics pomimo jego przechwycenia i obsługi, użyj Crashlytics.LogException(exception) do zarejestrowania go jako zdarzenia niekrytycznego.

Jeśli jednak chcesz ręcznie zgłosić zdarzenie krytyczne w Unity Cloud Test, możesz użyć polecenia Debug.LogException. Ta opcja powoduje umieszczenie wyjątku w konsoli Unity, tak jak w przypadku opcji 1, ale zgłasza też wyjątek (niezależnie od tego, czy został on już zgłoszony czy przechwycony). Ten błąd jest zgłaszany nielokalnie. Oznacza to, że nawet otaczające go bloki Debug.LogException(exception) z try-catch nadal stanowią niewyłapany wyjątek.

Wywołaj Debug.LogException wtedy, gdy chcesz wykonywać wszystkie te czynności:

• Aby wydrukować wyjątek w konsoli Unity.
• Aby przesłać wyjątek do Crashlytics jako zdarzenia krytycznego.
• Aby zgłosić wyjątek, należy traktować go jako uncaught wyjątek i zgłaszać go do narzędzia Unity Cloud Diagnostyka.

Jeśli chcesz wydrukować zarejestrowany wyjątek w konsoli Unity oraz przesłać go do Crashlytics jako zdarzenie niekrytyczne, wykonaj te czynności:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}