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

iOS+ Android Efekt kołysania Unity

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:

• Masz włącz Google Analytics, w projekcie Firebase.

• masz włączone udostępnianie danych na potrzeby Google Analytics, Więcej informacji o to ustawienie w Zarządzanie ustawieniami udostępniania danych Analytics

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

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

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:

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

2. 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ć:

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

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

.

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. Z powodu niewielkich różnic w sposobie awarii wartości app_exception wyświetlanej w panelu Analytics może się czasami różnić od wartości, którą używamy przy obliczaniu zakresu bezpieczeństwa odsetek użytkowników.

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.

Uwaga: jeśli przefiltrujesz zdarzenie Zdarzenie, zobaczysz pustą kartę Statystyki bez awarii. typu tylko na problemy niekrytyczne. 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 Crashytics

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

  • 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 artykułem Dane o 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:

• 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 Crashytics

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

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

Integracje

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.

1. Po raz pierwszy Crashlytics otrzymuje raport o awariach „A”. Crashlytics wyświetli odpowiedni problem dotyczący tej awarii (problem „A”).
2. Szybko naprawiasz błąd, zamknij problem „A”, a następnie opublikujesz nową wersję do aplikacji.
3. 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.

.

Uwaga: przed lutym 2022 r. zespół Crashlytics uznał problem za 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 Crashlytics czasami błędnie wykrywa regresje. Korzystamy teraz z konwencji opisanej powyżej.

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

Uwaga: przed lutym 2022 r. zespół Crashlytics uznał problem za regresja, gdy problem wystąpił ponownie w dowolnej wersji aplikacji – nawet w jej wersjach. które wiedzieliśmy, kiedy zamknęliście ten problem. Dzięki temu powstała Crashlytics często błędnie wykrywając 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 nie zostały otwarte.

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.

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, więc możesz wykrywać i rozwiązywać problemy z aplikacjami i grami.

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:

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

• 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:

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

Chwyć i obsługuj zgłoszone wyjątki

Są tworzone i zgłaszane wyjątki, aby odzwierciedlić nieoczekiwane lub wyjątkowe przypadki . Rozwiązywanie problemów zgłaszanych przez zgłoszony wyjątek wymaga zwrócenia do znanego stanu (proces nazywany wyjątkiem obsługi klienta).

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
    //
}