Ta strona zawiera pomoc w rozwiązywaniu problemów i 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 nawigacyjnych i/lub alertów dotyczących prędkości, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że masz włączone Google Analytics w swoim projekcie Firebase.
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ądzane w konsoli Google Analytics.
Oprócz pakietu Firebase Crashlytics SDK upewnij się, że do swojej aplikacji został dodany pakiet SDK Firebase dla Google Analytics ( iOS+ | Android ).
Upewnij się, że używasz najnowszych wersji wszystkich swoich pakietów SDK Firebase ( iOS+ | Android ).
W szczególności sprawdź, czy używasz co najmniej następujących wersji Firebase SDK 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. Możesz także zauważyć funkcję o nazwie „warianty” w niektórych swoich problemach. Dlatego!
Na początku 2023 roku wprowadziliśmy ulepszony mechanizm analizy do grupowania wydarzeń, a także zaktualizowany projekt i kilka zaawansowanych funkcji dla nowych problemów (takich jak warianty!). Sprawdź nasz najnowszy wpis na blogu , aby poznać wszystkie szczegóły, ale możesz przeczytać poniżej o najważniejszych wydarzeniach.
Crashlytics analizuje wszystkie zdarzenia z Twojej aplikacji (takie jak awarie, błędy niekrytyczne 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 mechanizm analizy analizuje teraz wiele aspektów zdarzenia, w tym ramki w śledzeniu stosu, komunikat o wyjątku, kod błędu i inne cechy platformy lub typu błędu.
Jednak w ramach tej grupy zdarzeń ślady stosu prowadzące do niepowodzenia mogą być inne. Inny ślad stosu może oznaczać inną pierwotną przyczynę. Aby przedstawić tę możliwą różnicę w ramach problemu, tworzymy teraz warianty w ramach 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żna debugować najczęstsze ślady stosu w ramach problemu i określić, czy różne przyczyny prowadzą do niepowodzenia.
Oto, czego doświadczysz dzięki tym ulepszeniom:
Zmienione metadane wyświetlane w wierszu problemu
Łatwiej jest teraz zrozumieć i segregować problemy w aplikacji.Mniej zduplikowanych problemów
Zmiana numeru linii nie powoduje powstania 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.Bardziej zaawansowane wyszukiwanie
Każde wydanie zawiera więcej możliwych do przeszukiwania metadanych, 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ą do istniejącego problemu.
Jeśli nie ma dopasowania, automatycznie zastosujemy nasz inteligentniejszy algorytm grupowania zdarzeń do zdarzenia i utworzymy nowy problem z odnowionym projektem metadanych.
To pierwsza duża aktualizacja naszego grupowania wydarzeń. Jeśli masz uwagi lub napotkasz jakiekolwiek problemy, daj nam znać, wypełniając raport.
Wartość bez awarii reprezentuje odsetek użytkowników, którzy korzystali z Twojej aplikacji, ale nie mieli awarii w określonym czasie.
Oto wzór do obliczania 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 to łączna liczba użytkowników, którzy korzystali z Twojej aplikacji w okresie wybranym z menu rozwijanego w prawym górnym rogu panelu Crashlytics.
Odsetek użytkowników bez awarii to agregacja w czasie , a nie średnia.
Załóżmy na przykład, że Twoja aplikacja ma trzech użytkowników; nazwijmy ich Użytkownikiem A, Użytkownikiem B i Użytkownikiem C. Poniższa tabela pokazuje, którzy użytkownicy wchodzili w interakcję z Twoją aplikacją każdego dnia i którzy z nich mieli tego dnia awarię:
| Poniedziałek | Wtorek | Środa | |
|---|---|---|---|
| Użytkownicy, którzy korzystali z Twojej aplikacji | A, B, C | A, B, C | A, B |
| Użytkownik, który miał awarię | C | B | A |
W środę Twój odsetek użytkowników bez awarii wynosi 50% (1 na 2 użytkowników był bez awarii).
Dwóch użytkowników korzystało z Twojej aplikacji w środę, ale tylko jeden z nich (Użytkownik B) nie miał żadnych awarii.W ciągu ostatnich 2 dni Twój odsetek użytkowników bez awarii wynosił 33,3% (1 na 3 użytkowników był bez awarii).
Trzech użytkowników korzystało z Twojej aplikacji w ciągu ostatnich dwóch dni, ale tylko jeden z nich (Użytkownik C) nie miał żadnych awarii.W ciągu ostatnich 3 dni Twój odsetek użytkowników bez awarii wynosił 0% (0 na 3 użytkowników było bez awarii).
Trzech użytkowników korzystało z Twojej aplikacji w ciągu ostatnich trzech dni, ale żaden z nich nie miał żadnych awarii.
Notatki umożliwiają członkom projektu komentowanie konkretnych problemów za pomocą pytań, aktualizacji statusu itp.
Gdy 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 z uprawnieniami do przeglądania notatki.
Poniżej opisano uprawnienia wymagane do przeglądania, zapisywania 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 dotyczące problemu.
Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać notatki opublikowane w sprawie, ale nie mogą ich usuwać ani pisać.
- Przeglądarka projektów , Przeglądarka Firebase , Przeglądarka jakości lub Przeglądarka Crashlytics
Integracje
Jeśli Twój projekt korzysta z Crashlytics wraz z pakietem SDK do reklam mobilnych Google, prawdopodobnie moduły zgłaszające awarie zakłócają rejestrację procedur obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie awarii w pakiecie SDK do reklam mobilnych, wywołując funkcję disableSDKCrashReporting .
Po połączeniu Crashlytics z BigQuery nowe zbiory danych, które tworzysz, są automatycznie umieszczane w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Wsparcie platformy
Regresowane problemy
Problem uległ regresji po jego wcześniejszym zamknięciu, ale Crashlytics otrzymuje nowy raport, że problem pojawił się ponownie. Crashlytics automatycznie ponownie otwiera te cofnięte problemy, dzięki czemu możesz je odpowiednio rozwiązać dla swojej aplikacji.
Oto przykładowy scenariusz wyjaśniający, w jaki sposób Crashlytics klasyfikuje problem jako regresję:
- Po raz pierwszy Crashlytics otrzymuje raport o awarii dotyczący awarii „A”. Crashlytics otwiera odpowiedni problem dla tej awarii (problem „A”).
- Szybko naprawiasz ten błąd, zamykasz problem „A”, a następnie wydajesz nową wersję swojej aplikacji.
- Crashlytics otrzymuje kolejny raport dotyczący problemu „A” po jego zamknięciu.
- Jeśli zgłoszenie pochodzi z wersji aplikacji, o której Crashlytics wiedziało w momencie zamykania problemu (co oznacza, że ta wersja w ogóle wysłała raport o awarii w przypadku jakiejkolwiek awarii), Crashlytics nie uzna problemu za cofnięty. Temat pozostanie zamknięty.
- Jeśli zgłoszenie dotyczy wersji aplikacji, o której Crashlytics nie wiedziało w momencie zamykania problemu (co oznacza, że wersja nigdy nie wysłała żadnego raportu o awarii w przypadku jakiejkolwiek 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 z powodu naszego algorytmu regresji, „wycisz” problem zamiast go zamykać.
Jeśli zgłoszenie pochodzi ze starej wersji aplikacji, która nigdy nie wysyłała żadnych raportów o awariach po zamknięciu problemu, Crashlytics uzna, że problem został cofnięty i otworzy go ponownie.
Taka sytuacja może wystąpić w następującej sytuacji: naprawiłeś błąd i wydałeś nową wersję swojej aplikacji, ale nadal masz użytkowników starszych wersji bez poprawki. Jeśli przypadkowo jedna z tych starszych wersji nigdy nie wysłała żadnych raportów o awariach po zamknięciu problemu, a ci użytkownicy zaczną napotykać błąd, wtedy te raporty o awariach wywołałyby regresję problemu.
Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, „wycisz” problem zamiast go zamykać.