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.

Ogólne informacje o rozwiązywaniu problemów i najczęstsze pytania

wyświetlanie w tabeli Problemy różnych formatów (a czasami „wariantów”) niektórych problemów;

W konsoli Firebase możesz zauważyć 2 różne formaty problemów wymienionych w tabeli Problemy. W niektórych problemach możesz też zauważyć funkcję o nazwie „warianty”. Wyjaśniamy dlaczego.

Na początku 2023 r. wdrożyliśmy ulepszony mechanizm analizy grupowania zdarzeń oraz zaktualizowany wygląd i kilka zaawansowanych funkcji związanych z nowymi problemami (takimi jak warianty). Więcej informacji znajdziesz w naszym niedawnym poście na blogu. Poniżej znajdziesz najważniejsze informacje.

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

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

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 uwzględnić tę możliwą różnicę w problemie, tworzymy warianty w problemach. Każdy wariant to podgrupa zdarzeń w problemie, która ma ten sam punkt awarii i podobny ślad 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:

• Zaktualizowane 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 skomplikowanych problemów z różnymi przyczynami
  Używaj wariantów do debugowania najczęstszych ścieżek wywołań w ramach problemu.

• Bardziej istotne alerty i sygnały
  Nowy problem oznacza 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 znajdziemy pasującego zdarzenia, automatycznie zastosujemy do niego nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z ulepszonym projektem metadanych.

Jest to pierwsza duża zmiana, jaką wprowadzamy w grupowaniu wydarzeń. Jeśli chcesz podzielić się opinią lub napotkasz problem, prześlij raport.

Nie widzisz danych o bezawaryjnej pracy ani alertów dotyczących 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 dzienników ścieżek, sprawdź konfigurację aplikacji pod kątem Google Analytics. Upewnij się, że spełniasz te wymagania:

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

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

• Do aplikacji dodano pakiet SDK Firebase dla Google Analytics do aplikacji. Ten pakiet SDK musi zostać dodany oprócz pakietu SDK Crashlytics.

• Używasz najnowszych wersji pakietu SDK Firebase wszystkich usług używanych w aplikacji.

W panelu Crashlytics widać niesymboliczne zrzuty stosu aplikacji na Androida

Jeśli używasz Unity IL2CPP i widujesz niesymbolizowane ścieżki stosu, wykonaj te czynności:

1. Upewnij się, że używasz 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 uruchomić 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 znajdziesz na stronie Pozyskiwanie czytelnych raportów o awariach.

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

Tak. Crashlytics może wyświetlać symboliczne ścieżki stosu w przypadku aplikacji korzystających z IL2CPP. Ta funkcja jest dostępna w przypadku aplikacji opublikowanych na platformach Android lub Apple. Oto co musisz zrobić:

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

2. Wykonaj odpowiednie czynności na swojej platformie:

   • W przypadku aplikacji na platformę Apple: nie musisz nic robić. W przypadku aplikacji na platformy Apple wtyczka Firebase Unity Editor automatycznie skonfiguruje projekt Xcode do 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 wiersza poleceń musisz uruchomić 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 znajdziesz na stronie Uzyskiwanie czytelnych raportów o awariach.

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

Wartość bez awarii to odsetek użytkowników, którzy weszli w interakcję z Twoją aplikacją, ale w wybranym okresie nie uległy awarii.

Oto wzór na obliczanie odsetka użytkowników, u których nie wystąpiła awaria. Wartości wejściowe tego elementu są dostarczane przez 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 to łączna liczba użytkowników, którzy korzystali z Twojej aplikacji w okresie wybranym w 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, w panelu Analytics znajdziesz liczbę zdarzeń app_exception dotyczących aplikacji. 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 obliczania odsetka użytkowników bez awarii.

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

Załóżmy na przykład, że Twoja aplikacja ma 3 użytkowników. Będziemy je nazwać Użytkownik A, Użytkownik B i Użytkownik C. W tabeli poniżej podano, którzy użytkownicy danego dnia korzystali z Twojej aplikacji i 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 u jednego z nich (Użytkownik B) nie wystąpiły żadne awarie.

• W ciągu ostatnich 2 dni odsetek użytkowników, u których nie wystąpiła żadna awaria, wynosił 33,3% (u 1 na 3 użytkowników nie wystąpiła awaria).
  W ciągu ostatnich 2 dni 3 użytkownicy wchodzili w interakcję z Twoją aplikacją, 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 miało awarii).
  W ciągu ostatnich 3 dni 3 użytkowników korzystało z Twojej aplikacji, ale żaden z nich nie miał żadnych awarii.

Wartości współczynnika użytkowników, u których nie wystąpił błąd, nie należy porównywać w różnych okresach. Im częściej użytkownik korzysta z aplikacji, tym większe jest prawdopodobieństwo, że wystąpi u niego awaria, dlatego wartość użytkowników, u których nie wystąpiła awaria, jest prawdopodobnie mniejsza w dłuższych okresach.

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ł błąd, jest obliczany tylko w przypadku krytycznych zdarzeń.

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

Uwagi umożliwiają uczestnikom projektu komentowanie konkretnych problemów, zadawanie pytań, informowanie o aktualizacjach stanu itp.

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

Poniżej opisujemy uprawnienia wymagane do wyświetlania, zapisywania i usuwania notatek:

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

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

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

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

Uwagi umożliwiają uczestnikom projektu komentowanie konkretnych problemów, zadawanie pytań, informowanie o aktualizacjach stanu itp.

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

Poniżej opisujemy uprawnienia wymagane do wyświetlania, zapisywania i usuwania notatek:

