Rozwiązywanie problemów z Crashlytics i najczęstsze pytania
Na tej stronie znajdziesz pomoc dotyczącą rozwiązywania problemów i odpowiedzi na najczęstsze pytania
pytań dotyczących korzystania z Crashlytics. Jeśli
nie możesz znaleźć tego, czego szukasz, lub potrzebujesz dodatkowej pomocy, skontaktuj się z
Obsługa 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 wymienionych w tabeli Problemy.
w konsoli Firebase. Możesz też zauważyć funkcję
„warianty” w niektórych kwestiach. Wyjaśniamy 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 (takie jak awarie, niekrytyczne
i błędy ANR) oraz tworzy grupy zdarzeń nazywane problemami – wszystkie
mają wspólne
punkty 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.
Jednak w ramach tej grupy zdarzeń zrzuty stosu prowadzące do błędu
może być inna. 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. W przypadku wariantów
możesz debugować typowe zrzuty stosu w obrębie problemu i sprawdzić, czy
mają różne przyczyny.
Oto zalety tych ulepszeń:
Ulepszone metadane wyświetlane w wierszu problemu Teraz łatwiej jest zrozumieć i eliminować problemy z aplikacją.
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 oznacza nowy błąd.
Bardziej zaawansowane wyszukiwanie Każdy numer zawiera więcej metadanych, które można wyszukać,
np. typ wyjątku i nazwę pakietu.
Oto jak wprowadzamy te ulepszenia:
Gdy otrzymamy nowe zdarzenia z aplikacji, sprawdzimy, czy pasują do istniejących
Google Cloud.
Jeśli nie, automatycznie zastosujemy
lepszy sposób grupowania zdarzeń.
do zdarzenia i sformułować nowy problem ze zmienionymi metadanymi.
projektu.
To pierwsza duża aktualizacja, którą wprowadzamy w grupowaniu wydarzeń. Jeśli
Jeśli masz uwagi lub napotkasz jakieś problemy, skontaktuj się z nami do
i wypełnianie zgłoszenia.
Nie widać
dane o braku awarii lub alerty o szybkości
Jeśli nie widzisz danych, w których przypadku nie wystąpiła awaria (np. liczby użytkowników i sesji, w których przypadku nie wystąpiła awaria)
i/lub alertów o rosnącej liczbie problemów, upewnij się, że używasz funkcji
SDK Crashlytics w wersji 11.7.0 lub nowszej.
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:
Widzenie bez symboli
zrzuty stosu aplikacji na Androida w panelu Crashlytics
Jeśli używasz Unity IL2CPP
i widzisz niesymboliczne zrzuty stosu, spróbuj wykonać następujące czynności:
Upewnij się, że używasz wersji Crashlytics Unity lub nowszej
SDK.
Sprawdź, czy masz skonfigurowany i uruchomiony interfejs wiersza poleceń Firebase
Polecenie crashlytics:symbols:upload, aby wygenerować i przesłać symbol
.
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:
Otrzymywanie czytelnych raportów o awariach
stronę.
Czy można używać Crashlytics
z aplikacjami, 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 wersji Crashlytics Unity lub nowszej
SDK.
Wykonaj czynności wymagane dla Twojej platformy:
W przypadku aplikacji platformy Apple: nie musisz wykonywać żadnych specjalnych działań. Do Apple
aplikacji na platformie, wtyczka Firebase Unity Editor automatycznie konfiguruje
w projekcie Xcode, aby przesłać symbole.
W przypadku aplikacji na Androida: upewnij się, że aplikacja jest skonfigurowana i uruchomiona
Polecenie wiersza poleceń Firebase crashlytics:symbols:upload do wygenerowania
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:
Otrzymywanie czytelnych raportów o awariach
stronę.
Jak obliczana jest liczba 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
są dostarczane przez Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
Gdy zdarzy się wypadek, Google Analytics wysyła zdarzenie app_exception.
a CRASHED_USERS to liczba powiązanych użytkowników
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 na przykład, że z aplikacji korzysta 3 użytkowników. nadajemy nazwy Użytkownikom A, Użytkownikom B.
oraz Użytkownik 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, który uległ awarii
C
B
A
We środę odsetek użytkowników, u których nie wystąpiła awaria, wynosi 50% (1 na 2 użytkowników
bez awarii). Dwóch użytkowników weszło w interakcję z Twoją aplikacją w środę, ale tylko jeden z nich
(Użytkownik B) nie wystąpił żadna awaria.
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). Trzech użytkowników weszło w interakcję z Twoją aplikacją w ciągu ostatnich dwóch dni, ale tylko
w przypadku jednej z nich (użytkownik C) nie wystąpiła żadna awaria.
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 danego użytkownika rośnie z każdym jej
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 może 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:
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 może usunąć ani napisać notatki.
Aplikacja używa też
Pakiet SDK do reklam mobilnych Google, ale nie występują awarie
Jeśli Twój projekt używa Crashlytics i pakietu SDK do reklam mobilnych Google,
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
pakietu SDK do reklam mobilnych, wywołując funkcję disableSDKCrashReporting.
Gdzie znajduje się mój zbiór danych BigQuery?
Po połączeniu Crashlytics z BigQuery nowe zbiory danych
znajduje się automatycznie w USA, niezależnie od lokalizacji
projekt Firebase.
Problemy, które pojawiły się znowu
Co to jest regresja
problem?
Występuje regresja, gdy wcześniej został przez Ciebie zamknięty problem, ale
Crashlytics otrzymuje nowy raport o powtórnym wystąpieniu problemu.
Crashlytics automatycznie ponownie otwiera te problemy, aby umożliwić Ci
odpowiednio do potrzeb aplikacji.
Oto przykładowy scenariusz, który wyjaśnia, jak Crashlytics kategoryzuje
jako regresji.
Po raz pierwszy Crashlytics otrzymuje raport o awariach
„A”. Crashlytics wyświetli odpowiedni problem dotyczący tej awarii (problem „A”).
Szybko naprawiasz błąd, zamknij problem „A”, a następnie opublikujesz nową wersję
do aplikacji.
Crashlytics otrzymuje kolejny raport o problemie A. po zamknięciu
Google Cloud.
Jeśli raport pochodzi z wersji aplikacji, którą znała Crashlytics
kiedy zamknięto problem (co oznacza, że wersja spowodowała awarię).
w ogóle nie zgłosi żadnej awarii), Crashlytics nie weźmie pod uwagę
a wraz z nim ponownie. Problem pozostanie zamknięty.
Jeśli raport pochodzi z wersji aplikacji, w przypadku której Crashlytics nie, kiedy zamknięto problem (co oznacza, że wersja
nigdy nie wysłał żadnego raportu o awarii), a następnie
Crashlytics uzna, że problem ustąpił, i ponownie otworzy
Google Cloud.
.
Gdy problem ustąpi, wysyłamy alert o wykryciu regresji i dodajemy
sygnał regresji, aby poinformować Cię, że Crashlytics
ponownie otworzył problem. Jeśli nie chcesz, aby dany problem został ponownie otwarty ze względu na nasze
algorytm regresji, „mute”; problemu, zamiast ją zamykać.
Dlaczego u mnie się pogorszył
problemów ze starszymi wersjami aplikacji?
Jeśli raport pochodzi ze starej wersji aplikacji, która nigdy nie wysyłała żadnych raportów o awariach na
po zamknięciu problemu Crashlytics bierze pod uwagę
problem został rozwiązany i zostanie ponownie otwarty.
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 był ponownie otwierany przez nasz algorytm regresji, kliknij „Wycisz”.
problemu, zamiast ją zamykać.
Zgłaszanie niewykrytych wyjątków jako 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
jak korzystać 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 zgłaszać błędy krytyczne, odsetek użytkowników, u których nie wystąpił błąd,
najprawdopodobniej się zmniejszy, ale wskaźnik CFU będzie bardziej reprezentatywny
użytkowników korzystanie z aplikacji.
Jakie wyjątki
zgłaszanych jako błędy śmiertelne?
Aby usługa Crashlytics mogła zgłosić niewyłapany wyjątek jako krytyczny, oba atrybuty
muszą być spełnione następujące dwa warunki:
Twoja aplikacja (lub dołączona biblioteka) zgłasza wyjątek, który nie jest uwzględniany. An
utworzony, ale nie zgłoszony, nie jest uważany za nieobsłużony.
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:
Sprawdzoną metodą jest wyłapywanie i obsługa wszystkich przewidzianych wyjątków, chyba że
programu nie można przywrócić do znanego stanu.
Aby kontrolować, jakie wyjątki są wychwytywane i obsługiwane przez jaki kod:
zapakuj kod, który mógłby wygenerować wyjątek w bloku try-catch.
Upewnij się, że warunki w instrukcjach catch są tak wąskie jak
aby odpowiednio zająć się poszczególnymi wyjątkami.
Rejestrowanie wyjątków w Unity lub Crashlytics
Istnieje kilka sposobów rejestrowania wyjątków w Unity lub Crashlytics.
debugować problem.
Oto 2 najpopularniejsze i zalecane metody korzystania z Crashlytics
opcje:
Opcja 1. Drukuj w konsoli Unity, ale nie zgłaszaj do Crashlytics
podczas programowania 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 do Crashlytics, aby skonsolidować raporty w
Panel Crashlytics w tych sytuacjach:
Jeśli warto zapisać wyjątek, by debugować możliwy kolejny
zdarzenie Crashlytics, a potem użyj parametru 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). Zgłasza błąd
w sposób nielokalny. Oznacza to, że nawet otaczające go Debug.LogException(exception)
z blokadami try-catch nadal skutkuje nieobsłużonym wyjątkiem.
Dlatego wywołaj funkcję Debug.LogException tylko wtedy, gdy chcesz wykonać wszystkie z tych
następujące:
Aby wydrukować wyjątek w konsoli Unity.
Aby przesłać wyjątek do 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.
Pamiętaj, że jeśli chcesz wydrukować wyjątek dla konsoli Unity oraz
przesłać do Crashlytics jako zdarzenie niekrytyczne, wykonaj zamiast tego 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
//
}