Na tej stronie znajdziesz pomoc w rozwiązywaniu problemów oraz odpowiedzi na często zadawane pytania dotyczące korzystania z Crashlytics. Jeśli nie możesz znaleźć tego, czego szukasz lub potrzebujesz dodatkowej pomocy, skontaktuj się z pomocą techniczną Firebase .
Ogólne rozwiązywanie problemów/FAQ
Jeśli nie widzisz użytkowników bez awarii, dzienników nawigacji i/lub alertów dotyczących prędkości, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że w swoim projekcie Firebase włączyłeś Google Analytics .
Upewnij się, że Udostępnianie danych dla Google Analytics jest włączone na stronie Integracje > Google Analytics w konsoli Firebase. Pamiętaj, że ustawienia udostępniania danych są wyświetlane w konsoli Firebase, ale zarządza się nimi w konsoli Google Analytics.
Oprócz pakietu SDK Firebase Crashlytics upewnij się, że do swojej aplikacji dodałeś pakiet SDK Firebase dla Google Analytics ( iOS+ | Android ).
Upewnij się, że używasz najnowszych wersji wszystkich zestawów SDK Firebase ( iOS+ | Android ).
W szczególności sprawdź, czy używasz co najmniej następujących wersji pakietu SDK Firebase dla Google Analytics:iOS+ — v6.3.1+ (v8.9.0+ dla macOS i tvOS) | Android — v17.2.3+ (BoM v24.7.1+) .
Możesz zauważyć dwa różne formaty problemów wymienionych w tabeli Problemy w konsoli Firebase. W niektórych problemach możesz także zauważyć funkcję zwaną „wariantami”. Dlatego!
Na początku 2023 r. wprowadziliśmy ulepszony silnik analityczny do grupowania wydarzeń, a także zaktualizowany projekt i kilka zaawansowanych funkcji dla nowych problemów (takich jak warianty!). Wszystkie szczegóły znajdziesz w naszym najnowszym poście na blogu , ale najważniejsze informacje znajdziesz poniżej.
Crashlytics analizuje wszystkie zdarzenia z Twojej aplikacji (takie jak awarie, zdarzenia inne niż krytyczne i błędy ANR) i tworzy grupy zdarzeń zwane problemami — wszystkie zdarzenia w problemie mają wspólny punkt awarii.
Aby pogrupować zdarzenia w te problemy, ulepszony silnik analizy analizuje obecnie wiele aspektów zdarzenia, w tym ramki w śladzie stosu, komunikat wyjątku, kod błędu i inne cechy platformy lub typu błędu.
Jednak w obrębie tej grupy zdarzeń ślady stosu prowadzące do awarii mogą być inne. Inny ślad stosu może oznaczać inną przyczynę podstawową. Aby przedstawić tę możliwą różnicę w obrębie problemu, tworzymy teraz warianty w obrębie problemów — każdy wariant jest podgrupą zdarzeń w problemie, które mają ten sam punkt awarii i podobny ślad stosu. Dzięki wariantom możesz debugować najczęstsze ślady stosu w obrębie problemu i określić, czy do niepowodzenia prowadzą różne przyczyny główne.
Oto, czego doświadczysz dzięki tym ulepszeniom:
Zmienione metadane wyświetlane w wierszu problemu
Teraz łatwiej jest zrozumieć i ocenić problemy w aplikacji.Mniej duplikatów problemów
Zmiana numeru linii nie powoduje nowego problemu.Łatwiejsze debugowanie złożonych problemów z różnymi przyczynami źródłowymi
Użyj wariantów, aby debugować najczęstsze ślady stosu w ramach problemu.Bardziej znaczące alerty i sygnały
Nowy problem w rzeczywistości oznacza nowy błąd.Mocniejsze wyszukiwanie
Każde wydanie zawiera więcej metadanych, które można przeszukiwać, takich jak typ wyjątku i nazwa pakietu.
Oto jak wdrażane są te ulepszenia:
Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy pasują one do istniejącego problemu.
Jeśli nie ma dopasowania, automatycznie zastosujemy do zdarzenia nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z ulepszonym projektem metadanych.
To pierwsza duża aktualizacja, którą wprowadzamy w naszym grupowaniu wydarzeń. Jeśli masz uwagi lub napotkasz jakiekolwiek problemy, daj nam znać, przesyłając raport.
Wartość bez awarii reprezentuje odsetek użytkowników, którzy weszli w interakcję z Twoją aplikacją, ale nie doświadczyli awarii w określonym przedziale czasu.
Oto wzór na obliczenie procentu użytkowników bez awarii. Jego wartości wejściowe są dostarczane przez Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
W przypadku awarii Google Analytics wysyła typ zdarzenia
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 Twoją aplikacją w okresie wybranym z menu rozwijanego w prawym górnym rogu panelu Crashlytics.
Odsetek użytkowników bez awarii jest sumą w czasie , a nie średnią.
Załóżmy na przykład, że Twoja aplikacja ma trzech użytkowników; nazwiemy ich Użytkownikiem A, Użytkownikiem B i Użytkownikiem C. Poniższa tabela pokazuje, którzy użytkownicy korzystali z Twojej aplikacji każdego dnia i który z nich miał 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 miał awarię | C | B | A |
W środę odsetek użytkowników bez awarii wynosi 50% (1 na 2 użytkowników nie miał żadnych awarii).
Dwóch użytkowników skorzystało z Twojej aplikacji w środę, ale tylko u jednego z nich (Użytkownik B) nie wystąpiła żadna awaria.W ciągu ostatnich 2 dni odsetek użytkowników bez awarii wynosił 33,3% (1 na 3 użytkowników nie miał żadnych awarii).
Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich dwóch dni, ale tylko u jednego z nich (Użytkownik C) nie wystąpiła żadna awaria.W ciągu ostatnich 3 dni odsetek użytkowników bez awarii wynosił 0% (0 z 3 użytkowników nie miało żadnych awarii).
Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich trzech dni, ale u żadnego z nich nie wystąpiła żadna awaria.
Wartości użytkowników bez awarii nie należy porównywać w różnych okresach czasu. Prawdopodobieństwo, że pojedynczy użytkownik doświadczy awarii, rośnie im częściej korzysta z aplikacji, więc wartość użytkowników bez awarii będzie prawdopodobnie mniejsza w dłuższych okresach.
Notatki umożliwiają członkom projektu komentowanie konkretnych problemów za pomocą pytań, aktualizacji statusu itp.
Kiedy członek projektu publikuje notatkę, jest ona oznaczona adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich członków projektu mających dostęp do przeglądania notatki.
Poniżej opisano dostęp wymagany do przeglądania, pisania i usuwania notatek:
Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.
Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać notatki opublikowane w sprawie problemu, ale nie mogą usuwać ani pisać notatek.
Integracje
Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, prawdopodobne jest, że osoby zgłaszające awarie zakłócają rejestrację programów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie o awariach w pakiecie SDK do reklam mobilnych, wywołując disableSDKCrashReporting .
Po połączeniu Crashlytics z BigQuery nowe utworzone przez Ciebie zbiory danych będą automatycznie lokalizowane w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Wsparcie platformy
Cofnięte problemy
Problem uległ regresji, gdy został już wcześniej zamknięty, ale Crashlytics otrzymuje nowy raport o ponownym wystąpieniu problemu. Crashlytics automatycznie ponownie otwiera te problemy, które uległy regresji, dzięki czemu możesz je rozwiązać odpowiednio do swojej aplikacji.
Oto przykładowy scenariusz wyjaśniający, jak Crashlytics kategoryzuje problem jako regresję:
- Po raz pierwszy w historii Crashlytics otrzymuje raport o awarii dotyczącej awarii „A”. Crashlytics otwiera odpowiedni problem dla tej awarii (problem „A”).
- Szybko naprawisz ten błąd, zamkniesz wydanie „A”, a następnie wypuścisz nową wersję swojej aplikacji.
- Crashlytics otrzymuje kolejny raport na temat problemu „A” po jego zamknięciu.
- Jeśli raport dotyczy wersji aplikacji, o której Crashlytics wiedziała w chwili zamykania problemu (co oznacza, że ta wersja wysłała raport o awarii w przypadku jakiejkolwiek awarii), Crashlytics nie uzna, że problem uległ regresji. Temat pozostanie zamknięty.
- Jeśli raport pochodzi z wersji aplikacji, o której Crashlytics nie wiedziała w chwili zamykania problemu (co oznacza, że ta wersja nigdy nie wysłała żadnego raportu o awarii w przypadku żadnej awarii), Crashlytics uzna, że problem ustąpił i ponownie go otworzy .
Gdy problem się cofa, wysyłamy alert o wykryciu regresji i dodajemy sygnał regresji do problemu, aby poinformować Cię, że Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby problem został ponownie otwarty ze względu na nasz algorytm regresji, „wycisz” problem, zamiast go zamykać.
Jeśli raport pochodzi ze starej wersji aplikacji, która po zamknięciu problemu nie wysyłała żadnych raportów o awariach, Crashlytics uzna, że problem uległ regresji i ponownie go otworzy.
Taka sytuacja może mieć miejsce w następującej sytuacji: Naprawiłeś błąd i wydałeś nową wersję aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji bez poprawki błędu. Jeśli przez przypadek jedna ze starszych wersji nigdy nie wysłała żadnych raportów o awariach po zamknięciu problemu, a ci użytkownicy zaczną napotykać błąd, wówczas te raporty o awariach spowodują regresję problemu.
Jeśli nie chcesz, aby problem został ponownie otwarty ze względu na nasz algorytm regresji, „wycisz” problem, zamiast go zamykać.