• 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ą przypisaną dowolną z tych ról, mogą wyświetlać notatki opublikowane na temat problemu, ale nie mogą 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 interfejsu Crashlytics razem z pakietem SDK Google Mobile Ads, prawdopodobnie narzędzia do zgłaszania awarii zakłócają rejestrowanie modułów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie awarii w pakiecie SDK Mobile Ads, wywołując funkcję disableSDKCrashReporting.

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

Po połączeniu usługi Crashlytics z BigQuery nowe zbiory danych, które utworzysz, zostaną automatycznie umieszczone w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.

Problemy z regresją

Co to jest problem z powrotem do stanu poprzedniego?

Występuje ponowna regresja, ponieważ wcześniej został przez Ciebie zamknięty wcześniej, ale usługa Crashlytics otrzymuje nowy raport o ponownym wystąpieniu problemu. 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 otrzymał raport o awarii „A”. Crashlytics otwiera odpowiedni problem dotyczący tego błędu (problem „A”).
2. Szybko naprawiasz ten błąd, zamykasz problem „A”, a potem publikujesz nową wersję 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 pochodzi z wersji aplikacji, o której użytkownik Crashlytics nie wiedział o czymś w momencie zamknięcia problemu (czyli że ta wersja nigdy nie wysyłała żadnego raportu o awarii), Crashlytics uznaje, że problem wrócił do poprzedniego, i otworzy go ponownie.

Uwaga: przed lutym 2022 roku Crashlyticskategorizował 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. Z tego powodu funkcja Crashlytics czasami nieprawidłowo identyfikowała regresje. Teraz stosujemy opisaną powyżej konwencję.

Gdy problem wystąpi ponownie, wyślemy alert o wykryciu regresji i dodamy do problemu sygnał regresji, aby poinformować Cię, że usługa Crashlytics ponownie otworzyła 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ę to zdarzyć, gdy naprawisz błąd i opublikujesz nową wersję aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji bez poprawki. Jeśli po zamknięciu problemu okazało się, że jedna z tych starszych wersji nigdy nie wysłała żadnych raportów o awariach, a użytkownicy zaczęli napotykać ten błąd, raporty o awariach spowodują problemy z powrotem.

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 identyfikował regresje. Obecnie stosujemy konwencję opisaną powyżej.

Jeśli zaobserwujesz wiele błędnie zidentyfikowanych regresji sprzed lutego 2022 r., możesz je ponownie zamknąć, aby zapobiec ich ponownemu otwarciu.

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

Crashlytics może zgłaszać nieprzechwycone wyjątki jako krytyczne (od wersji 10.4.0 pakietu SDK Unity). Poniżej znajdziesz odpowiedzi na najczęstsze pytania, które pomogą Ci zrozumieć uzasadnienie i zalety korzystania z tej funkcji.

Dlaczego aplikacja powinna zgłaszać nieprzechwycone wyjątki jako krytyczne?

Dzięki zgłaszaniu nieprzechwyconych wyjątków jako krytycznych możesz uzyskać bardziej realistyczne wskazanie, które wyjątki mogą spowodować, że gra nie będzie grywalna – nawet jeśli aplikacja nadal będzie działać.

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

Ważne: zgłaszanie niewykrytych wyjątków jako błędów krytycznych nie ma wpływu na wskaźniki Androida. Błędy krytyczne zgłoszone w usłudze Crashlytics są widoczne tylko dla Ciebie. Dzięki temu możesz wykrywać i rozwiązywać problemy z aplikacjami i grami.

Które wyjątki będą oznaczane jako błędy?

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

• Podczas inicjalizacji w aplikacji właściwość ReportUncaughtExceptionsAsFatal 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 nieprzechwycionych wyjątków jako krytycznych mam teraz wiele nowych krytycznych błędów. Jak prawidłowo obsługiwać te wyjątki?

Gdy zaczniesz otrzymywać raporty o niewykrytych wyjątkach jako krytycznych, możesz skorzystać z tych sposobów postępowania z takimi 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

Wyjątki są tworzone i wyrzucane, aby odzwierciedlić nieoczekiwane lub wyjątkowe stany. Rozwiązanie problemów, które są spowodowane wyrzuceniem wyjątku, wymaga przywrócenia programu do znanego stanu (proces znany 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ć wychwytywane i obsługiwane przez dany kod, zapakuj kod, który może wygenerować wyjątek, w blok try-catch. Aby odpowiednio obsługiwać konkretne wyjątki, zadbaj o to, aby warunki w oświadczeniach catch były jak najbardziej wąskie.

Zapisywanie wyjątków w Unity lub Crashlytics

Istnieje wiele sposobów rejestrowania wyjątków w Unity i Crashlytics, które mogą pomóc w rozwiązaniu problemu.

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

  • Wydrukuj do konsoli Unity za pomocą funkcji Debug.Log(exception), Debug.LogWarning(exception) i Debug.LogError(exception), które wydrukują zawartość wyjątku do konsoli Unity i nie wyrzucają wyjątku.

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

  • Jeśli warto zalogować się na wyjątek, aby debugować potencjalne kolejne zdarzenie Crashlytics, użyj metody Crashlytics.Log(exception.ToString()).
  • Jeśli wyjątek powinien być nadal zgłaszany do Crashlytics pomimo jego przechwycenia i obsłużenia, użyj metody Crashlytics.LogException(exception), aby zarejestrować to jako zdarzenie niekrytyczne.

Jeśli jednak chcesz ręcznie zgłosić do Diagnostics w usłudze Unity Cloud zdarzenie krytyczne, możesz użyć Debug.LogException. Ta opcja powoduje wydrukowanie wyjątku w konsoli Unity, na przykład opcji 1, ale zgłoszenie wyjątku (niezależnie od tego, czy został on zgłoszony czy przechwycony). 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 wyjątek został wygenerowany, należy go traktować jako niechwytyczony i zgłaszać do narzędzia Unity Cloud Diagnostics.

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