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

iOS+ Android Flutter Unity

Na tej stronie znajdziesz pomoc dotyczącą rozwiązywania problemów oraz odpowiedzi na najczęstsze pytania dotyczące Crashlytics. Jeśli nie możesz znaleźć tego, czego szukasz, lub potrzebujesz dodatkowej pomocy, skontaktuj się z zespołem pomocy Firebase.

Rozwiązywanie problemów/najczęstsze pytania

Różne formaty (a czasem „warianty”) w przypadku niektórych problemów w tabeli Problemy.

W tabeli Problemy możesz zobaczyć 2 różne formaty problemów w konsoli Firebase. Możesz też zauważyć funkcję „warianty” w niektórych kwestiach. Oto dlaczego.

Na początku 2023 r. wdrożyliśmy ulepszony mechanizm analizy grupujący zdarzenia jako a także zaktualizowany wygląd i niektóre zaawansowane funkcje w przypadku nowych problemów (np. wersji). Zobacz nasze najnowsze post na blogu .

Crashlytics analizuje wszystkie zdarzenia z aplikacji (np. awarie, błędy niekrytyczne i błędy ANR) oraz tworzy grupy zdarzeń o nazwie problemy – wszystkie zdarzenia w problemie mają wspólny punkt awarii.

Aby pogrupować zdarzenia w te problemy, ulepszony mechanizm analizy analizuje teraz: wielu aspektów zdarzenia, w tym ramki zrzutu stosu, komunikat o wyjątku, kod błędu oraz inną platformę lub typ błędu dla niektórych cech produktu.

W ramach tej grupy zdarzeń ścieżki stosu prowadzące do błędu mogą się jednak różnić. Inny zrzut stosu może oznaczać inną przyczynę problemu. Aby odzwierciedlić tę możliwą różnicę w ramach problemu, tworzymy warianty w ramach problemów – każdy wariant jest podgrupą zdarzeń w danym problemie. które mają ten sam punkt błędu i podobny zrzut stosu. Za pomocą wariantów możesz debugować najczęstsze ścieżki stosu w ramach problemu i określać, czy do niepowodzenia prowadzą różne przyczyny.

Oto, co się zmieni:

• Zmienione metadane wyświetlane w wierszu z problemem
  Zrozumienie i rozwiązywanie problemów w aplikacji jest teraz łatwiejsze.

• Mniej zduplikowanych problemów
  Zmiana numeru wiersza nie powoduje pojawienia się 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 problemu.

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

• Bardziej zaawansowane wyszukiwanie
  Każdy problem zawiera więcej metadanych, które można wyszukiwać, na przykład typ wyjątku i nazwę pakietu.

Oto jak wprowadzamy te ulepszenia:

• Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy pasują one do istniejącego problemu.

• Jeśli nie, automatycznie zastosujemy lepszy sposób grupowania zdarzeń. algorytm do zdarzenia i sformułować nowy problem ze zmienionymi metadanymi. projektu.

To pierwsza duża aktualizacja, którą wprowadzamy w grupowaniu wydarzeń. Jeśli chcesz podzielić się opinią lub napotkasz problem, prześlij raport.

Nie widać dane o braku awarii lub alerty o szybkości

Jeśli nie widzisz danych o użytkownikach i sesjach bez awarii ani alertów dotyczących szybkości, sprawdź, czy używasz

Nie widzę logów menu nawigacyjnego

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

• Masz włączoną Google Analytics w projekcie Firebase.

• Włączono udostępnianie danych dla: Google Analytics. Więcej informacji o to ustawienie w Zarządzanie ustawieniami udostępniania danych Analytics

• Masz dodał(a) pakiet SDK Firebase dla aplikacji Google Analytics do Twojej aplikacji. Ten pakiet SDK należy dodatkowo dodać do Crashlytics SDK.

• Używasz najnowsze wersje pakietu SDK Firebase w przypadku wszystkich produktów, których używasz w aplikacji.

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

