Performance Monitoring – Fehlerbehebung und FAQs

Log-Nachrichten für Leistungsereignisse ansehen

1. Aktivieren Sie das Debug-Logging für Performance Monitoring zur Build-Zeit, indem Sie der AndroidManifest.xml-Datei Ihrer App ein <meta-data>-Element hinzufügen:

   <application>
       <meta-data
         android:name="firebase_performance_logcat_enabled"
         android:value="true" />
   </application>

2. Prüfen Sie Ihre Logmeldungen auf Fehlermeldungen.

3. Performance Monitoring kennzeichnet seine Logmeldungen mit FirebasePerformance. Mit der logcat-Filterung können Sie sich mit dem folgenden Befehl speziell die Dauer-Traces und das HTTP/S-Netzwerkanfrage-Logging ansehen:

   adb logcat -s FirebasePerformance

4. Suchen Sie nach den folgenden Arten von Logs, die darauf hinweisen, dass Performance Monitoring Leistungsereignisse protokolliert:

   • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
   • Logging network request trace: URL

5. Klicken Sie auf die URL, um Ihre Daten in der Firebase Console aufzurufen. Es kann einige Momente dauern, bis die Daten im Dashboard aktualisiert werden.

Wenn in Ihrer App keine Leistungsereignisse protokolliert werden, finden Sie hier Tipps zur Fehlerbehebung.

Das SDK wurde der App hinzugefügt, aber in der Console wird weiterhin angezeigt, dass das SDK hinzugefügt werden muss.

Firebase kann erkennen, ob Sie das Performance Monitoring SDK erfolgreich in Ihre App eingebunden haben, wenn Ereignisinformationen (z. B. App-Interaktionen) von Ihrer App empfangen werden. In der Regel wird innerhalb von 10 Minuten nach dem Start Ihrer App im Performance-Dashboard der Firebase-Konsole die Meldung „SDK erkannt“ angezeigt. Innerhalb von 30 Minuten werden dann die ersten verarbeiteten Daten im Dashboard angezeigt.

Wenn seit dem Hinzufügen der neuesten SDK-Version zu Ihrer App mehr als 10 Minuten vergangen sind und Sie immer noch keine Änderung sehen, prüfen Sie Ihre Logmeldungen, um sicherzustellen, dass Performance Monitoring Ereignisse protokolliert. Führen Sie die entsprechenden Schritte zur Fehlerbehebung aus, um eine verzögerte SDK-Erkennung zu beheben.

In der Console wird angezeigt, dass das SDK erkannt wurde, aber es werden keine Daten angezeigt.

Performance Monitoring verarbeitet Leistungsereignisdaten, bevor sie im Dashboard zur Leistungsüberwachung angezeigt werden.

Wenn seit dem Erscheinen der Meldung „SDK erkannt“ mehr als 24 Stunden vergangen sind und Sie immer noch keine Daten sehen, prüfen Sie das Firebase-Status-Dashboard auf bekannte Ausfälle. Wenn kein Ausfall vorliegt, wenden Sie sich an den Firebase-Support.

Die App protokolliert keine Leistungsereignisse.

Wenn Sie keine Log-Nachrichten für Leistungsereignisse sehen, führen Sie die folgenden Schritte zur Fehlerbehebung aus:

1. Prüfen Sie die Einrichtung des Performance Monitoring-Gradle-Plug-ins:

   1. Prüfen Sie, ob Sie das Plug-in richtig hinzugefügt haben. Prüfen Sie insbesondere Folgendes:

      • Sie haben das Plug-in (apply plugin: 'com.google.firebase.firebase-perf') in der Datei build.gradle Ihres Moduls (auf App-Ebene) hinzugefügt.
      • Sie haben die Classpath-Abhängigkeit für das Plug-in (classpath 'com.google.firebase:perf-plugin:1.4.2') in die Datei build.gradle auf Projektebene aufgenommen.

   2. Prüfen Sie, ob das Plug-in durch eines der folgenden Flags deaktiviert wurde:

      • instrumentationEnabled in der Datei build.gradle auf Modulebene (App-Ebene)
      • firebasePerformanceInstrumentationEnabled in Ihrer gradle.properties-Datei

