Dostosowywanie raportów o awariach Firebase Crashlytics

iOS+ Android Efekt kołysania Unity

W panelu Crashlytics możesz kliknąć problem i otrzymać szczegółowe w raporcie o zdarzeniach. Możesz dostosować te raporty, aby lepiej zrozumieć, co dzieje się w Twojej aplikacji i w jakich okolicznościach Crashlytics

• Dostosuj aplikację do rejestrowania kluczy niestandardowych, niestandardowe komunikaty dziennika i identyfikatory użytkowników.

• Zgłaszaj wyjątki do Crashlytics.

• Automatycznie pobieraj logi menu nawigacyjnego, jeśli aplikacja używa pakietu SDK Firebase dla Google Analytics. Logi te dają Ci wgląd w działań użytkownika, które doprowadziły do zdarzenia zebranego przez Crashlytics w Twojej aplikacji.

• Wyłącz automatyczne zgłaszanie awarii oraz włączyć raportowanie dla użytkowników. Pamiętaj, że Crashlytics domyślnie zbiera raporty o awariach użytkowników aplikacji.

Dodaj klucze niestandardowe

Klucze niestandardowe pomagają uzyskać konkretny stan aplikacji, który doprowadził do awarii. Dowolne pary klucz-wartość możesz powiązać z raportami o awariach, a następnie użyć funkcji niestandardowe klucze do wyszukiwania i filtrowania raportów o awariach w konsoli Firebase.

• W panelu Crashytics możesz wyszukiwać problemy pasujące do klucza niestandardowego.
• Podczas sprawdzania konkretnego problemu w konsoli możesz wyświetlić powiązane klucze niestandardowe dla każdego zdarzenia (podkarta Klucze), a nawet filtrować dane zdarzeń według kluczy niestandardowych (menu Filtr u góry strony).

.

Uwaga: Crashlytics obsługuje maksymalnie 64 pary klucz-wartość. Po osiągnie ten próg, dodatkowe wartości nie są zapisywane. Każda para klucz-wartość może mogą mieć maksymalnie 1 kB.

Do ustawiania par klucz-wartość użyj metody setCustomValue. Przykład:

Swift

// Set int_key to 100.
Crashlytics.crashlytics().setCustomValue(100, forKey: "int_key")

// Set str_key to "hello".
Crashlytics.crashlytics().setCustomValue("hello", forKey: "str_key")

Objective-C

Podczas ustawiania liczb całkowitych, wartości logicznych lub liczb zmiennoprzecinkowych wpisz wartość w polu @(value).

// Set int_key to 100.
[[FIRCrashlytics crashlytics] setCustomValue:@(100) forKey:@"int_key"];

// Set str_key to "hello".
[[FIRCrashlytics crashlytics] setCustomValue:@"hello" forKey:@"str_key"];

Możesz też zmienić wartość istniejącego klucza, wywołując go i ustawiając do innej wartości. Przykład:

Swift

Crashlytics.crashlytics().setCustomValue(100, forKey: "int_key")

// Set int_key to 50 from 100.
Crashlytics.crashlytics().setCustomValue(50, forKey: "int_key")

Objective-C

[[FIRCrashlytics crashlytics] setCustomValue:@(100) forKey:@"int_key"];

// Set int_key to 50 from 100.
[[FIRCrashlytics crashlytics] setCustomValue:@(50) forKey:@"int_key"];

Dodaj pary klucz-wartość zbiorczo, używając metody setCustomKeysAndValues z parametrem NSDictionary jako jedyny parametr:

Swift

let keysAndValues = [
                 "string key" : "string value",
                 "string key 2" : "string value 2",
                 "boolean key" : true,
                 "boolean key 2" : false,
                 "float key" : 1.01,
                 "float key 2" : 2.02
                ] as [String : Any]

Crashlytics.crashlytics().setCustomKeysAndValues(keysAndValues)

Objective-C

