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
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.
Jeśli nie widzisz wskaźników wolnych od awarii (takich jak użytkownicy i sesje bez awarii) i/lub alertów dotyczących prędkości, upewnij się, że używasz pakietu
Jeśli nie widzisz dzienników nawigacji , zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics. Upewnij się, że spełniasz następujące wymagania:
Włączyłeś Google Analytics w swoim projekcie Firebase.
Włączyłeś udostępnianie danych dla Google Analytics. Więcej informacji o tym ustawieniu znajdziesz w artykule Zarządzanie ustawieniami udostępniania danych Analytics
do swojej aplikacji. Ten zestaw SDK należy dodać oprócz zestawu SDK Crashlytics.
Używaszdla wszystkich produktów, których używasz w swojej aplikacji.
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.
Zobacz Omówienie wskaźników bezawaryjnych .
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ć.