Jeśli używasz Unity IL2CPP i widujesz niesymbolizowane ścieżki stosu, spróbuj wykonać te czynności:

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

2. Upewnij się, że masz skonfigurowane i uruchomione polecenie wiersza poleceń Firebasecrashlytics:symbols:upload, aby wygenerować i przesłać plik symboli.

   To polecenie wiersza poleceń musisz wykonywać za każdym razem, gdy tworzysz kompilację wersji lub dowolną kompilację, dla której chcesz zobaczyć symboliczne ścieżki stosu w konsoli Firebase. Więcej informacji: Otrzymywanie czytelnych raportów o awariach stronę.

Czy Crashlytics można używać w aplikacjach, które korzystają z IL2CPP?

Tak. Crashlytics może wyświetlać symbolizowane zrzuty stosu aplikacji, które należy używać IL2CPP. Ta funkcja jest dostępna w aplikacjach na Androida oraz Platformy Apple. Oto co musisz zrobić:

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

2. Wykonaj czynności wymagane dla Twojej platformy:

   • W przypadku aplikacji platformy Apple: nie musisz wykonywać żadnych specjalnych działań. W przypadku aplikacji na platformy Apple wtyczka Firebase Unity Editor automatycznie skonfiguruje projekt Xcode w celu przesyłania symboli.

   • Aplikacje na Androida: upewnij się, że masz skonfigurowane i uruchomione polecenie wiersza poleceń Firebasecrashlytics:symbols:upload, aby wygenerować i przesłać plik symboli.

     To polecenie interfejsu wiersza poleceń musisz uruchamiać za każdym razem, gdy tworzysz wersję lub dowolną kompilację, dla której chcesz zobaczyć symbolizowane zrzuty stosu w konsoli Firebase. Więcej informacji znajdziesz na stronie Pozyskiwanie czytelnych raportów o awariach.

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

Wartość, w której przypadku nie wystąpiła awaria, to odsetek użytkowników, którzy weszli w interakcję z Twoją aplikacji, ale w danym okresie nie uległa awarii.

Oto wzór na obliczenie odsetka użytkowników, u których nie wystąpiła awaria. Dane wejściowe wartości pochodzą z funkcji Google Analytics.

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

• Gdy wystąpi awaria, Google Analytics wysyła zdarzenie typu 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 weszli w interakcję z reklamą w okresie wybranym z menu w prawym górnym rogu panelu Crashlytics.

Uwaga: jeśli chcesz samodzielnie obliczyć odsetek użytkowników, u których nie wystąpiła awaria, liczbę zdarzeń app_exception zdarzenia dla aplikacji możesz znaleźć w Panel Analytics. Jednak ze względu na niewielkie różnice w sposobie przetwarzania awarii wartość app_exception wyświetlana na panelu Analytics może się czasami różnić od wartości, której używamy do obliczenia odsetka użytkowników bez awarii.

Odsetek użytkowników, u których nie wystąpił błąd, jest agregacją w czasie, a nie średnią.

Załóżmy, że Twoja aplikacja ma 3 użytkowników: A, B i C. Tabela poniżej pokazuje, którzy użytkownicy korzystali z Twojej aplikacji każdego dnia którzy z nich mieli tego dnia awarię:

	Poniedziałek	wtorek	Środa
Użytkownicy, którzy weszli w interakcję z Twoją aplikacją	A, B, C	A, B, C	A, B
Użytkownik, u którego wystąpiła awaria	C	B	A

• W środę odsetek użytkowników, u których nie wystąpiła awaria, wynosił 50% (1 na 2 użytkowników nie miał awarii).
  W środę 2 użytkownicy weszli w interakcję z Twoją aplikacją, 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ło bez awarii).
  Trzej użytkownicy korzystali z Twojej aplikacji w ciągu ostatnich 2 dni, ale tylko jeden z nich (użytkownik C) nie miał żadnych awarii.