NSDictionary *keysAndValues =
    @{@"string key" : @"string value",
      @"string key 2" : @"string value 2",
      @"boolean key" : @(YES),
      @"boolean key 2" : @(NO),
      @"float key" : @(1.01),
      @"float key 2" : @(2.02)};

[[FIRCrashlytics crashlytics] setCustomKeysAndValues: keysAndValues];

Dodaj niestandardowe komunikaty logu

Aby uzyskać więcej informacji na temat zdarzeń prowadzących do awarii, możesz dodać niestandardowe logi Crashlytics do Twojej aplikacji. Crashlytics wiąże logi z danymi o awariach i wyświetla je na stronie Crashlytics Konsola Firebase na karcie Logi.

Uwaga: aby uniknąć spowalniania aplikacji, Crashlytics ogranicza rozmiar logów do 64 kB i usuwa starsze wpisy, jeśli logi sesji przekroczą ten limit.

Swift

Aby wskazać problemy, użyj log() lub log(format:, arguments:). Jeśli by uzyskać przydatne dane wyjściowe dziennika z komunikatami, obiektem, do którego log() musi spełniać wymagania: CustomStringConvertible. usłudze. Funkcja log() zwraca właściwość opisu zdefiniowaną przez Ciebie dla argumentu obiektu. Przykład:

Crashlytics.crashlytics().log("Higgs-Boson detected! Bailing out…, \(attributesDict)")

Wartości formatów zwrócone przez wywołanie: .log(format:, arguments:) getVaList() Przykład:

Crashlytics.crashlytics().log(format: "%@, %@", arguments: getVaList(["Higgs-Boson detected! Bailing out…", attributesDict]))

Aby dowiedzieć się więcej o tym, jak korzystać z aplikacji log() lub log(format:, arguments:), zapoznaj się z artykułami Crashlytics. dokumentacji referencyjnej.

Objective-C

Aby wskazać problemy, użyj log lub logWithFormat. Pamiętaj, że jeśli chcą otrzymywać przydatne dane wyjściowe dziennika z komunikatami, obiektem, który przekazujesz do dowolnej z tych metod musi zastąpić właściwość instancji description. Przykład:

[[FIRCrashlytics crashlytics] log:@"Simple string message"];

[[FIRCrashlytics crashlytics] logWithFormat:@"Higgs-Boson detected! Bailing out... %@", attributesDict];

[[FIRCrashlytics crashlytics] logWithFormat:@"Logging a variable argument list %@" arguments:va_list_arg];

Więcej informacji o tym, jak korzystać z log i logWithFormat, znajdziesz w Dokumentacja Crashlytics

Ustawianie identyfikatorów użytkowników

Przy diagnozowaniu problemu często warto wiedzieć, u których użytkowników w przypadku danej awarii. Crashlytics umożliwia anonimowe identyfikowanie użytkowników raporty o awariach.

Aby dodać identyfikatory użytkowników do raportów, przypisz każdemu użytkownikowi unikalny identyfikator w numeru identyfikacyjnego, tokena lub zahaszowanej wartości:

Swift

Crashlytics.crashlytics().setUserID("123456789")

Objective-C

[[FIRCrashlytics crashlytics] setUserID:@"123456789"];

Jeśli po ustawieniu identyfikatora użytkownika trzeba będzie go usunąć, zresetuj wartość do pustym ciągiem znaków. Wyczyszczenie identyfikatora użytkownika nie spowoduje usunięcia istniejącego Rekordy Crashlytics. Jeśli musisz usunąć rekordy powiązane z użytkownikiem ID, skontaktuj się z zespołem pomocy Firebase.

Zgłaszanie wyjątków niekrytycznych

Oprócz automatycznego zgłaszania awarii aplikacji Crashlytics umożliwia też rejestrujesz niekrytyczne wyjątki i wysyłasz je do Ciebie przy następnej aplikacji. nowych funkcji.

