Ta strona zawiera 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 szybkości, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że masz włączoną usługę Google Analytics w swoim projekcie Firebase.
Upewnij się, że udostępnianie danych jest włączone dla Google Analytics 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 Twojej aplikacji ( iOS+ | Android ) został dodany pakiet Firebase SDK dla Google Analytics.
Upewnij się, że korzystasz z najnowszych wersji wszystkich pakietów SDK Firebase ( iOS+ | Android ).
W szczególności sprawdź, czy używasz co najmniej następujących wersji pakietu Firebase SDK dla Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ dla macOS i tvOS) | Android — wersja 17.2.3+(BoM v24.7.1+) .
Odsetek użytkowników bez awarii to agregacja w czasie , a nie średnia.
Wartość bez awarii reprezentuje odsetek użytkowników, którzy weszli w interakcję z Twoją aplikacją, ale w określonym czasie nie wystąpiła awaria. Okres ten wybierasz z menu w prawym górnym rogu panelu Crashlytics.
Na przykład wyobraź sobie, że Twoja aplikacja ma trzech użytkowników; nazwiemy ich Użytkownik A, Użytkownik B i Użytkownik C. Poniższa tabela pokazuje, którzy użytkownicy korzystają z Twojej aplikacji każdego dnia i który z nich miał 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ę odsetek użytkowników bez awarii wynosi 50% (1 na 2 użytkowników nie powodował awarii).
Dwóch użytkowników korzystało z Twojej aplikacji w środę, ale tylko jeden z nich (użytkownik B) nie miał awarii.W ciągu ostatnich 2 dni odsetek użytkowników bez awarii wynosi 33,3% (1 na 3 użytkowników nie uległo 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ł awarii.W ciągu ostatnich 3 dni Twój odsetek użytkowników bez awarii wynosi 0% (0 z 3 użytkowników nie powodowało awarii).
Trzech użytkowników korzystało z Twojej aplikacji w ciągu ostatnich trzech dni, ale u żadnego z nich nie wystąpiły żadne awarie.
Integracje
Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, prawdopodobnie zgłaszający awarie zakłócają rejestrację modułó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 zbiory danych, które utworzysz, będą automatycznie zlokalizowane w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Obsługa platformy
Cofnięte problemy
Problem uległ regresji, gdy poprzednio go zamknąłeś, ale Crashlytics otrzymuje nowy raport, że problem wystąpił ponownie. Crashlytics automatycznie ponownie otwiera te problemy, które cofnęły się, aby można było je rozwiązać zgodnie z potrzebami Twojej aplikacji.
Oto przykładowy scenariusz, który wyjaśnia, w jaki sposób Crashlytics klasyfikuje problem jako regresję:
- Po raz pierwszy w historii Crashlytics otrzymuje raport o awarii o Crashu „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 otrzyma kolejny raport o problemie „A” po jego zamknięciu.
- Jeśli zgłoszenie pochodzi z wersji aplikacji, o której Crashlytics wiedziało , gdy zamknąłeś problem (co oznacza, że wersja wysłała raport o awarii w przypadku jakiejkolwiek awarii), Crashlytics nie uzna problemu za cofnięty. Sprawa pozostanie zamknięta.
- Jeśli raport pochodzi z wersji aplikacji, o której Crashlytics nie wiedział podczas zamykania problemu (co oznacza, że ta wersja nigdy nie wysłała żadnego raportu o awariach), Crashlytics uzna, że problem uległ regresji i ponownie go otworzy .
Gdy problem cofa się, wysyłamy alert o wykryciu regresji i dodajemy do niego sygnał regresji, aby poinformować Cię, że Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby sprawa została ponownie otwarta z powodu naszego algorytmu regresji, „wycisz” problem zamiast go zamykać.
Jeśli raport 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ł wycofany i ponownie go otworzy.
Taka sytuacja może mieć miejsce w następującej sytuacji: Naprawiłeś błąd i wydałeś nową wersję swojej aplikacji, ale nadal masz użytkowników w starszych wersjach bez poprawki. Jeśli przypadkiem 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, te raporty o awariach wywołają problem cofnięty.
Jeśli nie chcesz, aby sprawa została ponownie otwarta z powodu naszego algorytmu regresji, „wycisz” problem zamiast go zamykać.