Firebase Crashlytics-Absturzberichte anpassen

iOS+ Android Flutter Unity

Im Crashlytics-Dashboard können Sie auf ein Problem klicken, um einen detaillierten Ereignisbericht zu erhalten. Sie können diese Berichte anpassen, um besser nachvollziehen zu können, was in Ihrer App passiert und unter welchen Umständen Ereignisse an Crashlytics gemeldet werden.

• Instrumentieren Sie Ihre App, um benutzerdefinierte Schlüssel, benutzerdefinierte Log-Nachrichten und Nutzer-IDs zu protokollieren.

• Ausnahmen für Crashlytics melden

• Wenn Ihre App das Firebase SDK für Google Analytics verwendet, erhalten Sie automatisch Breadcrumb-Logs. Diese Logs geben Ihnen Einblick in Nutzeraktionen, die zu einem in Ihrer App erfassten Crashlytics-Ereignis führen.

• Deaktivieren Sie die automatische Absturzmeldung und aktivieren Sie die Opt-in-Berichterstellung für Ihre Nutzer. Standardmäßig werden in Crashlytics automatisch Absturzberichte für alle Nutzer Ihrer App erfasst.

Benutzerdefinierte Schlüssel hinzufügen

Mit benutzerdefinierten Schlüsseln können Sie den spezifischen Status Ihrer App abrufen, der zu einem Absturz führte. Sie können Ihren Absturzberichten beliebige Schlüssel/Wert-Paare zuordnen und dann die benutzerdefinierten Schlüssel verwenden, um in der Firebase-Konsole nach Absturzberichten zu suchen und sie zu filtern.

• Im Crashlytics-Dashboard können Sie nach Problemen suchen, die einem benutzerdefinierten Schlüssel entsprechen.
• Wenn Sie ein bestimmtes Problem in der Konsole untersuchen, können Sie die zugehörigen benutzerdefinierten Schlüssel für jedes Ereignis auf dem Tab Schlüssel ansehen und die Ereignisse sogar nach benutzerdefinierten Schlüsseln filtern (Menü Filter oben auf der Seite).

Hinweis :Crashlytics unterstützt maximal 64 Schlüssel/Wert-Paare. Nachdem Sie diesen Grenzwert erreicht haben, werden keine zusätzlichen Werte mehr gespeichert. Jedes Schlüssel/Wert-Paar kann bis zu 1 KB groß sein.

Mit der Methode setCustomValue können Sie Schlüssel/Wert-Paare festlegen. Beispiel:

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

