Dostosuj raporty o awariach Firebase Crashlytics

W tym przewodniku opisano, jak dostosować raporty o awariach za pomocą pakietu Firebase Crashlytics SDK. Domyślnie Crashlytics automatycznie zbiera raporty o awariach dla wszystkich użytkowników swojej aplikacji (można wyłączyć automatyczne zgłaszanie awarii i umożliwiają raportowanie opt-in dla użytkowników zamiast). Crashlytics zapewnia cztery mechanizmy wylogowaniu z pudełka: niestandardowych klawiszy , niestandardowe dzienniki , identyfikatory użytkowników i złowione wyjątki .

Dodaj niestandardowe klucze

Klucze niestandardowe pomagają uzyskać konkretny stan aplikacji, który może doprowadzić do awarii. Z raportami o awariach możesz powiązać dowolne pary klucz/wartość, a następnie użyć kluczy niestandardowych do wyszukiwania i filtrowania raportów o awariach w konsoli Firebase.

  • W desce rozdzielczej Crashlytics można szukać problemów pasujących klucz niestandardowy.
  • Kiedy Oceniasz problem szczególny w konsoli, można przeglądać powiązane niestandardowe klucze dla każdego zdarzenia (Keys podkarty), a nawet filtrować zdarzenia według niestandardowych klawiszy (menu filtra na górze strony).

Użyj setCustomValue metody par klucz / wartość. Na przykład:

Szybki

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

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

Cel C

Przy ustalaniu liczby całkowite, wartości logicznych lub pływaków, skrzynka wartość jako @( 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 również zmodyfikować wartość istniejącego klucza, wywołując klucz i ustawiając go na inną wartość. Na przykład:

Szybki

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

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

Cel 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ść luzem za pomocą setCustomKeysAndValues metodę z NSDictionary jako jedyny parametr:

Szybki

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)

Cel 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 dziennika

Aby zapewnić sobie więcej kontekstu dla zdarzeń prowadzących do awarii, możesz dodać do swojej aplikacji niestandardowe dzienniki Crashlytics. Crashlytics współpracownicy dzienniki ze swoimi danymi zderzeniowych i wyświetla je na stronie Crashlytics z konsoli Firebase w zakładce logów.

Szybki

Zastosowanie log() lub log(format:, arguments:) do spraw pomocy punktowych. Jeśli chcesz uzyskać użyteczną wyjście z dziennika komunikatów, obiekt, który można przejść do log() musi być zgodne z CustomStringConvertible nieruchomości. log() zwraca opis nieruchomości można zdefiniować dla obiektu. Na przykład:

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

.log(format:, arguments:) formaty Wartości zwracane przez wywołanie getVaList() . Na przykład:

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

Aby uzyskać więcej informacji na temat korzystania z log() lub log(format:, arguments:) , odnoszą się do Crashlytics dokumentacji referencyjnej .

Cel C

Wykorzystanie log lub logWithFormat do spraw pomocy punktowych. Zauważ, że jeśli chcesz uzyskać użyteczną wyjście z dziennika komunikatów, obiekt, który można przejść do każdej metody musi zastąpić description własności instancji. Na 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];

Aby uzyskać więcej informacji na temat korzystania z log i logWithFormat , patrz Crashlytics dokumentacji referencyjnej .

Ustaw identyfikatory użytkowników

Aby zdiagnozować problem, często warto wiedzieć, u którego z użytkowników wystąpiła dana awaria. Crashlytics umożliwia anonimowe identyfikowanie użytkowników w raportach o awariach.

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

Szybki

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

Cel C

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

Jeśli kiedykolwiek będziesz musiał wyczyścić identyfikator użytkownika po jego ustawieniu, zresetuj wartość do pustego ciągu. Usunięcie identyfikatora użytkownika nie powoduje usunięcia istniejących rekordów Crashlytics. Jeśli chcesz usunąć rekordy powiązane z identyfikatorem użytkownika, kontaktów wsparcia Firebase .

Zgłoś niekrytyczne wyjątki

Oprócz automatycznego zgłaszania awarii aplikacji Crashlytics umożliwia rejestrowanie niekrytycznych wyjątków i wysyłanie ich do Ciebie przy następnym uruchomieniu aplikacji.

Można nagrywać non-śmiertelnych wyjątki nagrywając NSError obiektów z recordError metody. recordError oddaje wątku stosu wywołań poprzez wywołanie [NSThread callStackReturnAddresses] .

Szybki

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

Cel C

[[FIRCrashlytics crashlytics] recordError:error];

Podczas korzystania z recordError sposób, ważne jest, aby zrozumieć NSError strukturę i jak Crashlytics wykorzystuje dane do awarii grupowych. Nieprawidłowe korzystanie z recordError metody może spowodować nieprzewidywalne zachowanie i może powodować Crashlytics do limitu sprawozdawczą zalogowanych błędów dla swojej aplikacji.

NSError obiekt ma trzy argumenty:

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