• W ciągu ostatnich 3 dni odsetek użytkowników, u których nie wystąpił błąd, wynosi 0% (0 na 3) użytkowników nie wystąpiło bez awarii).
  Trzech użytkowników weszło w interakcję z Twoją aplikacją w ciągu ostatnich trzech dni, ale 0 z nich nie wystąpiło.

Wartości użytkowników, u których nie wystąpił błąd, nie należy porównywać dla różnych okresów. Prawdopodobieństwo awarii u jednego użytkownika rośnie wraz z liczbą używają Twojej aplikacji, więc wartość użytkowników, u których nie wystąpiła awaria, będzie prawdopodobnie mniejsza przez dłuższy czas okresów.

Uwaga: jeśli przefiltrujesz Typ zdarzenia tak, aby obejmowało tylko błędy niekrytyczne, zobaczysz pustą kartę Statystyki dotyczące braku awarii. Odsetek użytkowników, u których nie wystąpiła awaria, wynosi uwzględnianych w przypadku zdarzeń krytycznych.

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

Notatki umożliwiają uczestnikom projektu komentowanie konkretnych problemów związanych z pytaniami i stanem aktualizacje itd.

Gdy członek projektu opublikuje notatkę, zostanie ona oznaczona etykietą z adresem e-mail jego Google koncie. Ten adres e-mail jest widoczny wraz z notatką dla całego projektu użytkowników mających uprawnienia do wyświetlania notatki.

Poniżej znajdziesz informacje o uprawnieniach wymaganych do wyświetlania, zapisu i usuwania uwagi:

• Członkowie projektu z dowolną z tych ról mogą wyświetlać i usuwać istniejące notatki i pisanie nowych notatek na temat problemu.

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

• Członkowie projektu, którzy mają przypisaną dowolną z tych ról, mogą wyświetlać notatki opublikowane w problem, ale nie mogą usunąć ani napisać notatki.

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

Jak obliczana jest liczba użytkowników, u których nie wystąpiła awaria?

Zapoznaj się z informacjami o danych dotyczących braku awarii.

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

Notatki umożliwiają uczestnikom projektu komentowanie konkretnych problemów związanych z pytaniami i stanem aktualizacje itd.

Gdy członek projektu opublikuje notatkę, zostanie ona oznaczona etykietą z adresem e-mail jego Google koncie. Ten adres e-mail jest widoczny wraz z notatką dla całego projektu użytkowników mających uprawnienia do wyświetlania notatki.

Poniżej znajdziesz informacje o uprawnieniach wymaganych do wyświetlania, zapisu i usuwania uwagi:

• Uczestnicy projektu, którzy mają dowolną z tych ról, mogą wyświetlać i usuwać istniejące notatki oraz tworzyć nowe notatki dotyczące problemu.

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

• Członkowie projektu, którzy mają jedną z tych ról, mogą wyświetlać notatki opublikowane w ramach problemu, ale nie mogą ich usuwać ani pisać.

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

Integracje

Aplikacja korzysta też z pakietu SDK Google Mobile Ads, ale nie ma awarii

Jeśli Twój projekt używa Crashlytics i pakietu SDK Google Mobile Ads, jest prawdopodobne, że narzędzia do zgłaszania awarii zakłócają działanie rejestracji modułów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz zgłaszanie awarii w pakiet SDK Mobile Ads, wywołując metodę disableSDKCrashReporting.

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

Gdy połączysz usługę Crashlytics z BigQuery, nowe zbiory danych zostaną znajduje się automatycznie w USA, niezależnie od lokalizacji projekt Firebase.

Problemy z regresją

Co to jest regresja problem?

Problem został rozwiązany, ale po pewnym czasie Crashlytics otrzymał nowe zgłoszenie, że problem powrócił. Crashlytics automatycznie otwiera te problemy, aby umożliwić ich rozwiązanie w sposób odpowiedni dla Twojej aplikacji.

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