Wenn Sie Ganzzahlen, boolesche Werte oder Gleitkommazahlen festlegen, setzen Sie den Wert in @(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"];

Sie können auch den Wert eines vorhandenen Schlüssels ändern, indem Sie den Schlüssel aufrufen und einen anderen Wert festlegen. Beispiel:

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

Fügen Sie Schlüssel/Wert-Paare im Bulk hinzu, indem Sie die Methode setCustomKeysAndValues mit einem NSDictionary als einzigem Parameter verwenden:

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

Benutzerdefinierte Logmeldungen hinzufügen

Um mehr Kontext zu den Ereignissen zu erhalten, die zu einem Absturz geführt haben, können Sie Ihrer App benutzerdefinierte Crashlytics-Logs hinzufügen. Crashlytics verknüpft die Logs mit Ihren Absturzdaten und zeigt sie auf der Seite Crashlytics der Firebase-Konsole auf dem Tab Logs an.

Hinweis :Damit Ihre App nicht langsamer wird, Crashlytics werden Logs auf 64 KB begrenzt und ältere Logeinträge gelöscht, wenn die Logs einer Sitzung dieses Limit überschreiten.

Swift

Verwenden Sie log() oder log(format:, arguments:), um Probleme einzugrenzen. Wenn Sie eine nützliche Protokollausgabe mit Nachrichten erhalten möchten, muss das Objekt, das Sie an log() übergeben, der Eigenschaft CustomStringConvertible entsprechen. log() gibt das Attribut „description“ zurück, das Sie für das Objekt definieren. Beispiel:

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

Mit .log(format:, arguments:) werden Werte formatiert, die durch den Aufruf von getVaList() zurückgegeben werden. Beispiel:

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

Weitere Informationen zur Verwendung von log() oder log(format:, arguments:) finden Sie in der Crashlytics-Referenzdokumentation.

Objective-C

Verwenden Sie log oder logWithFormat, um Probleme einzugrenzen. Wenn Sie eine nützliche Protokollausgabe mit Meldungen erhalten möchten, muss das Objekt, das Sie an eine der beiden Methoden übergeben, das Instanzattribut description überschreiben. Beispiel:

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

Weitere Informationen zur Verwendung von log und logWithFormat finden Sie in der Crashlytics-Referenzdokumentation.

Nutzerkennungen festlegen

Um ein Problem zu diagnostizieren, ist es oft hilfreich zu wissen, welche Ihrer Nutzer einen bestimmten Absturz erlebt haben. Crashlytics bietet eine Möglichkeit, Nutzer in Ihren Absturzberichten anonym zu identifizieren.

Wenn Sie Ihren Berichten User-IDs hinzufügen möchten, weisen Sie jedem Nutzer eine eindeutige Kennung in Form einer ID-Nummer, eines Tokens oder eines gehashten Werts zu:

Swift

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

Objective-C

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

Wenn Sie eine Nutzer-ID löschen müssen, nachdem Sie sie festgelegt haben, setzen Sie den Wert auf einen leeren String zurück. Wenn Sie eine Nutzerkennung löschen, werden vorhandene Crashlytics-Datensätze nicht entfernt. Wenn Sie Datensätze löschen müssen, die mit einer Nutzer-ID verknüpft sind, wenden Sie sich an den Firebase-Support.

Nicht schwerwiegende Ausnahmen melden

Zusätzlich zum automatischen Melden von App-Abstürzen können Sie mit Crashlytics nicht schwerwiegende Ausnahmen aufzeichnen und sie werden Ihnen beim nächsten Start Ihrer App gesendet.

Hinweis :Crashlytics speichert nur die letzten acht Ausnahmen in einer bestimmten App-Sitzung. Wenn Ihre App in einer Sitzung mehr als acht Ausnahmen auslöst, gehen ältere Ausnahmen verloren.

Sie können nicht schwerwiegende Ausnahmen aufzeichnen, indem Sie NSError-Objekte mit der Methode recordError aufzeichnen. recordError erfasst den Aufrufstack des Threads durch Aufrufen von [NSThread callStackReturnAddresses].

Swift

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

Objective-C

[[FIRCrashlytics crashlytics] recordError:error];

Wenn Sie die Methode recordError verwenden, ist es wichtig, die NSError-Struktur zu verstehen und zu wissen, wie Crashlytics die Daten verwendet, um Abstürze zu gruppieren. Eine falsche Verwendung der Methode recordError kann zu unvorhersehbarem Verhalten führen und dazu, dass Crashlytics die Berichterstellung für protokollierte Fehler für Ihre App einschränkt.

Ein NSError-Objekt hat drei Argumente:

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

Im Gegensatz zu schwerwiegenden Abstürzen, die über die Stacktrace-Analyse gruppiert werden, werden protokollierte Fehler nach domain und code gruppiert. Dies ist ein wichtiger Unterschied zwischen schwerwiegenden Abstürzen und protokollierten Fehlern. Beispiel:

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

Wenn Sie den oben genannten Fehler protokollieren, wird ein neues Problem erstellt, das nach NSSomeErrorDomain und -1001 gruppiert wird. Zusätzliche protokollierte Fehler, die dieselben Domain- und Code-Werte verwenden, werden unter demselben Problem gruppiert. Die Daten im userInfo-Objekt werden in Schlüssel/Wert-Paare konvertiert und im Abschnitt „Schlüssel/Logs“ eines einzelnen Problems angezeigt.

Achtung :Vermeiden Sie die Verwendung eindeutiger Werte wie Nutzer-ID, Produkt-ID und Zeitstempel in den Feldern „Domain“ und „Code“. Wenn Sie eindeutige Werte in diesen Feldern verwenden, führt dies zu einer hohen Kardinalität von Problemen und Crashlytics muss möglicherweise die Berichterstellung von protokollierten Fehlern in Ihrer App einschränken. Eindeutige Werte sollten stattdessen dem userInfo-Wörterbuchobjekt hinzugefügt werden.

Logs und benutzerdefinierte Schlüssel

Wie bei Absturzberichten können Sie Logs und benutzerdefinierte Schlüssel einbetten, um dem NSError Kontext hinzuzufügen. Es gibt jedoch einen Unterschied zwischen den Logs, die an Abstürze angehängt werden, und den Logs, die an protokollierte Fehler angehängt werden. Wenn ein Absturz auftritt und die App neu gestartet wird, ruft Crashlytics die Protokolle vom Datenträger ab, die bis zum Zeitpunkt des Absturzes geschrieben wurden. Wenn Sie einen NSError protokollieren, wird die App nicht sofort beendet. Da Crashlytics den protokollierten Fehlerbericht erst beim nächsten Start der App sendet und die Menge an Speicherplatz, die für Logs auf der Festplatte zugewiesen wird, begrenzt werden muss, ist es möglich, nach dem Aufzeichnen eines NSError genügend zu protokollieren, sodass alle relevanten Logs rotiert werden, bevor Crashlytics den Bericht vom Gerät sendet. Behalten Sie dieses Gleichgewicht im Hinterkopf, wenn Sie NSErrors protokollieren und Protokolle und benutzerdefinierte Schlüssel in Ihrer App verwenden.

Hinweise zur Leistung

Das Logging von NSError kann ziemlich teuer sein. Wenn Sie den Aufruf ausführen, erfasst Crashlytics den Aufrufstapel des aktuellen Threads mithilfe eines Prozesses namens „Stack Unwinding“. Dieser Prozess kann CPU- und E/A-intensiv sein, insbesondere bei Architekturen, die DWARF-Unwinding unterstützen (arm64 und x86). Nachdem das Unwind abgeschlossen ist, werden die Informationen synchron auf die Festplatte geschrieben. So wird Datenverlust verhindert, falls die nächste Zeile abstürzt.

Es ist zwar sicher, diese API in einem Hintergrundthread aufzurufen, aber wenn Sie diesen Aufruf an eine andere Warteschlange weiterleiten, geht der Kontext des aktuellen Stacktrace verloren.

Was ist mit NSExceptions?

Crashlytics bietet keine Möglichkeit, NSException-Instanzen direkt zu protokollieren und aufzuzeichnen. Im Allgemeinen sind die Cocoa- und Cocoa Touch-APIs nicht ausnahmesicher. Das bedeutet, dass die Verwendung von @catch sehr schwerwiegende unbeabsichtigte Nebenwirkungen in Ihrem Prozess haben kann, selbst wenn sie mit äußerster Sorgfalt erfolgt. Sie sollten @catch-Anweisungen niemals in Ihrem Code verwenden. Weitere Informationen finden Sie in der Dokumentation von Apple.

Stacktraces anpassen

Wenn Ihre App in einer nicht nativen Umgebung (z. B. C++ oder Unity) ausgeführt wird, können Sie mit der Exception Model API Absturzmetadaten im nativen Ausnahmeformat Ihrer App melden. Gemeldete Ausnahmen werden als nicht schwerwiegend markiert.

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

Benutzerdefinierte Stapelframes können auch nur mit Adressen initialisiert werden:

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

Navigationspfad-Logs abrufen

Navigationspfadlogs geben Ihnen einen besseren Einblick in die Interaktionen eines Nutzers mit Ihrer App, die zu einem Absturz‑, nicht schwerwiegenden oder ANR-Ereignis geführt haben. Diese Protokolle können hilfreich sein, wenn Sie versuchen, ein Problem zu reproduzieren und zu beheben.

Breadcrumb-Logs basieren auf Google Analytics. Damit Sie sie erhalten, müssen Sie Google Analytics für Ihr Firebase-Projekt aktivieren und das Firebase SDK für Google Analytics in Ihre App einfügen. Wenn diese Voraussetzungen erfüllt sind, werden Breadcrumb-Logs automatisch in die Daten eines Ereignisses auf dem Tab Logs aufgenommen, wenn Sie die Details eines Problems aufrufen.

Im Analytics SDK wird das screen_view-Ereignis automatisch protokolliert. Dadurch kann in den Navigationspfadlogs eine Liste der Bildschirme angezeigt werden, die vor dem Absturz‑, nicht schwerwiegenden oder ANR-Ereignis aufgerufen wurden. Ein screen_view-Breadcrumb-Log enthält einen firebase_screen_class-Parameter.

Breadcrumb-Logs werden auch mit allen benutzerdefinierten Ereignissen gefüllt, die Sie manuell in der Sitzung des Nutzers protokollieren, einschließlich der Parameterdaten des Ereignisses. Anhand dieser Daten lässt sich eine Reihe von Nutzeraktionen nachvollziehen, die zu einem Absturz‑, nicht schwerwiegenden oder ANR-Ereignis geführt haben.

Sie können die Erhebung und Verwendung von Google Analytics-Daten steuern, einschließlich der Daten, die in Breadcrumb-Logs enthalten sind.

Berichterstellung für die Einwilligung aktivieren

Wenn Sie die Einwilligungserklärung für Berichte aktivieren, indem Sie die automatische Berichterstellung deaktivieren, wird die Genauigkeit der Ereignisanzahl und der Messwerte zu Nutzern ohne Abstürze Ihrer App verringert. Dadurch wird die Gesamtstabilität Ihrer App weniger genau abgebildet.Weitere Informationen

Standardmäßig erfasst Crashlytics automatisch Absturzberichte für alle Nutzer Ihrer App. Um Nutzern mehr Kontrolle über die von ihnen gesendeten Daten zu geben, können Sie das Opt-in-Reporting aktivieren. Dazu deaktivieren Sie das automatische Reporting und senden Daten nur dann an Crashlytics, wenn Sie dies in Ihrem Code festlegen.

1. Sie können die automatische Erfassung deaktivieren, indem Sie Ihrer Info.plist-Datei einen neuen Schlüssel hinzufügen:

   • Schlüssel: FirebaseCrashlyticsCollectionEnabled
   • Wert: false

2. Aktivieren Sie die Erhebung für ausgewählte Nutzer, indem Sie den Crashlytics-Überschreibungsbefehl für die Datenerhebung zur Laufzeit aufrufen. Der Überschreibungswert bleibt bei allen nachfolgenden Starts Ihrer App erhalten, sodass Crashlytics automatisch Berichte für diesen Nutzer erfassen kann.

   Swift

   Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)

   Objective-C

   [[FIRCrashlytics crashlytics] setCrashlyticsCollectionEnabled:YES];

   Wenn der Nutzer die Datenerhebung später deaktiviert, können Sie false als Überschreibungswert übergeben. Dieser wird beim nächsten Start der App durch den Nutzer angewendet und bleibt bei allen nachfolgenden Starts für diesen Nutzer bestehen.

