Rozwiązywanie problemów z Crashlytics i najczęstsze pytania
Na tej stronie znajdziesz pomoc dotyczącą rozwiązywania problemów i odpowiedzi na najczęstsze pytania
pytań dotyczących korzystania z Crashlytics. Jeśli
nie możesz znaleźć tego, czego szukasz, lub potrzebujesz dodatkowej pomocy, skontaktuj się z
Obsługa Firebase.
Rozwiązywanie problemów/najczęstsze pytania
Różne formaty
(a czasem „warianty”) w przypadku niektórych problemów w tabeli Problemy.
W tabeli Problemy możesz zobaczyć 2 różne formaty problemów wymienionych w tabeli Problemy.
w konsoli Firebase. Możesz też zauważyć funkcję
„warianty” w niektórych kwestiach. Wyjaśniamy dlaczego.
Na początku 2023 r. wdrożyliśmy ulepszony mechanizm analizy grupujący zdarzenia jako
a także zaktualizowany wygląd i niektóre zaawansowane funkcje w przypadku nowych problemów (np.
wersji). Zobacz nasze najnowsze
post na blogu
.
Crashlytics analizuje wszystkie zdarzenia z aplikacji (takie jak awarie, niekrytyczne
i błędy ANR) oraz tworzy grupy zdarzeń nazywane problemami – wszystkie
mają wspólne
punkty awarii.
Aby pogrupować zdarzenia w te problemy, ulepszony mechanizm analizy analizuje teraz:
wielu aspektów zdarzenia, w tym ramki zrzutu stosu,
komunikat o wyjątku, kod błędu oraz inną platformę lub typ błędu
dla niektórych cech produktu.
Jednak w ramach tej grupy zdarzeń zrzuty stosu prowadzące do błędu
może być inna. Inny zrzut stosu może oznaczać inną przyczynę problemu.
Aby odzwierciedlić tę możliwą różnicę w ramach problemu, tworzymy
warianty w ramach problemów – każdy wariant jest podgrupą zdarzeń w danym problemie.
które mają ten sam punkt błędu i podobny zrzut stosu. W przypadku wariantów
możesz debugować typowe zrzuty stosu w obrębie problemu i sprawdzić, czy
mają różne przyczyny.
Oto zalety tych ulepszeń:
Ulepszone metadane wyświetlane w wierszu problemu Teraz łatwiej jest zrozumieć i eliminować problemy z aplikacją.
Mniej zduplikowanych problemów Zmiana numeru wiersza nie powoduje pojawienia się nowego problemu.
Łatwiejsze debugowanie złożonych problemów o różnych przyczynach Używaj wariantów do debugowania najczęstszych zrzutów stosu w obrębie problemu.
Bardziej przydatne alerty i sygnały Nowy problem oznacza nowy błąd.
Bardziej zaawansowane wyszukiwanie Każdy numer zawiera więcej metadanych, które można wyszukać,
np. typ wyjątku i nazwę pakietu.
Oto jak wprowadzamy te ulepszenia:
Gdy otrzymamy nowe zdarzenia z aplikacji, sprawdzimy, czy pasują do istniejących
Google Cloud.
Jeśli nie, automatycznie zastosujemy
lepszy sposób grupowania zdarzeń.
do zdarzenia i sformułować nowy problem ze zmienionymi metadanymi.
projektu.
To pierwsza duża aktualizacja, którą wprowadzamy w grupowaniu wydarzeń. Jeśli
Jeśli masz uwagi lub napotkasz jakieś problemy, skontaktuj się z nami do
i wypełnianie zgłoszenia.
Nie widać
dane o braku awarii lub alerty o szybkości
Jeśli nie widzisz danych, w których przypadku nie wystąpiła awaria (np. liczby użytkowników i sesji, w których przypadku nie wystąpiła awaria)
i/lub alertów o rosnącej liczbie problemów, upewnij się, że używasz funkcji
Nie widzę logów menu nawigacyjnego
Jeśli nie widzisz
dzienniki menu nawigacyjnego,
zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że spełniasz te wymagania:
Masz
do Twojej aplikacji. Ten pakiet SDK należy dodatkowo dodać do pakietu SDK Crashlytics.
Używasz
w przypadku wszystkich produktów, których używasz w aplikacji.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Notatki umożliwiają uczestnikom projektu komentowanie konkretnych problemów związanych z pytaniami i stanem
aktualizacje itd.
Gdy członek projektu opublikuje notatkę, zostanie ona oznaczona etykietą z adresem e-mail jego Google
koncie. Ten adres e-mail jest widoczny wraz z notatką dla całego projektu
użytkowników mających uprawnienia do wyświetlania notatki.
Poniżej znajdziesz informacje o uprawnieniach wymaganych do wyświetlania, zapisu i usuwania
uwagi:
Członkowie projektu z dowolną z tych ról mogą wyświetlać i usuwać istniejące
notatki i pisanie nowych notatek na temat problemu.
Członkowie projektu, którzy mają przypisaną dowolną z tych ról, mogą wyświetlać notatki opublikowane w
problem, ale nie może usunąć ani napisać notatki.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Notatki umożliwiają uczestnikom projektu komentowanie konkretnych problemów związanych z pytaniami i stanem
aktualizacje itd.
Gdy członek projektu opublikuje notatkę, zostanie ona oznaczona etykietą z adresem e-mail jego Google
koncie. Ten adres e-mail jest widoczny wraz z notatką dla całego projektu
użytkowników mających uprawnienia do wyświetlania notatki.
Poniżej znajdziesz informacje o uprawnieniach wymaganych do wyświetlania, zapisu i usuwania
uwagi:
Członkowie projektu z dowolną z tych ról mogą wyświetlać i usuwać istniejące
notatki i pisanie nowych notatek na temat problemu.
Członkowie projektu, którzy mają przypisaną dowolną z tych ról, mogą wyświetlać notatki opublikowane w
problem, ale nie może usunąć ani napisać notatki.
Aplikacja używa też
Pakiet SDK do reklam mobilnych Google, ale nie występują awarie
Jeśli Twój projekt używa Crashlytics i pakietu SDK do reklam mobilnych Google,
jest prawdopodobne, że narzędzia do zgłaszania awarii zakłócają działanie
rejestracji modułów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz zgłaszanie awarii w
pakietu SDK do reklam mobilnych, wywołując funkcję disableSDKCrashReporting.
Gdzie znajduje się mój zbiór danych BigQuery?
Po połączeniu Crashlytics z BigQuery nowe zbiory danych
znajduje się automatycznie w USA, niezależnie od lokalizacji
projekt Firebase.
Pomoc dotycząca platformy
Problemy, które pojawiły się znowu
Co to jest regresja
problem?
Występuje regresja, gdy wcześniej został przez Ciebie zamknięty problem, ale
Crashlytics otrzymuje nowy raport o powtórnym wystąpieniu problemu.
Crashlytics automatycznie ponownie otwiera te problemy, aby umożliwić Ci
odpowiednio do potrzeb aplikacji.
Oto przykładowy scenariusz, który wyjaśnia, jak Crashlytics kategoryzuje
jako regresji.
Po raz pierwszy Crashlytics otrzymuje raport o awariach
„A”. Crashlytics wyświetli odpowiedni problem dotyczący tej awarii (problem „A”).
Szybko naprawiasz błąd, zamknij problem „A”, a następnie opublikujesz nową wersję
do aplikacji.
Crashlytics otrzymuje kolejny raport o problemie A. po zamknięciu
Google Cloud.
Jeśli raport pochodzi z wersji aplikacji, którą znała Crashlytics
kiedy zamknięto problem (co oznacza, że wersja spowodowała awarię).
w ogóle nie zgłosi żadnej awarii), Crashlytics nie weźmie pod uwagę
a wraz z nim ponownie. Problem pozostanie zamknięty.
Jeśli raport pochodzi z wersji aplikacji, w przypadku której Crashlytics nie, kiedy zamknięto problem (co oznacza, że wersja
nigdy nie wysłał żadnego raportu o awarii), a następnie
Crashlytics uzna, że problem ustąpił, i ponownie otworzy
Google Cloud.
.
Gdy problem ustąpi, wysyłamy alert o wykryciu regresji i dodajemy
sygnał regresji, aby poinformować Cię, że Crashlytics
ponownie otworzył problem. Jeśli nie chcesz, aby dany problem został ponownie otwarty ze względu na nasze
algorytm regresji, „mute”; problemu, zamiast ją zamykać.
Dlaczego u mnie się pogorszył
problemów ze starszymi wersjami aplikacji?
Jeśli raport pochodzi ze starej wersji aplikacji, która nigdy nie wysyłała żadnych raportów o awariach na
po zamknięciu problemu Crashlytics bierze pod uwagę
problem został rozwiązany i zostanie ponownie otwarty.
Może się tak zdarzyć, jeśli: naprawiono błąd i
opublikowała nową wersję Twojej aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji
bez poprawek. Jeśli przez przypadek jedna ze starszych wersji nigdy nie została wysłana
żadnych raportów o awariach w momencie zamknięcia problemu, a użytkownicy zaczną
napotkania błędu, raporty o awariach wywołałyby ponowne wystąpienie problemu.
Jeśli nie chcesz, aby problem był ponownie otwierany przez nasz algorytm regresji, kliknij „Wycisz”.
problemu, zamiast ją zamykać.