2. Prüfen Sie, ob das Performance Monitoring SDK in der Datei AndroidManifest.xml durch eines der folgenden Flags nicht deaktiviert ist:

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

3. Achten Sie darauf, dass Performance Monitoring zur Laufzeit nicht deaktiviert ist.

4. Wenn Sie in Ihrer App nichts finden, das deaktiviert wurde, wenden Sie sich an den Firebase-Support.

Im Dashboard zur Leistungsüberwachung fehlen Daten zu Bildschirm-Traces

Wenn Daten für die Bildschirmrendering-Traces fehlen, führen Sie die folgenden Schritte zur Fehlerbehebung aus:

1. Achten Sie darauf, dass Sie die aktuelle Version des Android SDK (v21.0.5) verwenden. Traces für das Rendern von Bildschirmen sind erst ab Version 15.2.0 verfügbar.

2. Prüfen Sie, ob Sie die Hardwarebeschleunigung für einen Bildschirm manuell deaktiviert haben.

3. Vergewissern Sie sich, dass Sie weder DexGuard noch Jack verwenden. Performance Monitoring ist nicht mit diesen Toolchains kompatibel.

   • DexGuard deaktiviert die automatische Erfassung von Traces für App-Start, App im Vordergrund und App im Hintergrund. Benutzerdefinierte Code-Traces sollten sich jedoch normal verhalten, wenn Ihre App DexGuard verwendet.

   • Jack ist veraltet und sollte in Ihrer App im Allgemeinen nicht verwendet werden.

Im Dashboard zur Leistungsüberwachung fehlen benutzerdefinierte Trace-Daten

Sehen Sie Leistungsdaten für automatisch erfasste Traces, aber nicht für benutzerdefinierte Code-Traces? Führen Sie die folgenden Schritte zur Fehlerbehebung durch:

1. Wenn Sie benutzerdefinierte Code-Traces über die Trace API instrumentiert haben, prüfen Sie die Einrichtung der Traces, insbesondere die folgenden Punkte:

   • Namen für benutzerdefinierte Code-Traces und benutzerdefinierte Messwerte müssen die folgenden Anforderungen erfüllen: keine Leerzeichen am Anfang oder Ende, kein Unterstrich (_) am Anfang und eine maximale Länge von 32 Zeichen.
   • Alle Traces müssen gestartet und beendet werden. Traces, die nicht gestartet, nicht beendet oder vor dem Start beendet wurden, werden nicht protokolliert.

2. Wenn Sie benutzerdefinierte Code-Traces über die @AddTrace-Notation instrumentiert haben, prüfen Sie die Einrichtung des Performance Monitoring-Gradle-Plug-ins:

   1. Prüfen Sie, ob Sie das Plug-in richtig hinzugefügt haben. Prüfen Sie insbesondere Folgendes:

      • Sie haben das Plug-in (apply plugin: 'com.google.firebase.firebase-perf') in der Datei build.gradle Ihres Moduls (auf App-Ebene) hinzugefügt.
      • Sie haben die Classpath-Abhängigkeit für das Plug-in (classpath 'com.google.firebase:perf-plugin:1.4.2') in die Datei build.gradle auf Projektebene aufgenommen.

   2. Prüfen Sie, ob das Plug-in durch eines der folgenden Flags deaktiviert wurde:

      • instrumentationEnabled in der Datei build.gradle auf Modulebene (App-Ebene)
      • firebasePerformanceInstrumentationEnabled in Ihrer gradle.properties-Datei

3. Prüfen Sie Ihre Log-Nachrichten, um sicherzustellen, dass Performance Monitoring die erwarteten benutzerdefinierten Code-Traces protokolliert.

4. Wenn Performance Monitoring Ereignisse protokolliert, aber nach 24 Stunden keine Daten angezeigt werden, wenden Sie sich an den Firebase-Support.

Im Dashboard zur Leistungsüberwachung fehlen Daten zu Netzwerkanfragen

Wenn Daten zu Netzwerkanfragen fehlen, führen Sie die folgenden Schritte zur Fehlerbehebung aus:

1. Für Android-Apps ermöglicht das Performance Monitoring-Gradle-Plug-in die Instrumentierung, die automatische Überwachung von HTTP/S-Netzwerkanfragen ermöglicht. Dann machen Sie Folgendes:

   1. Prüfen Sie, ob Sie das Plug-in richtig hinzugefügt haben. Prüfen Sie insbesondere Folgendes:

      • Sie haben das Plug-in (apply plugin: 'com.google.firebase.firebase-perf') in der Datei build.gradle Ihres Moduls (auf App-Ebene) hinzugefügt.
      • Sie haben die Classpath-Abhängigkeit für das Plug-in (classpath 'com.google.firebase:perf-plugin:1.4.2') in die Datei build.gradle auf Projektebene aufgenommen.

   2. Prüfen Sie, ob das Plug-in durch eines der folgenden Flags deaktiviert wurde:

      • instrumentationEnabled in der Datei build.gradle auf Modulebene (App-Ebene)
      • firebasePerformanceInstrumentationEnabled in Ihrer gradle.properties-Datei

2. Prüfen Sie, ob die Netzwerkbibliothek inkompatibel ist. Performance Monitoring erfasst automatisch Messwerte für Netzwerkanfragen, die die folgenden Netzwerkbibliotheken verwenden: OkHttp 3.x.x, URLConnection von Java und Apache HttpClient.

   Sie können auch benutzerdefiniertes Monitoring für Netzwerkanfragen hinzufügen.

3. Beachten Sie Folgendes:

   • Je nach Verhalten Ihres Codes und der von Ihrem Code verwendeten Netzwerkbibliotheken werden in Performance Monitoring möglicherweise nur abgeschlossene Netzwerkanfragen erfasst. Das bedeutet, dass offene HTTP/S-Verbindungen möglicherweise nicht gemeldet werden.

   • Performance Monitoring ist nicht mit DexGuard und Jack kompatibel.

     • DexGuard deaktiviert die Überwachung von HTTP/S-Netzwerkanfragen.
     • Jack ist veraltet und sollte in Ihrer App im Allgemeinen nicht verwendet werden.

   • In Performance Monitoring werden keine Netzwerkanfragen mit ungültigen Content-Type-Headern erfasst. Netzwerkanfragen ohne die Content-Type-Header werden jedoch weiterhin akzeptiert.

Daten zu Netzwerkanfragen werden nicht wie erwartet zusammengefasst

Weitere Informationen dazu, wie Performance Monitoring Daten zu Netzwerkanfragen anhand von URL-Mustern zusammenfasst

Sie können auch benutzerdefinierte URL-Muster ausprobieren.

Was ist mit den wichtigsten Problemen auf der Karte „Leistung“ auf der Projektstartseite passiert?

Wir haben Top-Probleme durch Letzte Benachrichtigungen ersetzt. Das ist eine Folge der Einführung von Benachrichtigungen, die Sie automatisch informieren, wenn die von Ihnen festgelegten Grenzwerte überschritten werden. Probleme werden nicht mehr unterstützt und durch Benachrichtigungen ersetzt.

Mit der App-Auswahl oben auf der Karte „Leistung“ werden die Benachrichtigungseinträge unter Letzte Benachrichtigungen gefiltert. Es werden nur die drei letzten Warnungen für die ausgewählten Apps angezeigt.

Weitere Informationen zu Benachrichtigungen

Was ist mit der Möglichkeit passiert, Grenzwerte für Probleme in der Konsole festzulegen?

Performance Monitoring unterstützt Benachrichtigungen für Messwerte, die definierte Schwellenwerte überschreiten. Um Verwirrung mit diesen konfigurierbaren Grenzwerten für Leistungsmesswerte zu vermeiden, haben wir die Möglichkeit entfernt, Grenzwerte für Probleme zu konfigurieren.

Was ist mit den Informationen unter „Details“ und „Messwerte“ in der Firebase-Konsole passiert?