Uwaga: Crashlytics przechowuje tylko 8 ostatnich wyjątków w danym okresie i sesji w aplikacji. Jeśli aplikacja zgłasza więcej niż 8 wyjątków w sesji, starsze wyjątki od tej reguły.

Możesz rejestrować niekrytyczne wyjątki, rejestrując obiekty NSError za pomocą funkcji Metoda recordError. Funkcja recordError przechwytuje stos wywołań wątku przez wywołanie [NSThread callStackReturnAddresses]

Swift

Crashlytics.crashlytics().record(error: error)

Objective-C

[[FIRCrashlytics crashlytics] recordError:error];

Korzystając z metody recordError, musisz znać NSError oraz jak Crashlytics wykorzystuje te dane do grupowania awarii. Nieprawidłowe informacje użycie metody recordError może powodować nieprzewidywalne działanie i może sprawia, że Crashlytics ogranicza raportowanie rejestrowanych błędów dotyczących Twojej aplikacji.

Obiekt NSError ma 3 argumenty:

• domain: String
• code: Int
• userInfo: [AnyHashable : Any]? = nil

W przeciwieństwie do awarii krytycznych, które są grupowane za pomocą analizy zrzutu stosu, rejestrowane błędy są grupowane według kolumn domain i code. To ważne rozróżnienie. między awariami krytycznymi a zarejestrowanymi błędami. Przykład:

Swift

let userInfo = [
  NSLocalizedDescriptionKey: NSLocalizedString("The request failed.", comment: ""),
  NSLocalizedFailureReasonErrorKey: NSLocalizedString("The response returned a 404.", comment: ""),
  NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString("Does this page exist?", comment: ""),
  "ProductID": "123456",
  "View": "MainView"
]

let error = NSError.init(domain: NSCocoaErrorDomain,
                         code: -1001,
                         userInfo: userInfo)

Objective-C

NSDictionary *userInfo = @{
  NSLocalizedDescriptionKey: NSLocalizedString(@"The request failed.", nil),
  NSLocalizedFailureReasonErrorKey: NSLocalizedString(@"The response returned a 404.", nil),
  NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString(@"Does this page exist?", nil),
  @"ProductID": @"123456",
  @"View": @"MainView",
};

NSError *error = [NSError errorWithDomain:NSCocoaErrorDomain
                                     code:-1001
                                 userInfo:userInfo];

Gdy zapiszesz ten błąd, spowoduje to utworzenie nowego problemu pogrupowanego według NSSomeErrorDomain i -1001. Dodatkowe zarejestrowane błędy, które używają tego samego wartości domeny i kodu są pogrupowane w ramach tego samego problemu. Dane zawarte w obiekt userInfo jest konwertowany na pary klucz-wartość i wyświetlany w kluczy/logów w ramach danego problemu.

Uwaga: nie używaj unikalnych wartości, takich jak identyfikator użytkownika, identyfikator produktu i sygnatury czasowe. w polach domeny i kodu. Zastosowanie unikalnych wartości w tych polach zwiększa moc zbioru problemów i może spowodować, że Crashlytics będzie musiała ograniczać raportowania zarejestrowanych błędów w Twojej aplikacji. Unikalne wartości należy zamiast tego dodać do w obiekcie słownika userInfo.

Logi i klucze niestandardowe

Podobnie jak w przypadku raportów o awariach możesz osadzić dzienniki i klucze niestandardowe, aby wzbogacić je o kontekst NSError. Występuje jednak różnica w tym, do jakich danych są dołączane logi. między błędami i błędami zarejestrowanymi. W przypadku awarii i ponownego uruchomienia aplikacji logi pobrane przez Crashlytics z dysku to te, które zostały zapisane czas wypadku. Po zarejestrowaniu NSError aplikacja nie wykona usunąć. Ponieważ Crashlytics wysyła raport o błędach tylko na przy następnym uruchomieniu aplikacji i musi ograniczyć ilość miejsca przydzielonego do logów na dysku, można zarejestrować wystarczająco dużo danych po zarejestrowaniu parametru NSError, aby wszystkie logi są rotowane zgodnie z momentem, gdy Crashlytics wysyła raport z urządzenia. Pamiętaj o tym podczas rejestrowania danych z funkcji NSErrors i korzystania z dzienników za pomocą kluczy niestandardowych.

