Ta strona została przetłumaczona przez Cloud Translation API.

Rozwiązywanie problemów z Crashlytics i najczęstsze pytania

Na tej stronie znajdziesz pomoc dotyczącą rozwiązywania problemów oraz odpowiedzi na najczęstsze pytania dotyczące 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

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 w konsoli Firebase. Możesz też zauważyć funkcję „warianty” w niektórych kwestiach. Oto 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 (np. awarie, błędy niekrytyczne i błędy ANR) oraz tworzy grupy zdarzeń o nazwie problemy – wszystkie zdarzenia w problemie mają wspólny punkt 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.

W ramach tej grupy zdarzeń ścieżki stosu prowadzące do błędu mogą się jednak różnić. 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. Za pomocą wariantów możesz debugować najczęstsze ścieżki stosu w ramach problemu i określać, czy do niepowodzenia prowadzą różne przyczyny.

Oto, co się zmieni:

Zmienione metadane wyświetlane w wierszu z problemem
Zrozumienie i rozwiązywanie problemów w aplikacji jest teraz łatwiejsze.
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 to w rzeczywistości nowy błąd.
Bardziej zaawansowane wyszukiwanie
Każdy problem zawiera więcej metadanych, które można wyszukiwać, na przykład typ wyjątku i nazwę pakietu.

Oto jak wprowadzamy te ulepszenia:

Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy pasują one do istniejącego problemu.
Jeśli nie, automatycznie zastosujemy lepszy sposób grupowania zdarzeń. algorytm do zdarzenia i sformułować nowy problem ze zmienionymi metadanymi. projektu.

To pierwsza duża aktualizacja, którą wprowadzamy w grupowaniu wydarzeń. Jeśli chcesz podzielić się opinią lub napotkasz problem, prześlij raport.

Nie widać dane o braku awarii lub alerty o szybkości

Jeśli nie widzisz danych o użytkownikach i sesjach bez awarii ani alertów dotyczących szybkości, sprawdź, czy używasz

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 włączoną Google Analytics w projekcie Firebase.
Włączono udostępnianie danych dla: Google Analytics. Więcej informacji o to ustawienie w Zarządzanie ustawieniami udostępniania danych Analytics
Masz do Twojej aplikacji. Ten pakiet SDK należy dodatkowo dodać do Crashlytics SDK.
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.
- Właściciel lub edytujący projekt, Administrator Firebase, Administrator jakości lub Administrator Crashlytics.
Członkowie projektu, którzy mają przypisaną dowolną z tych ról, mogą wyświetlać notatki opublikowane w problem, ale nie mogą usunąć ani napisać notatki.
- Wyświetlający projekt, Wyświetlający Firebase, Wyświetlający jakość, lub Wyświetlający Crashlytics

Jak obliczana jest liczba użytkowników, u których nie wystąpiła awaria?

Zapoznaj się z informacjami o danych dotyczących braku awarii.

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.

Poniżej znajdziesz informacje o uprawnieniach wymaganych do wyświetlania, zapisu i usuwania uwagi:

Uczestnicy projektu, którzy mają dowolną z tych ról, mogą wyświetlać i usuwać istniejące notatki oraz tworzyć nowe notatki dotyczące problemu.
- Właściciel lub edytujący projekt, Administrator Firebase, Administrator jakości lub Administrator Crashlytics.
Członkowie projektu, którzy mają jedną z tych ról, mogą wyświetlać notatki opublikowane w ramach problemu, ale nie mogą ich usuwać ani pisać.
- Wyświetlający projekt, Wyświetlający Firebase, Wyświetlający jakość, lub Wyświetlający Crashlytics

Integracje

Aplikacja korzysta też z pakietu SDK Google Mobile Ads, ale nie ma awarii

Jeśli Twój projekt używa Crashlytics i pakietu SDK Google Mobile Ads, 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 pakiet SDK Mobile Ads, wywołując metodę disableSDKCrashReporting.

Gdzie znajduje się mój zbiór danych BigQuery?

Gdy połączysz usługę Crashlytics z BigQuery, nowe zbiory danych zostaną znajduje się automatycznie w USA, niezależnie od lokalizacji projekt Firebase.

Pomoc dotycząca platformy

Problemy z regresją

Co to jest regresja problem?

Problem został rozwiązany, ale po pewnym czasie Crashlytics otrzymał nowe zgłoszenie, że problem powrócił. Crashlytics automatycznie otwiera te problemy, aby umożliwić ich rozwiązanie w sposób odpowiedni dla Twojej aplikacji.

Oto przykładowy scenariusz, który pokazuje, jak Crashlytics klasyfikuje problem jako regresję:

Po raz pierwszy Crashlytics otrzymuje raport o awarii „A”. Crashlytics otworzy problem związany z tą awarią (problem „A”).
Szybko naprawiasz błąd, zamknij problem „A”, a następnie opublikujesz nową wersję do aplikacji.
Crashlytics otrzymuje kolejny raport dotyczący problemu „A” po tym, jak został on zamknięty.
- Jeśli raport pochodzi z wersji aplikacji, którą Crashlytics znał w momencie zamknięcia problemu (co oznacza, że wersja wysłała raport o dowolnym załamaniu), Crashlytics nie uzna problemu za rozwiązany. Problem pozostanie zamknięty.
- Jeśli raport dotyczy wersji aplikacji, o której Crashlytics nie wiedział w momencie zamykania problemu (czyli w tej wersji nigdy nie wysłano żadnego raportu o awarii), Crashlytics uzna, że problem został rozwiązany i ponownie otworzy zgłoszenie.

Gdy problem pogorszy się, wysyłamy alert o wykryciu regresji i dodajemy sygnał regresji do problemu, informujący, że w wyniku Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, zamiast go zamykać, „wycisz” go.

Dlaczego w starszych wersjach aplikacji widzę problemy?

Jeśli raport pochodzi ze starej wersji aplikacji, która nigdy nie wysłała żadnych raportów o wypadkach, Crashlytics uzna, że problem uległ regresji, i ponownie otworzy zgłoszenie.

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 został ponownie otwarty z powodu naszego algorytmu regresji, zamiast zamykać problem, „wycisz go”.