Diese Seite bietet Hilfe zur Fehlerbehebung und Antworten auf häufig gestellte Fragen zur Verwendung von Crashlytics. Wenn Sie das Gesuchte nicht finden oder zusätzliche Hilfe benötigen, wenden Sie sich an den Firebase-Support .
Allgemeine Fehlerbehebung/FAQ
Möglicherweise bemerken Sie zwei unterschiedliche Formate für Probleme, die in Ihrer Problemtabelle in der Firebase-Konsole aufgeführt sind. Und vielleicht fällt Ihnen in einigen Ihrer Ausgaben auch eine Funktion namens „Varianten“ auf. Hier ist der Grund!
Anfang 2023 haben wir eine verbesserte Analyse-Engine zum Gruppieren von Ereignissen sowie ein aktualisiertes Design und einige erweiterte Funktionen für neue Probleme (wie Varianten!) eingeführt. Schauen Sie sich unseren aktuellen Blog-Beitrag für alle Details an, aber Sie können unten die Highlights lesen.
Crashlytics analysiert alle Ereignisse Ihrer App (wie Abstürze, nicht tödliche Unfälle und ANRs) und erstellt Gruppen von Ereignissen, die als Probleme bezeichnet werden – alle Ereignisse in einem Problem haben eine gemeinsame Fehlerquelle.
Um Ereignisse in diese Probleme einzuteilen, untersucht die verbesserte Analyse-Engine nun viele Aspekte des Ereignisses, einschließlich der Frames im Stack-Trace, der Ausnahmemeldung, des Fehlercodes und anderer Plattform- oder Fehlertypmerkmale.
Innerhalb dieser Ereignisgruppe können die Stack-Traces, die zum Fehler führen, jedoch unterschiedlich sein. Ein anderer Stack-Trace könnte eine andere Grundursache bedeuten. Um diesen möglichen Unterschied innerhalb eines Problems darzustellen, erstellen wir jetzt Varianten innerhalb von Problemen – jede Variante ist eine Untergruppe von Ereignissen in einem Problem, die denselben Fehlerpunkt und einen ähnlichen Stack-Trace aufweisen. Mit Varianten können Sie die häufigsten Stack-Traces innerhalb eines Problems debuggen und feststellen, ob verschiedene Grundursachen zum Fehler führen.
Folgendes werden Sie mit diesen Verbesserungen erleben:
Überarbeitete Metadaten werden in der Problemzeile angezeigt
Es ist jetzt einfacher, Probleme in Ihrer App zu verstehen und zu selektieren.Weniger doppelte Probleme
Eine Änderung der Zeilennummer führt nicht zu einem neuen Problem.Einfacheres Debuggen komplexer Probleme mit verschiedenen Grundursachen
Verwenden Sie Varianten, um die häufigsten Stack-Traces innerhalb eines Problems zu debuggen.Aussagekräftigere Warnungen und Signale
Ein neues Problem stellt tatsächlich einen neuen Fehler dar.Leistungsstärkere Suche
Jedes Problem enthält weitere durchsuchbare Metadaten, z. B. Ausnahmetyp und Paketname.
So werden diese Verbesserungen umgesetzt:
Wenn wir neue Ereignisse von Ihrer App erhalten, prüfen wir, ob sie mit einem bestehenden Problem übereinstimmen.
Wenn es keine Übereinstimmung gibt, wenden wir automatisch unseren intelligenteren Ereignisgruppierungsalgorithmus auf das Ereignis an und erstellen ein neues Problem mit dem überarbeiteten Metadatendesign.
Dies ist das erste große Update, das wir an unserer Event-Gruppierung vornehmen. Wenn Sie Feedback haben oder auf Probleme stoßen, teilen Sie uns dies bitte mit, indem Sie einen Bericht einreichen.
Wenn Sie keine absturzfreien Metriken (z. B. absturzfreie Benutzer und Sitzungen) und/oder Geschwindigkeitswarnungen sehen, stellen Sie sicher, dass Sie dasCrashlytics SDK 11.7.0+.
Wenn Sie keine Breadcrumb-Protokolle sehen, empfehlen wir Ihnen, die Konfiguration Ihrer App für Google Analytics zu überprüfen. Stellen Sie sicher, dass Sie die folgenden Anforderungen erfüllen:
Sie haben Google Analytics in Ihrem Firebase-Projekt aktiviert .
Sie haben die Datenfreigabe für Google Analytics aktiviert. Weitere Informationen zu dieser Einstellung finden Sie unter Verwalten Ihrer Analytics-Datenfreigabeeinstellungen
Sie habendas Firebase SDK für Google Analyticszu Ihrer App hinzugefügt. Dieses SDK muss zusätzlich zum Crashlytics SDK hinzugefügt werden.
Sie verwenden dieneuesten Firebase SDK-Versionenfür alle Produkte, die Sie in Ihrer App verwenden.
Wenn Sie Unity IL2CPP verwenden und nicht symbolisierte Stack-Traces sehen, versuchen Sie Folgendes:
Stellen Sie sicher, dass Sie Version 8.6.1 oder höher des Crashlytics Unity SDK verwenden.
Stellen Sie sicher, dass Sie für den Firebase-CLI-
crashlytics:symbols:uploadeingerichtet sind und ihn ausführen, um Ihre Symboldatei zu generieren und hochzuladen.Sie müssen diesen CLI-Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen Build erstellen, für den Sie symbolisierte Stack-Traces in der Firebase-Konsole sehen möchten. Weitere Informationen finden Sie auf der Seite „Lesbare Absturzberichte erhalten“ .
Ja, Crashlytics kann symbolisierte Stack-Traces für Ihre Apps anzeigen, die IL2CPP verwenden. Diese Funktion ist für Apps verfügbar, die entweder auf Android- oder Apple-Plattformen veröffentlicht wurden. Folgendes müssen Sie tun:
Stellen Sie sicher, dass Sie Version 8.6.0 oder höher des Crashlytics Unity SDK verwenden.
Führen Sie die erforderlichen Aufgaben für Ihre Plattform aus:
Für Apple-Plattform-Apps : Es sind keine besonderen Maßnahmen erforderlich. Für Apple-Plattform-Apps konfiguriert das Firebase Unity Editor-Plugin Ihr Xcode-Projekt automatisch zum Hochladen von Symbolen.
Für Android-Apps : Stellen Sie sicher, dass Sie für den Firebase-CLI-
crashlytics:symbols:uploadeingerichtet sind und ihn ausführen, um Ihre Symboldatei zu generieren und hochzuladen.Sie müssen diesen CLI-Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen Build erstellen, für den Sie symbolisierte Stack-Traces in der Firebase-Konsole sehen möchten. Weitere Informationen finden Sie auf der Seite „Lesbare Absturzberichte erhalten“ .
Der Wert „Absturzfrei“ stellt den Prozentsatz der Benutzer dar, die mit Ihrer App interagiert haben, aber über einen bestimmten Zeitraum hinweg keinen Absturz hatten.
Hier ist die Formel zur Berechnung des Prozentsatzes absturzfreier Benutzer. Die Eingabewerte werden von Google Analytics bereitgestellt.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Wenn ein Absturz auftritt, sendet Google Analytics einen Ereignistyp
app_exceptionund CRASHED_USERS stellt die Anzahl der Benutzer dar, die diesem Ereignistyp zugeordnet sind.ALL_USERS stellt die Gesamtzahl der Benutzer dar, die über den Zeitraum, den Sie aus dem Dropdown-Menü oben rechts im Crashlytics-Dashboard ausgewählt haben, mit Ihrer App interagiert haben.
Der Prozentsatz absturzfreier Benutzer ist eine Aggregation im Zeitverlauf und kein Durchschnitt.
Stellen Sie sich zum Beispiel vor, Ihre App hat drei Benutzer; Wir nennen sie Benutzer A, Benutzer B und Benutzer C. Die folgende Tabelle zeigt, welche Benutzer jeden Tag mit Ihrer App interagierten und welcher dieser Benutzer an diesem Tag einen Absturz hatte:
| Montag | Dienstag | Mittwoch | |
|---|---|---|---|
| Benutzer, die mit Ihrer App interagiert haben | A, B, C | A, B, C | A, B |
| Benutzer, der einen Absturz hatte | C | B | A |
Am Mittwoch liegt Ihr Prozentsatz absturzfreier Benutzer bei 50 % (1 von 2 Benutzern war absturzfrei).
Zwei Ihrer Benutzer haben am Mittwoch mit Ihrer App interagiert, aber nur einer von ihnen (Benutzer B) hatte keine Abstürze.Für die letzten 2 Tage beträgt Ihr Prozentsatz absturzfreier Benutzer 33,3 % (1 von 3 Benutzern war absturzfrei).
Drei Ihrer Benutzer haben in den letzten zwei Tagen mit Ihrer App interagiert, aber nur einer von ihnen (Benutzer C) hatte keine Abstürze.In den letzten 3 Tagen lag der Prozentsatz Ihrer absturzfreien Benutzer bei 0 % (0 von 3 Benutzern waren absturzfrei).
Drei Ihrer Benutzer haben in den letzten drei Tagen mit Ihrer App interagiert, aber keiner von ihnen hatte keine Abstürze.
Der Wert für absturzfreie Benutzer sollte nicht über verschiedene Zeiträume hinweg verglichen werden. Die Wahrscheinlichkeit, dass ein einzelner Benutzer einen Absturz erleidet, steigt, je öfter er Ihre App verwendet, sodass der Wert für absturzfreie Benutzer über längere Zeiträume wahrscheinlich geringer ist.
Mithilfe von Notizen können Projektmitglieder bestimmte Probleme mit Fragen, Statusaktualisierungen usw. kommentieren.
Wenn ein Projektmitglied eine Notiz postet, wird diese mit der E-Mail-Adresse seines Google-Kontos gekennzeichnet. Diese E-Mail-Adresse ist zusammen mit der Notiz für alle Projektmitglieder sichtbar, die Zugriff auf die Notiz haben.
Im Folgenden wird der Zugriff beschrieben, der zum Anzeigen, Schreiben und Löschen von Notizen erforderlich ist:
Projektmitglieder mit einer der folgenden Rollen können vorhandene Notizen anzeigen und löschen sowie neue Notizen zu einem Problem schreiben.
- Projektinhaber oder -editor , Firebase-Administrator , Qualitätsadministrator oder Crashlytics-Administrator
Projektmitglieder mit einer der folgenden Rollen können die zu einem Problem veröffentlichten Notizen anzeigen, aber sie können keine Notizen löschen oder schreiben.
- Projekt- Viewer , Firebase-Viewer , Qualitäts-Viewer oder Crashlytics-Viewer
Siehe Absturzfreie Metriken verstehen .
Mithilfe von Notizen können Projektmitglieder bestimmte Probleme mit Fragen, Statusaktualisierungen usw. kommentieren.
Wenn ein Projektmitglied eine Notiz postet, wird diese mit der E-Mail-Adresse seines Google-Kontos gekennzeichnet. Diese E-Mail-Adresse ist zusammen mit der Notiz für alle Projektmitglieder sichtbar, die Zugriff auf die Notiz haben.
Im Folgenden wird der Zugriff beschrieben, der zum Anzeigen, Schreiben und Löschen von Notizen erforderlich ist:
Projektmitglieder mit einer der folgenden Rollen können vorhandene Notizen anzeigen und löschen sowie neue Notizen zu einem Problem schreiben.
- Projektinhaber oder -editor , Firebase-Administrator , Qualitätsadministrator oder Crashlytics-Administrator
Projektmitglieder mit einer der folgenden Rollen können die zu einem Problem veröffentlichten Notizen anzeigen, aber sie können keine Notizen löschen oder schreiben.
- Projekt- Viewer , Firebase-Viewer , Qualitäts-Viewer oder Crashlytics-Viewer
Integrationen
Wenn Ihr Projekt Crashlytics zusammen mit dem Google Mobile Ads SDK verwendet, ist es wahrscheinlich, dass die Crash-Reporter bei der Registrierung von Ausnahmehandlern stören. Um das Problem zu beheben, deaktivieren Sie die Absturzberichte im Mobile Ads SDK, indem Sie disableSDKCrashReporting aufrufen.
Nachdem Sie Crashlytics mit BigQuery verknüpft haben, werden neue Datensätze, die Sie erstellen, automatisch in den Vereinigten Staaten gespeichert, unabhängig vom Standort Ihres Firebase-Projekts.
Regressierte Probleme
Bei einem Problem ist ein Rückgang aufgetreten, wenn Sie das Problem zuvor geschlossen haben, Crashlytics jedoch einen neuen Bericht erhält, dass das Problem erneut aufgetreten ist. Crashlytics öffnet diese zurückgegangenen Probleme automatisch erneut, sodass Sie sie entsprechend Ihrer App beheben können.
Hier ist ein Beispielszenario, das erklärt, wie Crashlytics ein Problem als Regression kategorisiert:
- Zum ersten Mal überhaupt erhält Crashlytics einen Absturzbericht über Absturz „A“. Crashlytics öffnet ein entsprechendes Problem für diesen Absturz (Problem „A“).
- Sie beheben diesen Fehler schnell, schließen Problem „A“ und veröffentlichen dann eine neue Version Ihrer App.
- Crashlytics erhält einen weiteren Bericht zu Problem „A“, nachdem Sie das Problem geschlossen haben.
- Wenn der Bericht von einer App-Version stammt, von der Crashlytics wusste, als Sie das Problem geschlossen haben (was bedeutet, dass die Version überhaupt einen Absturzbericht für einen Absturz gesendet hat), betrachtet Crashlytics das Problem nicht als rückläufig. Das Problem bleibt geschlossen.
- Wenn der Bericht von einer App-Version stammt, von der Crashlytics beim Schließen des Problems nichts wusste (was bedeutet, dass die Version überhaupt keinen Absturzbericht für einen Absturz gesendet hat), betrachtet Crashlytics das Problem als rückläufig und öffnet das Problem erneut .
Wenn sich ein Problem zurückbildet, senden wir eine Regressionserkennungswarnung und fügen dem Problem ein Regressionssignal hinzu, um Sie darüber zu informieren, dass Crashlytics das Problem erneut geöffnet hat. Wenn Sie nicht möchten, dass ein Problem aufgrund unseres Regressionsalgorithmus erneut geöffnet wird, schalten Sie das Problem „stumm“, anstatt es zu schließen.
Wenn ein Bericht von einer alten App-Version stammt, die zum Zeitpunkt des Schließens des Problems überhaupt keine Absturzberichte gesendet hat, geht Crashlytics davon aus, dass das Problem zurückgegangen ist, und öffnet das Problem erneut.
Diese Situation kann in der folgenden Situation auftreten: Sie haben einen Fehler behoben und eine neue Version Ihrer App veröffentlicht, haben aber immer noch Benutzer mit älteren Versionen ohne die Fehlerbehebung. Wenn eine dieser älteren Versionen zufällig überhaupt keine Absturzberichte gesendet hätte, als Sie das Problem geschlossen haben, und diese Benutzer auf den Fehler stoßen, würden diese Absturzberichte ein zurückgebildetes Problem auslösen.
Wenn Sie nicht möchten, dass ein Problem aufgrund unseres Regressionsalgorithmus erneut geöffnet wird, schalten Sie das Problem „stumm“, anstatt es zu schließen.
Nicht erfasste Ausnahmen werden als schwerwiegend gemeldet
Crashlytics kann nicht abgefangene Ausnahmen als schwerwiegende Ausnahmen melden (ab Version 10.4.0 des Unity SDK). Die folgenden FAQs helfen dabei, die Gründe und Best Practices für die Verwendung dieser Funktion zu erläutern.
Indem Sie nicht erfasste Ausnahmen als schwerwiegend melden, erhalten Sie einen realistischeren Hinweis darauf, welche Ausnahmen dazu führen können, dass das Spiel nicht mehr spielbar ist – selbst wenn die App weiterhin ausgeführt wird.
Beachten Sie, dass sich der Anteil absturzfreier Benutzer (CFU) wahrscheinlich verringert, wenn Sie beginnen, tödliche Unfälle zu melden, die CFU-Metrik jedoch repräsentativer für die Erfahrungen der Endbenutzer mit Ihrer App ist.
Damit Crashlytics eine nicht abgefangene Ausnahme als schwerwiegend melden kann, müssen die beiden folgenden Bedingungen erfüllt sein:
Während der Initialisierung in Ihrer App muss die Eigenschaft
ReportUncaughtExceptionsAsFatalauftruefestgelegt werden .Ihre App (oder eine enthaltene Bibliothek) löst eine Ausnahme aus, die nicht abgefangen wird. Eine Ausnahme, die erstellt, aber nicht ausgelöst wird , gilt nicht als nicht abgefangen.
Wenn Sie Berichte über Ihre nicht abgefangenen Ausnahmen als schwerwiegende Ausnahmen erhalten, finden Sie hier einige Optionen für den Umgang mit diesen nicht abgefangenen Ausnahmen:
- Überlegen Sie, wie Sie diese nicht erfassten Ausnahmen abfangen und behandeln können.
- Erwägen Sie verschiedene Optionen zum Protokollieren von Ausnahmen in der Unity-Debug-Konsole und in Crashlytics.
Ausgelöste Ausnahmen abfangen und behandeln
Ausnahmen werden erstellt und ausgelöst, um unerwartete oder außergewöhnliche Zustände widerzuspiegeln. Um die durch eine ausgelöste Ausnahme verursachten Probleme zu lösen, muss das Programm in einen bekannten Zustand zurückversetzt werden (ein Prozess, der als Ausnahmebehandlung bezeichnet wird).
Es empfiehlt sich, alle vorgesehenen Ausnahmen abzufangen und zu behandeln, es sei denn, das Programm kann nicht in einen bekannten Zustand zurückversetzt werden.
Um zu steuern, welche Arten von Ausnahmen von welchem Code abgefangen und behandelt werden, schließen Sie Code, der eine Ausnahme generieren könnte, in einen try-catch Block ein . Stellen Sie sicher, dass die Bedingungen in den catch Anweisungen so eng wie möglich sind, um die spezifischen Ausnahmen angemessen zu behandeln.
Protokollieren Sie Ausnahmen in Unity oder Crashlytics
Es gibt mehrere Möglichkeiten, Ausnahmen in Unity oder Crashlytics aufzuzeichnen, um das Problem zu beheben.
Bei der Verwendung von Crashlytics sind hier die beiden häufigsten und empfohlenen Optionen:
Option 1: Drucken Sie in der Unity-Konsole, aber melden Sie sich während der Entwicklung oder Fehlerbehebung nicht an Crashlytics
- Drucken Sie auf der Unity-Konsole mit
Debug.Log(exception),Debug.LogWarning(exception)undDebug.LogError(exception), die den Inhalt der Ausnahme auf der Unity-Konsole ausgeben und die Ausnahme nicht erneut auslösen.
- Drucken Sie auf der Unity-Konsole mit
Option 2: Hochladen auf Crashlytics für konsolidierte Berichte im Crashlytics-Dashboard für die folgenden Situationen:
- Wenn es sich lohnt, eine Ausnahme zu protokollieren, um ein mögliches nachfolgendes Crashlytics-Ereignis zu debuggen, verwenden Sie
Crashlytics.Log(exception.ToString()). - Wenn eine Ausnahme trotz Abfangen und Behandeln weiterhin an Crashlytics gemeldet werden soll, verwenden Sie
Crashlytics.LogException(exception), um sie als nicht schwerwiegendes Ereignis zu protokollieren.
- Wenn es sich lohnt, eine Ausnahme zu protokollieren, um ein mögliches nachfolgendes Crashlytics-Ereignis zu debuggen, verwenden Sie
Wenn Sie jedoch ein schwerwiegendes Ereignis manuell an Unity Cloud Diagnostics melden möchten, können Sie Debug.LogException verwenden. Diese Option gibt die Ausnahme wie Option 1 an die Unity-Konsole aus, löst jedoch auch die Ausnahme aus (unabhängig davon, ob sie bereits ausgelöst oder abgefangen wurde). Es löst den Fehler nicht lokal aus. Dies bedeutet, dass selbst eine umgebende Debug.LogException(exception) mit try-catch Blöcken immer noch zu einer nicht abgefangenen Ausnahme führt.
Rufen Sie daher Debug.LogException genau dann auf, wenn Sie Folgendes tun möchten:
- Um die Ausnahme auf der Unity-Konsole zu drucken.
- Um die Ausnahme als schwerwiegendes Ereignis auf Crashlytics hochzuladen.
- Um die Ausnahme auszulösen, muss sie als nicht abgefangene Ausnahme behandelt und an Unity Cloud Diagnostics gemeldet werden.
Beachten Sie, dass Sie stattdessen Folgendes tun, wenn Sie eine abgefangene Ausnahme auf der Unity-Konsole drucken und als nicht schwerwiegendes Ereignis auf Crashlytics hochladen möchten:
try
{
methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
// Print the exception to the Unity console at the error level.
Debug.LogError(exception);
// Upload the exception to Crashlytics as a non-fatal event.
Crashlytics.LogException(exception); // not Debug.LogException
//
// Code that handles the exception
//
}