Możliwe spowolnienie działania witryny

Pamiętaj, że zapisywanie danych NSError może być dość kosztowne. W dowolnym momencie , Crashlytics przechwytuje stos wywołań bieżącego wątku za pomocą proces nazywany „odwijaniem stosu”. Ten proces może wymagać dużej mocy obliczeniowej procesora i operacji wejścia-wyjścia, zwłaszcza w architekturach, które obsługują rozwijanie plików DWARF (arm64 i x86). Po zakończeniu odwracania informacje informacje są synchronicznie zapisywane na dysku. Zapobiega to utracie danych w przypadku awarii następnego wiersza.

Chociaż można bezpiecznie zadzwonić ten interfejs API w wątku w tle, pamiętaj, że wysyłanie tego wywołania do innego kolejka straci kontekst bieżącego zrzutu stosu.

Co z NSExceptions?

Crashlytics nie oferuje możliwości logowania i rejestrowania zdarzeń NSException bezpośrednio w instancjach. Ogólnie interfejsy API Cocoa i Cocoa Touch nie są w takiej sytuacji. Oznacza to, że użycie atrybutu @catch może spowodować bardzo poważne, niezamierzone skutkami ubocznymi, nawet jeśli używa się go bardzo ostrożnie. Nigdy nie używaj w kodzie instrukcji @catch. Więcej informacji: Dokumentacja Apple w danej sprawie.

Dostosuj zrzuty stosu

Jeśli Twoja aplikacja działa w środowisku nienatywnym (takim jak C++ lub Unity), możesz użyć interfejsu Exception Model API do raportowania metadanych awarii w wyjątku natywnym aplikacji . Zgłoszone wyjątki są oznaczone jako niekrytyczne.

Swift

var  ex = ExceptionModel(name:"FooException", reason:"There was a foo.")
ex.stackTrace = [
  StackFrame(symbol:"makeError", file:"handler.js", line:495),
  StackFrame(symbol:"then", file:"routes.js", line:102),
  StackFrame(symbol:"main", file:"app.js", line:12),
]

crashlytics.record(exceptionModel:ex)

Objective-C

FIRExceptionModel *model =
    [FIRExceptionModel exceptionModelWithName:@"FooException" reason:@"There was a foo."];
model.stackTrace = @[
  [FIRStackFrame stackFrameWithSymbol:@"makeError" file:@"handler.js" line:495],
  [FIRStackFrame stackFrameWithSymbol:@"then" file:@"routes.js" line:102],
  [FIRStackFrame stackFrameWithSymbol:@"main" file:@"app.js" line:12],
];

[[FIRCrashlytics crashlytics] recordExceptionModel:model];

Niestandardowe ramki stosu można też inicjować jedynie za pomocą adresów:

Swift

var  ex = ExceptionModel.init(name:"FooException", reason:"There was a foo.")
ex.stackTrace = [
  StackFrame(address:0xfa12123),
  StackFrame(address:12412412),
  StackFrame(address:194129124),
]

crashlytics.record(exceptionModel:ex)

Objective-C

FIRExceptionModel *model =
    [FIRExceptionModel exceptionModelWithName:@"FooException" reason:@"There was a foo."];
model.stackTrace = @[
  [FIRStackFrame stackFrameWithAddress:0xfa12123],
  [FIRStackFrame stackFrameWithAddress:12412412],
  [FIRStackFrame stackFrameWithAddress:194129124],
];


[[FIRCrashlytics crashlytics] recordExceptionModel:model];

Pobierz logi menu nawigacyjnego