1. Po raz pierwszy Crashlytics otrzymuje raport o awarii „A”. Crashlytics otworzy problem związany z tą awarią (problem „A”).
2. Szybko naprawiasz błąd, zamknij problem „A”, a następnie opublikujesz nową wersję do aplikacji.
3. Crashlytics otrzymuje kolejny raport dotyczący problemu „A” po tym, jak został on zamknięty.
   • Jeśli raport pochodzi z wersji aplikacji, którą Crashlytics znał w momencie zamknięcia problemu (co oznacza, że wersja wysłała raport o dowolnym załamaniu), Crashlytics nie uzna problemu za rozwiązany. Problem pozostanie zamknięty.
   • Jeśli raport dotyczy wersji aplikacji, o której Crashlytics nie wiedział w momencie zamykania problemu (czyli w tej wersji nigdy nie wysłano żadnego raportu o awarii), Crashlytics uzna, że problem został rozwiązany i ponownie otworzy zgłoszenie.

Uwaga: przed lutym 2022 r. użytkownik Crashlytics sklasyfikował problem jako regresja, gdy problem powtórzył się ponownie w dowolnej wersji aplikacji – nawet w przypadku aplikacji które były znane w chwili zamknięcia problemu. W rezultacie Funkcja Crashlytics czasami nieprawidłowo identyfikuje regresje. Korzystamy teraz z konwencji opisanej powyżej.

Gdy problem pogorszy się, wysyłamy alert o wykryciu regresji i dodajemy sygnał regresji do problemu, informujący, że w wyniku Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, zamiast go zamykać, „wycisz” go.

Dlaczego w starszych wersjach aplikacji widzę problemy?

Jeśli raport pochodzi ze starej wersji aplikacji, która nigdy nie wysłała żadnych raportów o wypadkach, Crashlytics uzna, że problem uległ regresji, i ponownie otworzy zgłoszenie.

Może się tak zdarzyć, jeśli: naprawiono błąd i opublikowała nową wersję Twojej aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji bez poprawek. Jeśli przez przypadek jedna ze starszych wersji nigdy nie została wysłana żadnych raportów o awariach w momencie zamknięcia problemu, a użytkownicy zaczną napotkania błędu, raporty o awariach wywołałyby ponowne wystąpienie problemu.

Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, zamiast zamykać problem, „wycisz go”.

Uwaga: przed lutym 2022 roku Crashlytics sklasyfikowało problem jako regresję, gdy wystąpił on ponownie w dowolnej wersji aplikacji, nawet w wersjach, które były nam znane w momencie zamknięcia problemu. W efekcie Crashlyticsczasami nieprawidłowo rozpoznawał regresje. Teraz stosujemy konwencję opisane powyżej.

Jeśli zauważysz wiele błędnie zidentyfikowanych regresji z przed lutym 2022 r. możesz je ponownie zamknąć, aby uniknąć ponownego otwarcia.

Zgłaszanie nieprzechwycionych wyjątków jako błędów krytycznych

Crashlytics może zgłaszać niewyłapane wyjątki jako błędy krytyczne (zaczynające się od wersja 10.4.0 pakietu SDK Unity). Poniżej znajdziesz odpowiedzi na najczęstsze pytania dotyczące uzasadnienia i zalecanych metod korzystania z tej funkcji.

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

Zgłaszając niewyłapane wyjątki jako błędy krytyczne, uzyskasz bardziej realistyczne wskazania. jakie wyjątki mogą spowodować, że gra będzie niedostępna – nawet jeśli aplikacja będzie nadal działać.

Pamiętaj, że jeśli zaczniesz raportować awarie, odsetek użytkowników, u których nie wystąpiła awaria, prawdopodobnie się zmniejszy, ale wskaźnik CFU będzie lepiej odzwierciedlać wrażenia użytkowników z korzystania z aplikacji.

Ważne: zgłaszanie niewykrytych wyjątków (błędów krytycznych) nie wpływa na: Android Vitals. Błędy krytyczne zgłaszane w Crashlytics są widoczne tylko dla Ciebie, aby umożliwić Ci wykrywanie i rozwiązywanie problemów w aplikacjach i grach.