Wir haben die Seiten „Details“ und „Messwerte“ durch eine neu gestaltete, zentrale Benutzeroberfläche ersetzt, um die Fehlerbehebung zu vereinfachen. Diese neue Benutzeroberfläche zur Fehlerbehebung bietet dieselben Kernfunktionen wie die bisherigen Bereiche „Details“ und „Messwerte“. Weitere Informationen zur Fehlerbehebung finden Sie unter Weitere Daten für einen bestimmten Trace ansehen.

Warum entspricht die Anzahl der Stichproben nicht meinen Erwartungen?

Performance Monitoring erhebt Leistungsdaten von den Geräten der Nutzer Ihrer App. Wenn Ihre Anwendung viele Nutzer hat oder eine große Menge an Leistungsaktivitäten generiert, kann Performance Monitoring die Datenerhebung auf eine Teilmenge von Geräten beschränken, um die Anzahl der verarbeiteten Ereignisse zu reduzieren. Diese Grenzwerte sind hoch genug, damit die Messwerte auch bei weniger Ereignissen repräsentativ für die App-Nutzung durch Ihre Nutzer sind.

Um die Menge der von uns erhobenen Daten zu verwalten, verwendet Performance Monitoring die folgenden Optionen für die Stichprobenerhebung:

• Ratenbegrenzung auf dem Gerät: Damit ein Gerät nicht plötzlich eine große Anzahl von Traces sendet, begrenzen wir die Anzahl der Code- und Netzwerkanfrage-Traces, die von einem Gerät gesendet werden, auf 300 Ereignisse alle 10 Minuten. Dieser Ansatz schützt das Gerät vor wiederholten Instrumentierungen, die große Mengen an Leistungsdaten senden können, und verhindert, dass ein einzelnes Gerät die Leistungsmessungen verfälscht.

• Dynamisches Sampling: Performance Monitoring erfasst täglich eine begrenzte Anzahl von Code- und Netzwerk-Anfrage-Traces pro App für alle App-Nutzer. Auf Geräten wird eine dynamische Samplingrate abgerufen (mit Firebase Remote Config), um zu ermitteln, ob ein zufälliges Gerät Traces erfassen und senden soll. Ein Gerät, das nicht für die Stichprobenerhebung ausgewählt ist, sendet keine Ereignisse. Die dynamische Stichprobenrate ist app-spezifisch und wird so angepasst, dass das Gesamtvolumen der erhobenen Daten unter dem Limit bleibt.

  Projekte, für die die BigQuery-Integration aktiviert ist, erhalten ein höheres Limit für die Anzahl der Netzwerkanfrage-Traces.

  Bei Nutzersitzungen werden zusätzliche, detaillierte Daten vom Gerät eines Nutzers gesendet. Das Erfassen und Senden der Daten erfordert mehr Ressourcen. Um die Auswirkungen von Nutzersitzungen zu minimieren, kann Performance Monitoring auch die Anzahl der Sitzungen einschränken.

• Serverseitige Ratenbegrenzung: Damit Apps das Stichprobenlimit nicht überschreiten, kann Performance Monitoring serverseitige Stichproben verwenden, um einige von Geräten empfangene Ereignisse zu verwerfen. Diese Art der Einschränkung ändert zwar nicht die Effektivität unserer Messwerte, kann aber zu geringfügigen Musteränderungen führen, z. B.:

  • Die Anzahl der Traces kann sich von der Anzahl der Ausführungen eines Codeabschnitts unterscheiden.
  • Traces, die im Code eng miteinander verbunden sind, können jeweils eine unterschiedliche Anzahl von Stichproben haben.

Was ist mit dem Tab Probleme in der Console passiert?

Wir haben den Tab „Probleme“ durch Benachrichtigungen ersetzt. Sie werden automatisch benachrichtigt, wenn die von Ihnen festgelegten Grenzwerte überschritten werden. Sie müssen die Firebase-Konsole nicht mehr manuell prüfen, um den Status eines Schwellenwerts zu ermitteln. Weitere Informationen zu Benachrichtigungen finden Sie unter Benachrichtigungen für Leistungsprobleme einrichten.

Was ist mit den Tabs Auf dem Gerät und Netzwerk in der Console passiert? Wie kann ich die Traces auf diesen Seiten ansehen?