W przeciwieństwie do śmiertelnych wypadków, które pogrupowano poprzez analizy śladowej stos, rejestrowane błędy są pogrupowane według domain i code . Jest to ważne rozróżnienie między krytycznymi awariami a zarejestrowanymi błędami. Na przykład:

Szybki

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)

Cel 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];

Po zalogowaniu się błąd powyżej, tworzy nowy problem, który jest pogrupowany według NSSomeErrorDomain i -1001 . Dodatkowe zarejestrowane błędy, które używają tej samej domeny i wartości kodu, są pogrupowane w ramach tego samego problemu. Dane zawarte w userInfo obiektu są konwertowane do par klucz-wartość i wyświetlona w klawisze / loguje sekcję w ramach danej emisji.

Dzienniki i niestandardowe klucze

Podobnie jak zderzeniowych raportów, można osadzić dzienników i niestandardowe przyciski, aby dodać kontekst do NSError . Istnieje jednak różnica w tym, jakie dzienniki są dołączane do awarii, a jakie są rejestrowane błędy. Gdy nastąpi awaria i aplikacja zostanie ponownie uruchomiona, dzienniki pobierane przez Crashlytics z dysku to te, które zostały zapisane do momentu awarii. Po zalogowaniu się NSError , aplikacja nie natychmiast rozwiązać. Bo tylko Crashlytics wysyła zalogowany raport o błędzie na następnym uruchomieniu aplikacji i muszą ograniczyć ilość miejsca przeznaczonego na dzienniki na dysku, możliwe jest, aby zalogować się na tyle po przeprowadzeniu NSError są zapisywane tak, że wszystkie istotne dzienniki są obracane przez czas Crashlytics wysyła raport z urządzenia. Należy zachować tę równowagę w umyśle podczas logowania NSErrors i korzystania z dzienników i niestandardowe klucze w swojej aplikacji.

Rozważania dotyczące wydajności

Należy pamiętać, że zalogowaniu się NSError może być dość kosztowne. W momencie wywołania Crashlytics przechwytuje stos wywołań bieżącego wątku za pomocą procesu zwanego rozwijaniem stosu. Proces ten może intensywnie obciążać procesor i operacje we/wy, szczególnie w przypadku architektur obsługujących rozwijanie DWARF (arm64 i x86). Po zakończeniu rozwijania informacje są zapisywane na dysku synchronicznie. Zapobiega to utracie danych w przypadku awarii następnej linii.

Chociaż można bezpiecznie wywołać ten interfejs API w wątku w tle, należy pamiętać, że wysłanie tego wywołania do innej kolejki powoduje utratę kontekstu bieżącego śladu stosu.

A co z NSExceptions?

Crashlytics nie oferuje usługi na potrzeby rejestrowania i nagrywania NSException instancji bezpośrednio. Ogólnie rzecz biorąc, interfejsy API Cocoa i Cocoa Touch nie są bezpieczne. Oznacza to, że korzystanie z @catch może mieć bardzo poważne niezamierzonych skutków ubocznych w procesie, nawet kiedy jest stosowany ze szczególną ostrożnością. Nigdy nie należy używać @catch oświadczenia w kodzie. Proszę odnieść się do dokumentacji Apple na ten temat.

Włącz raportowanie zgody

Domyślnie Crashlytics automatycznie zbiera raporty o awariach dla wszystkich użytkowników Twojej aplikacji. Aby zapewnić użytkownikom większą kontrolę nad wysyłanymi przez nich danymi, możesz włączyć raportowanie, wyłączając automatyczne raportowanie i wysyłając dane do Crashlytics tylko wtedy, gdy zdecydujesz się w kodzie:

  1. Wyłączanie automatycznego zbierania dodając nowy klucz do Info.plist pliku:

    • Klucz: FirebaseCrashlyticsCollectionEnabled
    • Wartość: false
  2. Włącz zbieranie danych dla wybranych użytkowników, wywołując w czasie wykonywania funkcję zastępowania gromadzenia danych Crashlytics. Wartość zastąpienia utrzymuje się podczas uruchamiania aplikacji, dzięki czemu Crashlytics może automatycznie zbierać raporty.

    Aby zrezygnować z automatycznego zgłaszania awarii, przekaż false jako wartość override. Gdy ustawiony na false , nowa wartość nie stosuje się aż do następnego uruchomienia aplikacji.

    Szybki

    Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)
    

    Cel C

    [[FIRCrashlytics crashlytics] setCrashlyticsCollectionEnabled:YES];
    

Zarządzaj danymi Crash Insights

Crash Insights pomaga rozwiązywać problemy, porównując anonimowe ślady stosu ze śladami z innych aplikacji Firebase i informując, czy problem jest częścią większego trendu. W przypadku wielu problemów Crash Insights zapewnia nawet zasoby ułatwiające debugowanie awarii.

Crash Insights wykorzystuje zagregowane dane o awariach do identyfikowania typowych trendów stabilności. Gdyby wolisz nie udostępniać dane aplikacji, można zrezygnować z katastrofy Insights z menu zderzeniowe Insights na górze listy emisyjnej Crashlytics w konsoli Firebase .