Hinweis :Wenn die Datenerhebung für einen Nutzer deaktiviert ist, speichert Crashlytics Absturzinformationen lokal auf dem Gerät. Wenn die Datenerfassung später aktiviert wird, werden alle auf dem Gerät gespeicherten Absturzinformationen zur Verarbeitung an Crashlytics gesendet.

Daten für Absturzinformationen verwalten

Mit Absturzinformationen können Sie Probleme beheben, indem Sie Ihre anonymisierten Stacktraces mit Traces aus anderen Firebase-Apps vergleichen und feststellen, ob Ihr Problem Teil eines größeren Trends ist. Bei vielen Problemen bietet Crash Insights sogar Ressourcen, die Ihnen bei der Fehlerbehebung helfen.

Crash Insights verwendet aggregierte Absturzdaten, um allgemeine Stabilitätstrends zu ermitteln. Wenn Sie die Daten Ihrer App nicht freigeben möchten, können Sie Crash Insights im Menü Crash Insights oben in der Crashlytics-Problemliste in der Firebase-Konsole deaktivieren.

Hinweis :Wenn Sie die Datenweitergabe deaktivieren, erhalten Sie auch keine Informationen zu den aufgetretenen Problemen mehr. Es kann bis zu 24 Stunden dauern, bis Änderungen wirksam werden.