Wir haben den Bereich Performance Monitoring der Firebase-Konsole neu gestaltet, sodass auf dem Tab Dashboard Ihre wichtigsten Messwerte und alle Ihre Traces an einem Ort angezeigt werden. Im Rahmen der Neugestaltung haben wir die Seiten Auf dem Gerät und Netzwerk entfernt.

Die Tabelle mit den Traces unten auf dem Tab Dashboard enthält dieselben Informationen wie die Tabs Auf dem Gerät und Netzwerk, bietet aber einige zusätzliche Funktionen, z. B. die Möglichkeit, Traces nach der prozentualen Änderung für einen bestimmten Messwert zu sortieren. Wenn Sie alle Messwerte und Daten für einen bestimmten Trace aufrufen möchten, klicken Sie in der Tracetabelle auf den Tracenamen.

Sie können sich Ihre Traces auf den folgenden Untertabs der Tracetabelle ansehen:

• Netzwerkanfrage-Traces (sowohl sofort einsatzbereit als auch benutzerdefiniert) – Untertab Netzwerkanfragen
• Traces mit benutzerdefiniertem Code – Untertab Benutzerdefinierte Traces
• Traces für App-Start, App im Vordergrund und App im Hintergrund – Untertab Benutzerdefinierte Traces
• Bildschirm-Rendering-Traces – Untertab Bildschirm-Rendering
• Seitenaufbau-Traces – Untertab Seitenaufbau

Weitere Informationen zur Tabelle „Traces“ und zum Ansehen von Messwerten und Daten finden Sie auf der Übersichtsseite der Console (iOS+ | Android | Web).

Warum entspricht die Anzahl der langsamen und eingefrorenen Frames nicht meinen Erwartungen?

Langsame Rendering-Frames und eingefrorene Frames werden mit einer angenommenen Aktualisierungsrate des Geräts von 60 Hz berechnet. Wenn die Aktualisierungsrate eines Geräts niedriger als 60 Hz ist, hat jeder Frame eine längere Renderingzeit, da weniger Frames pro Sekunde gerendert werden. Längere Rendering-Zeiten können dazu führen, dass mehr langsame oder eingefrorene Frames gemeldet werden, da mehr Frames langsamer gerendert werden oder einfrieren. Wenn die Aktualisierungsrate eines Geräts jedoch höher als 60 Hz ist, wird jeder Frame schneller gerendert. Dadurch werden möglicherweise weniger langsame oder eingefrorene Frames gemeldet. Das ist eine aktuelle Einschränkung im Performance Monitoring SDK.

Warum kann ich keine Fragment-Traces sehen?

Wenn Sie die Leistung von Fragmenten zusätzlich zur App-Aktivität sehen möchten, muss Ihre App das Performance Monitoring Android SDK in Version 20.1.0 oder höher verwenden. Weitere Informationen finden Sie unter Performance Monitoring zur App hinzufügen.

Wie kann ich nachvollziehen, welche Traces mit Fragmenten und Aktivitäten zusammenhängen?

Jeder Fragment- und Aktivitätstrace basiert auf dem Klassennamen, der in Ihrer Anwendung definiert ist. Jeder der Bildschirm-Traces enthält das Präfix st, gefolgt vom Namen der Klasse. In der Firebase Console wird das Präfix entfernt. Weitere Informationen zu Leistungsdaten für das Bildschirm-Rendering (Apple- und Android-Apps)

Warum sehe ich weniger Fragment-Traces als andere Traces?

Bei Performance Monitoring wird das Event-Sampling für alle auf einem Gerät erfassten Ereignisse durchgeführt. So können wir die Mindestanzahl an Ereignissen erfassen, die von Nutzergeräten benötigt werden, um Leistungsmesswerte zu liefern.

Wie werde ich benachrichtigt, wenn es ein Problem mit der Rendering-Leistung meiner Anwendung gibt?

