Rozwiązywanie problemów z Crashlytics i najczęstsze pytania
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Na tej stronie znajdziesz pomoc w rozwiązywaniu problemów oraz odpowiedzi na najczęstsze pytania dotyczące korzystania z Crashlytics. Jeśli nie możesz znaleźć tego, czego szukasz, lub potrzebujesz dodatkowej pomocy, skontaktuj się z zespołem pomocy Firebase.
Rozwiązywanie problemów/najczęstsze pytania
W tabeli Problemy widoczne są różne formaty (a czasem „warianty”) w przypadku niektórych problemów
W tabeli Problemy w konsoli Firebase mogą pojawić się 2 różne formaty problemów. W niektórych problemach możesz też zauważyć
funkcję o nazwie „Warianty”. Oto dlaczego.
Na początku 2023 r. wdrożyliśmy ulepszony mechanizm analizy grupowania zdarzeń, a także zaktualizowany wygląd i kilka zaawansowanych funkcji związanych z nowymi problemami (np. wariantami). Przeczytaj nasz najnowszy
post na blogu, aby poznać wszystkie szczegóły. Możesz też przeczytać najważniejsze informacje poniżej.
Crashlytics analizuje wszystkie zdarzenia z aplikacji (takie jak awarie, błędy niekrytyczne czy błędy ANR) i tworzy grupy zdarzeń nazywane problemami. Wszystkie zdarzenia związane z problemem mają wspólny punkt awarii.
Aby grupować zdarzenia w te problemy, ulepszony mechanizm analizy analizuje wiele aspektów zdarzenia, w tym ramki w zrzucie stosu, komunikat o wyjątku, kod błędu i inne cechy platformy lub typu błędu.
Jednak w tej grupie zdarzeń zrzuty stosu prowadzące do niepowodzenia mogą być inne. Inny zrzut stosu może oznaczać inną przyczynę problemu.
Aby odzwierciedlić tę możliwą różnicę w obrębie problemu, tworzymy teraz w obrębie problemu warianty – każdy wariant jest podgrupą zdarzeń związanych z problemem, które mają ten sam punkt błędu oraz podobny zrzut stosu. Dzięki wariantom możesz debugować najczęstsze zrzuty stosu w obrębie danego problemu i określić, czy różne główne przyczyny niepowodzenia prowadzą do problemów.
Oto, czego się spodziewać po wprowadzeniu tych ulepszeń:
Odświeżone metadane wyświetlane w wierszu problemu Teraz łatwiej zrozumiesz i sprawdzisz problemy z aplikacją.
Mniej zduplikowanych problemów Zmiana numeru wiersza nie powoduje utworzenia 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 danego problemu.
Bardziej przydatne alerty i sygnały Nowy problem w rzeczywistości oznacza nowy błąd.
Bardziej zaawansowane wyszukiwanie Każdy numer zawiera metadane, które łatwiej wyszukać, takie jak typ wyjątku i nazwa pakietu.
Oto jak wprowadzamy te ulepszenia:
Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy nie występują w nich jakieś problemy.
Jeśli nie uda się dopasować danych, automatycznie zastosujemy do wydarzenia nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z odświeżonym wyglądem metadanych.
To pierwsza duża aktualizacja, w której wprowadzamy zmiany w naszej grupie wydarzeń. Jeśli masz uwagi lub masz problemy, skontaktuj się z nami,
przesyłając zgłoszenie
.
Brak alertów dotyczących braku awarii lub alertów o rosnącej liczbie problemów
Jeśli nie widzisz danych o braku awarii (takich jak liczba użytkowników, u których nie wystąpiła awaria) lub alerty o porcie
Nie widzę logów menu nawigacyjnego
Jeśli nie widzisz dzienników menu nawigacyjnego, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że spełniasz te wymagania:
do swojej aplikacji. Ten pakiet musisz też dodatkowo dodać do Crashlytics SDK.
Używasz
we wszystkich usługach, których używasz w swojej aplikacji.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Notatki umożliwiają członkom projektu komentowanie konkretnych problemów związanych z pytaniami, aktualizacjami stanu itp.
Gdy członek projektu opublikuje notatkę, jest ona oznaczona etykietą z adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich użytkowników projektu, którzy mają uprawnienia do jej wyświetlania.
Poniżej znajdziesz opis uprawnień wymaganych do wyświetlania, pisania i usuwania notatek:
Członkowie projektu z dowolną z poniższych ról mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Notatki umożliwiają członkom projektu komentowanie konkretnych problemów związanych z pytaniami, aktualizacjami stanu itp.
Gdy członek projektu opublikuje notatkę, jest ona oznaczona etykietą z adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich użytkowników projektu, którzy mają uprawnienia do jej wyświetlania.
Poniżej znajdziesz opis uprawnień wymaganych do wyświetlania, pisania i usuwania notatek:
Członkowie projektu z dowolną z poniższych ról mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.
Aplikacja korzysta też z pakietu SDK do reklam mobilnych Google, ale nie ulega awarii
Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, prawdopodobnie zgłaszający awarie zakłócają proces rejestrowania modułów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie awarii w pakiecie SDK do reklam mobilnych, wywołując disableSDKCrashReporting.
Gdzie znajduje się mój zbiór danych BigQuery?
Gdy połączysz Crashlytics z BigQuery, nowe zbiory danych, które utworzysz, będą automatycznie znajdować się w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Pomoc dotycząca platformy
Problemy wycofane
Co to jest problem, który pojawił się ponownie?
Po zamknięciu przez Ciebie wcześniej problemu powrócił on do normalnego stanu, ale Crashlytics otrzyma nowy raport o ponownym wystąpieniu problemu.
Crashlytics automatycznie ponownie otwiera te problemy, aby można było je naprawić w sposób odpowiedni dla aplikacji.
Oto przykładowy scenariusz, który wyjaśnia, jak Crashlytics klasyfikuje problem jako regresję:
Po raz pierwszy Crashlytics otrzymuje raport o awarii „A”. Crashlytics otworzy odpowiedni problem związany z tą awarią (problem „A”).
Szybko naprawiasz ten błąd, zamykasz problem „A” i publikujesz nową wersję aplikacji.
Gdy go zamkniesz, Crashlytics otrzyma kolejny raport dotyczący problemu „A”.
Jeśli raport pochodzi z wersji aplikacji, o której usługa Crashlytics była znana w momencie zamknięcia problemu (co oznacza, że wysłała raport o awarii w przypadku każdej awarii), Crashlytics nie uzna go za problem ponownie występujący. Problem pozostanie zamknięty.
Jeśli raport dotyczy wersji aplikacji, o której usługa Crashlytics nie wiedziała w momencie zamknięcia problemu (co oznacza, że ta wersja nigdy w ogóle nie wysyłała żadnego raportu o awarii), Crashlytics uzna problem za niewystępujący i ponownie go otworzy.
Gdy problem wystąpi ponownie, wyślemy alert dotyczący wykrywania regresji i dodamy do niego sygnał, aby poinformować Cię, że Crashlytics ponownie uruchomiło problem. Jeśli nie chcesz, aby problem otwierał się ponownie z powodu naszego algorytmu regresji, zamiast go zamykać, możesz go „zignorować”.
Dlaczego w przypadku starszych wersji aplikacji pojawiają się problemy, które ponownie się pojawiły?
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 się powtarza, i ponownie go otworzy.
Może się tak zdarzyć w takiej sytuacji: naprawiono błąd i opublikowano nową wersję aplikacji, ale użytkownicy nadal korzystają ze starszych wersji bez tych poprawek. Jeśli przypadkiem jedna ze starszych wersji nigdy w ogóle nie wysłała żadnych raportów o awariach w momencie zamknięcia problemu, a użytkownicy zaczęli napotkać błąd, wtedy te raporty o awariach wywołałyby problem ponownie.
Jeśli nie chcesz, aby problem otwierał się ponownie z powodu naszego algorytmu regresji, zamiast go zamykać, „zignoruj” go.