Jakie wyjątki będą zgłaszane jako krytyczne?

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

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

• Twoja aplikacja (lub zawarta w niej biblioteka) zgłasza wyjątek, który nie jest przechwycony. Wyjątek, który został utworzony, ale nie został wygenerowany, nie jest uważany za nieprzechwycony.

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

Gdy zaczniesz otrzymywać raporty o niewykrytych wyjątkach jako krytycznych, oto te kilka opcji postępowania z tymi niewykrytymi wyjątkami:

• Zastanów się, jak możesz zacząć wyłapywać te nietypowe wyjątki i odpowiednio sobie z nimi poradzić.
• Rozważ różne opcje logowania wyjątków w konsoli debugowania Unity i w zasadzie Crashlytics.

Łapanie i obsługa zgłaszanych wyjątków

Wyjątki są tworzone i wyrzucane, aby odzwierciedlić nieoczekiwane lub wyjątkowe stany. Rozwiązanie problemów, które wywołuje wyjątek, wymaga przywrócenia programu do znanego stanu (procesu znanego jako obsługa wyjątków).

Sprawdzoną metodą jest przechwytywanie i obsługa wszystkich przewidywanych wyjątków, chyba że program nie może powrócić do znanego stanu.

Aby określić, jakie rodzaje wyjątków mają być przechwytywane i obsługiwane przez dany kod, zapakuj kod, który może wygenerować wyjątek, w blok try-catch. Upewnij się, że warunki w instrukcjach catch są tak wąskie jak aby odpowiednio zająć się poszczególnymi wyjątkami.

Zapisywanie 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.

Podczas korzystania z funkcji Crashlytics możesz wybrać jedną z tych 2 najczęstszych i najlepiej rekomendowanych opcji:

• Opcja 1. Wyświetlanie w konsoli Unity, ale nie wysyłanie raportów do Crashlytics podczas tworzenia aplikacji lub rozwiązywania problemów

  • Drukuj w konsoli Unity za pomocą programu Debug.Log(exception), Debug.LogWarning(exception) i Debug.LogError(exception), które wydrukuj treść wyjątku do konsoli Unity i nie jeszcze raz zgłosić wyjątek.

• Opcja 2. Prześlij dane do Crashlytics, aby korzystać z konsolidowanych raportów na panelu Crashlytics w tych sytuacjach:

  • Jeśli warto zapisać wyjątek, by debugować możliwy kolejny Crashlytics, a potem użyj Crashlytics.Log(exception.ToString()).
  • Czy wyjątek należy zgłosić do Crashlytics pomimo przechwycenia i przetwarzania, użyj narzędzia Crashlytics.LogException(exception). , aby zapisać je jako zdarzenie niekrytyczne.

Jeśli jednak chcesz ręcznie zgłosić zdarzenie krytyczne do Unity Cloud Diagnostyka, możesz użyć narzędzia Debug.LogException. Ta opcja drukuje wyjątek do konsoli Unity, jak w przypadku opcji 1, ale zgłasza też wyjątek. (niezależnie od tego, czy został rzucony lub złapany). Wyrzuca błąd w nielokalnym miejscu. Oznacza to, że nawet blokowanie Debug.LogException(exception) za pomocą bloków try-catch powoduje wyjątek niewykryty.

Dlatego zadzwoń do Debug.LogException, jeśli chcesz wykonać wszystkie te czynności:

• Aby wydrukować wyjątek w konsoli Unity.
• Aby przesłać wyjątek do usługi Crashlytics jako zdarzenie krytyczne.
• Aby zgłosić wyjątek, zadbaj o to, aby był on traktowane jako nieobsłużony wyjątek oraz i przekazywać je do diagnostyki chmury Unity.

Jeśli chcesz wydrukować wyjątek w konsoli Unity i przesłać 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
    //
}