Mit Performance Monitoring können Sie Benachrichtigungen für die Messwerte einrichten, die für Sie wichtig sind. Für generierte Screen-Rendering-Traces können Sie Benachrichtigungen einrichten, um benachrichtigt zu werden, wenn der Prozentsatz der langsamen und eingefrorenen Frames einen von Ihnen festgelegten Grenzwert überschreitet.

Meine Build-Zeiten sind nach der Aktivierung des Performance Monitoring-Gradle-Plug-ins lang. Wie kann ich das verbessern?

Performance Monitoring für Android verwendet die Bytecode-Instrumentierung, um einige sofort einsatzbereite Funktionen wie die Überwachung von HTTP/S-Netzwerkanfragen bereitzustellen. Im Rahmen der Kompilierung müssen alle Klassen Ihrer App (einschließlich der Abhängigkeiten) durchlaufen werden, um den Code zu instrumentieren, der für die Messung der Leistung von Netzwerkanfragen Ihrer Anwendung entscheidend ist.

Hier sind einige der wichtigsten Faktoren, die zu einer längeren Build-Zeit führen können:

• Anzahl der Klassen oder Dateien
• Größe jeder dieser Klassen (Zeilen mit Code)
• Ihre Maschinenkonfiguration
• Erster Build im Vergleich zu einem nachfolgenden Build (nachfolgende Builds sind in der Regel schneller als der erste Build)

Um die Build-Zeit zu optimieren, sollten Sie Ihren Code modularisieren.

Ab Version 1.3.3 des Performance Monitoring-Plug-ins haben wir uns darauf konzentriert, die Verarbeitung inkrementeller Builds und das Caching von Bibliothekseingaben erheblich zu verbessern. Damit Sie die neuesten Verbesserungen bei der Build-Zeit nutzen können, müssen Sie die aktuelle Version des Plugins (v1.4.2) verwenden.

Sie können das Performance Monitoring-Plug-in für Ihre Debug-Builds lokal deaktivieren, um lange Build-Zeiten zu vermeiden. Dieser Ansatz wird jedoch für Produktions-Builds nicht empfohlen, da er dazu führen kann, dass Leistungsmessungen für die Netzwerkanfragen in Ihrer App fehlen.

Was kann ich tun, wenn ich Build-Fehler aufgrund inkompatibler Bibliotheken mit dem Performance Monitoring-Gradle-Plugin erhalte?

Performance Monitoring für Android verwendet die Bytecode-Instrumentierung, um einige sofort einsatzbereite Funktionen wie die Überwachung von HTTP/S-Netzwerkanfragen bereitzustellen. Im Rahmen der Kompilierung müssen alle Klassen Ihrer App (einschließlich der Abhängigkeiten) durchlaufen werden, um den Code zu instrumentieren, der für die Messung der Leistung von Netzwerkanfragen Ihrer Anwendung entscheidend ist.

Wenn nach der Integration des Performance Monitoring-Plug-ins Build-Fehler wie JSR/RET are not supported with computeFrames option oder ähnliche Fehler auftreten, liegt das möglicherweise daran, dass Sie auch eine Abhängigkeit von einer Bibliothek haben, die mit dem Performance Monitoring-Gradle-Plug-in inkompatibel ist.

Um dieses Problem zu umgehen, können Sie inkompatible Klassen/Bibliotheken von der Instrumentierung ausschließen. Gehen Sie dazu so vor:

1. Aktualisieren Sie das Performance Monitoring-Gradle-Plug-in auf die neueste Version (mindestens v1.4.0).
2. Aktualisieren Sie die Version des Android-Gradle-Plug-ins auf v7.2.0 oder höher.
3. Fügen Sie der Datei build.gradle auf Modulebene (auf Anwendungsebene) das folgende Flag hinzu, um die Inkompatibilitäten auszuschließen:

   android {
     // ...
     androidComponents {
       onVariants(selector().all(), {
           instrumentation.excludes.add("example.incompatible.library")
       })
     }
   }

   Weitere Informationen zur exclude-Eigenschaft der Instrumentation-API des Android-Gradle-Plug-ins finden Sie unter Instrumentation.

Wenn Sie aufgrund inkompatibler Bibliotheken auf Build-Fehler stoßen, erstellen Sie bitte ein GitHub-Problem, damit diese Bibliotheken auch aus der Instrumentierung im Performance Monitoring-Plug-in ausgeschlossen werden können.

