Rozwiązywanie problemów z Crashlytics i najczęstsze pytania
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:
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:
Upewnij się, że używasz wersji Crashlytics Unity SDK w wersji 8.6.1 lub nowszej.
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ć:
Upewnij się, że używasz pakietu SDK Unity w wersji 8.6.0 lub nowszej.
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.
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.
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.
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.
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.
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ę:
Po raz pierwszy Crashlytics otrzymuje raport o awarii „A”. Crashlytics otworzy problem związany z tą awarią (problem „A”).
Szybko naprawiasz błąd, zamknij problem „A”, a następnie opublikujesz nową wersję
do aplikacji.
Crashlytics otrzymuje kolejny raport dotyczący problemu „A” po tym, jak został on zamknięty.
Jeśli raport pochodzi z wersji aplikacji, którą Crashlyticsznał 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 Crashlyticsnie 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.
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”.
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.
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:
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:
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
//
}