Ta strona zawiera pomoc w rozwiązywaniu problemów oraz odpowiedzi na najczęściej 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 — v17.2.3+(BoM v24.7.1+) .
Wartość bez awarii reprezentuje odsetek użytkowników, którzy weszli w interakcję z Twoją aplikacją, ale nie mieli awarii w określonym czasie.
Oto wzór na obliczenie odsetka 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
Gdy wystąpi awaria, 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 korzystali z Twojej aplikacji w okresie wybranym z menu w prawym górnym rogu panelu Crashlytics.
Odsetek użytkowników bez awarii to agregacja w czasie , a nie średnia.
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 korzystali 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 powodował 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 odsetek użytkowników bez awarii wynosi 0% (0 z 3 użytkowników nie było żadnych 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.
Notatki umożliwiają członkom projektu komentowanie określonych problemów za pomocą pytań, aktualizacji statusu itp.
Gdy członek projektu opublikuje notatkę, zostanie 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 wyświetlania notatki.
Poniżej opisano dostęp wymagany do przeglądania, pisania i usuwania notatek:
Członkowie projektu o dowolnej z poniższych ról mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe notatki dotyczące problemu.
- Właściciel lub redaktor projektu , administrator Firebase , administrator jakości lub administrator Crashlytics
Członkowie projektu z dowolną z poniższych ról mogą wyświetlać notatki opublikowane w sprawie, ale nie mogą usuwać ani pisać notatki.
- 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 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 tworzysz, są automatycznie umieszczane w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Obsługa platformy
Problemy cofnięte
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 naprawisz ten błąd, zamkniesz problem „A”, a następnie wydasz 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ł w momencie zamykania problemu (co oznacza, że ta wersja nigdy nie wysłała żadnego raportu o awariach), Crashlytics uzna, że problem cofnął się 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 go otworzył. Jeśli nie chcesz, aby sprawa została ponownie otwarta 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ł 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 cofający się.
Jeśli nie chcesz, aby sprawa została ponownie otwarta z powodu naszego algorytmu regresji, „wycisz” problem zamiast go zamykać.