Der Export meiner Performance Monitoring-Daten nach BigQuery dauert länger als erwartet. Werden die Daten nicht in Echtzeit aktualisiert?

Wenn Sie die BigQuery-Integration für Firebase Performance Monitoring aktiviert haben, werden Ihre Daten 12 bis 24 Stunden nach Tagesende (Pazifische Zeit) nach BigQuery exportiert.

Die Daten für den 19. April sind beispielsweise am 20. April zwischen 12:00 Uhr und Mitternacht (alle Datums- und Zeitangaben sind in pazifischer Zeit) in BigQuery verfügbar.

Was bedeutet „Leistungsdaten nahezu in Echtzeit“?

Firebase Performance Monitoring verarbeitet die erfassten Leistungsdaten, sobald sie eingehen. Dadurch werden die Daten in der Firebase-Konsole nahezu in Echtzeit angezeigt. Verarbeitete Daten werden innerhalb weniger Minuten nach der Erfassung in der Console angezeigt. Daher der Begriff „nahezu in Echtzeit“.

Damit Sie die Datenverarbeitung nahezu in Echtzeit nutzen können, muss Ihre App eine SDK-Version verwenden, die mit Echtzeit kompatibel ist.

Wie erhalte ich Leistungsdaten für meine App nahezu in Echtzeit?

Damit Sie die Verarbeitung von Daten in Echtzeit nutzen können, müssen Sie nur darauf achten, dass Ihre App eine Performance Monitoring-SDK-Version verwendet, die mit der Verarbeitung von Daten in Echtzeit kompatibel ist.

Das sind die echtzeitkompatiblen SDK-Versionen:

• iOS: Version 7.3.0 oder höher
• tvOS: v8.9.0 oder höher
• Android: v19.0.10 oder höher (oder Firebase Android BoM v26.1.0 oder höher)
• Web: Version 7.14.0 oder höher

Wir empfehlen immer, die neueste SDK-Version zu verwenden. Mit jeder der oben aufgeführten Versionen kann Performance Monitoring Ihre Daten jedoch nahezu in Echtzeit verarbeiten.

Welche Versionen des Performance Monitoring SDK sind echtzeitkompatibel?

Dies sind die SDK-Versionen, die mit der Echtzeitdatenverarbeitung kompatibel sind:

• iOS: Version 7.3.0 oder höher
• tvOS: v8.9.0 oder höher
• Android: v19.0.10 oder höher (oder Firebase Android BoM v26.1.0 oder höher)
• Web: Version 7.14.0 oder höher

Wir empfehlen immer, die neueste SDK-Version zu verwenden. Mit jeder der oben aufgeführten Versionen kann Performance Monitoring Ihre Daten jedoch nahezu in Echtzeit verarbeiten.

Was passiert, wenn ich meine App nicht auf eine mit Echtzeit kompatible SDK-Version aktualisiere?

Wenn Ihre App keine mit Echtzeit kompatible SDK-Version verwendet, sehen Sie trotzdem alle Leistungsdaten Ihrer App in der Firebase-Konsole. Die Anzeige der Leistungsdaten verzögert sich jedoch um etwa 36 Stunden ab dem Zeitpunkt der Erhebung.

Ich habe ein Upgrade auf eine echtzeitkompatible SDK-Version durchgeführt, aber einige meiner Nutzer verwenden immer noch alte Versionen meiner App. Werden ihre Leistungsdaten weiterhin in der Firebase-Konsole angezeigt?

Sehr gut. Unabhängig davon, welche SDK-Version in einer App-Instanz verwendet wird, sehen Sie Leistungsdaten von allen Ihren Nutzern.

Wenn Sie sich jedoch aktuelle Daten ansehen (die weniger als etwa 36 Stunden alt sind), stammen die angezeigten Daten von Nutzern von App-Instanzen, die eine echtzeitkompatible SDK-Version verwenden. Die nicht aktuellen Daten enthalten jedoch Leistungsdaten aus allen Versionen Ihrer App.