Logi menu nawigacyjnego pozwalają lepiej poznać interakcje użytkownika do których doprowadziło do awarii, błędu niekrytycznego lub błędu ANR. Takie logi mogą może być pomocna przy odtworzeniu i debugowaniu problemu.

Logi menu nawigacyjnego są generowane przez Google Analytics, więc aby je uzyskać, musisz Trzeba włącz Google Analytics. dla projektu Firebase dodaj pakiet SDK Firebase dla Google Analytics do Twojej aplikacji. Po spełnieniu tych wymagań logi menu nawigacyjnego są automatycznie tworzone dołączany do danych zdarzenia na karcie Logi podczas wyświetlania szczegółów zdarzenia. danego problemu.

Pakiet SDK Analytics automatycznie rejestruje zdarzenie screen_view który pozwala w dziennikach menu nawigacyjnego wyświetlać listę ekranów wyświetlonych przed awarii, niekrytycznego ani błędu ANR. Log menu nawigacyjnego screen_view zawiera element firebase_screen_class.

W logach menu nawigacyjnego znajdują się też: niestandardowych zdarzeń rejestrowanych ręcznie na , w tym dane parametrów zdarzenia. Te dane pomagają wyświetlić serię działań użytkownika, które doprowadziły do awarii, błędów niekrytycznych lub błędów ANR.

Pamiętaj, że możesz jak kontrolować zbieranie i wykorzystywanie danych Google Analytics, który zawiera dane umieszczane w dziennikach menu nawigacyjnego.

Włącz raportowanie akceptacji

Domyślnie Crashlytics automatycznie zbiera raporty o awariach dotyczące użytkowników aplikacji. Aby zapewnić użytkownikom większą kontrolę nad danymi, które wysyłają, możesz włączyć raportów, na które należy się włączyć, wyłączając automatyczne raportowanie i wysyłając dane tylko do Jeśli w kodzie wybierzesz opcję Crashlytics:

1. Wyłącz automatyczne zbieranie danych, dodając nowy klucz do pliku Info.plist:

   • Klucz: FirebaseCrashlyticsCollectionEnabled
   • Wartość: false

2. Włącz zbieranie danych dla wybranych użytkowników, wywołując dane Crashlytics zastępowania kolekcji w czasie działania. Wartość zastąpienia będzie widoczna przez uruchomienia aplikacji, aby Crashlytics mogła automatycznie zbierać raporty.

   Aby zrezygnować z automatycznego zgłaszania awarii, podaj wartość false jako wartość zastąpienia. Jeśli ustawisz wartość false, nowa wartość nie będzie stosowana do czasu następnego uruchomienia polecenia .

   Swift

   Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)

   Objective-C

   [[FIRCrashlytics crashlytics] setCrashlyticsCollectionEnabled:YES];

Uwaga: gdy zbieranie danych jest wyłączone, Crashlytics zapisuje informacje o awariach. informacje lokalne na urządzeniu. Jeśli następnie włączysz zbieranie danych, wszystkie informacje o awariach przechowywane na urządzeniu będą wysyłane do Crashlytics przez przetwarzania danych.

Zarządzanie danymi analizy awarii

Statystyki awarii pomagają rozwiązywać problemy, porównując Twój zanonimizowany stos umożliwia śledzenie logów innych aplikacji Firebase i informację, czy problem jest jako część większego trendu. W przypadku wielu problemów Analiza awarii zapewnia nawet zasoby aby pomóc Ci w debugowaniu awarii.

Statystyki awarii wykorzystują zbiorcze dane o awariach, aby identyfikować typowe trendy dotyczące stabilności. Jeśli nie chcesz udostępniać danych o aplikacji, możesz zrezygnować ze Statystyk awarii w menu Statystyki awarii u góry listy problemów w Crashlytics w konsoli Firebase.

Uwaga: wyłączenie udostępniania danych powoduje też usunięcie statystyk dotyczących problemów. Zmiany mogą mogą minąć 24 godziny, zanim zaczną obowiązywać.