Performance Monitoring – Fehlerbehebung und FAQs

Protokollmeldungen für Leistungsereignisse aufrufen

1. Aktivieren Sie das Debug-Logging für Performance Monitoring zum Zeitpunkt des Builds, indem Sie der AndroidManifest.xml-Datei Ihrer App ein <meta-data>-Element hinzufügen. Beispiel:

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

2. Prüfen Sie die Protokollmeldungen auf Fehler.

3. Performance Monitoring taggt seine Protokollmeldungen mit FirebasePerformance. Mit der Logcat-Filterung können Sie sich mit dem folgenden Befehl speziell die Dauer der Traces und das Logging von HTTP/S-Netzwerkanfragen ansehen:

   adb logcat -s FirebasePerformance

4. Prüfen Sie, ob die folgenden Arten von Protokollen vorhanden sind, 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 Minuten dauern, bis die Daten im Dashboard aktualisiert werden.

Wenn in Ihrer App keine Leistungsereignisse protokolliert werden, lesen Sie die Tipps zur Fehlerbehebung.

Ich habe das SDK der App hinzugefügt, aber in der Console wird weiterhin angezeigt, dass ich das SDK hinzufügen soll.

Firebase kann erkennen, ob Sie Ihrer App das Performance Monitoring SDK hinzugefügt haben, wenn es Ereignisinformationen (z. B. App-Interaktionen) von Ihrer App empfängt. In der Regel wird innerhalb von 10 Minuten nach dem Starten Ihrer App im Dashboard „Leistung“ der Firebase-Konsole die Meldung „SDK erkannt“ angezeigt. Innerhalb von 30 Minuten werden dann die ersten verarbeiteten Daten im Dashboard angezeigt.

Wenn Sie Ihrer App vor mehr als 10 Minuten die neueste Version des SDKs hinzugefügt haben und immer noch keine Änderungen sehen, prüfen Sie die Protokollmeldungen, um sicherzustellen, dass Performance Monitoring Ereignisse protokolliert. Führen Sie die unten beschriebenen Schritte zur Fehlerbehebung aus, um eine Meldung zur verzögerten SDK-Erkennung zu beheben.

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

Performance Monitoring verarbeitet Leistungsereignisdaten, bevor sie im Dashboard „Leistung“ angezeigt werden.

Wenn mehr als 24 Stunden vergangen sind, seit die Meldung „SDK erkannt“ angezeigt wurde, und Sie immer noch keine Daten sehen, sehen Sie im Firebase-Status-Dashboard nach, ob es einen bekannten Ausfall gibt. Wenn kein Ausfall vorliegt, wenden Sie sich an den Firebase-Support.

In der App werden keine Leistungsereignisse protokolliert

Wenn keine Protokollmeldungen für Leistungsereignisse angezeigt werden, führen Sie die folgenden Schritte zur Fehlerbehebung aus:

1. So prüfen Sie die Konfiguration 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 Modul (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. Achten Sie darauf, dass das Plug-in nicht durch eines der folgenden Flags deaktiviert ist:

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

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

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

3. Performance Monitoring darf nicht zur Laufzeit deaktiviert sein.

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

Im Dashboard zur Leistungsüberwachung fehlen Bildschirm-Trace-Daten

Wenn für Bildschirm-Rendering-Spuren keine Daten vorhanden sind, versuchen Sie Folgendes:

1. Achten Sie darauf, dass Sie die neueste Version des Android SDK (Version 21.0.2) verwenden. Bildschirm-Rendering-Tracks sind nur mit Version 15.2.0 oder höher verfügbar.

2. Die Hardwarebeschleunigung darf nicht manuell für ein Display deaktiviert worden sein.

3. DexGuard oder Jack dürfen nicht verwendet werden. Performance Monitoring ist mit diesen Toolchains nicht kompatibel.

   • DexGuard deaktiviert die automatische Erfassung von App-Start-, App-im-Vordergrund- und App-im-Hintergrund-Spuren. Spuren benutzerdefinierten Codes sollten sich jedoch normal verhalten, wenn Ihre App DexGuard verwendet.

   • Jack wurde eingestellt und sollte in der Regel nicht in Ihrer App verwendet werden.

Im Dashboard zur Leistungsüberwachung fehlen benutzerdefinierte Trace-Daten

Werden für Sie Leistungsdaten für automatisch erfasste Traces angezeigt, aber nicht für Traces mit benutzerdefiniertem Code? Führen Sie die folgenden Schritte zur Fehlerbehebung aus:

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

   • Namen für benutzerdefinierte Code-Traces und benutzerdefinierte Messwerte müssen die folgenden Anforderungen erfüllen: keine anführenden oder nachgestellten Leerzeichen, kein anführendes Unterstrichzeichen (_) und eine maximale Länge von 32 Zeichen.
   • Alle Traces müssen gestartet und beendet werden. Alle Protokolle, die nicht gestartet, nicht angehalten oder vor dem Start angehalten 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 Modul (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. Achten Sie darauf, dass das Plug-in nicht durch eines der folgenden Flags deaktiviert ist:

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

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

4. Wenn Performance Monitoring Ereignisse aufzeichnet, nach 24 Stunden aber 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 eine 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 Modul (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. Achten Sie darauf, dass das Plug-in nicht durch eines der folgenden Flags deaktiviert ist:

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

2. Prüfen Sie, ob die Netzwerkbibliothek nicht kompatibel 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 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 Netzwerkanfragen erfasst, die abgeschlossen wurden. Das bedeutet, dass HTTP/S-Verbindungen, die offen bleiben, möglicherweise nicht gemeldet werden.

   • Performance Monitoring ist nicht mit DexGuard und Jack kompatibel.

     • DexGuard deaktiviert die Überwachung von HTTP/S-Netzwerkanfragen.
     • Jack wurde eingestellt und sollte in der Regel nicht in Ihrer App verwendet werden.

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

Netzwerkanfragedaten werden nicht wie erwartet zusammengefasst

Weitere Informationen dazu, wie Performance Monitoring Daten zu Netzwerkanfragen nach URL-Mustern aggregiert

Du kannst auch benutzerdefinierte URL-Muster ausprobieren.

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

Wir haben Häufigste Probleme durch Letzte Benachrichtigungen ersetzt. Dies ist eine Folge der Einführung von Benachrichtigungen, die Sie automatisch informieren, wenn die von Ihnen festgelegten Grenzwerte überschritten werden. Probleme werden eingestellt und durch Benachrichtigungen ersetzt.

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

Weitere Informationen zu Benachrichtigungen finden Sie unter Benachrichtigungen für Leistungsprobleme einrichten.

Wo ist die Möglichkeit geblieben, Grenzwerte für Probleme in der Konsole festzulegen?

Performance Monitoring unterstützt Benachrichtigungen für Messwerte, die festgelegte Schwellenwerte überschreiten. Um Verwechslungen 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 Details und Messwerten in der Firebase-Konsole passiert?

Wir haben die Seiten „Details“ und „Messwerte“ durch eine neu gestaltete, zentrale Benutzeroberfläche ersetzt, damit Sie Probleme noch besser beheben können. Diese neue Benutzeroberfläche für die Fehlerbehebung bietet dieselben grundlegenden Funktionen wie „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 Nutzergeräten Ihrer App. Wenn Ihre Anwendung viele Nutzer hat oder die App eine große Menge an Leistungsaktivitäten generiert, kann Performance Monitoring die Datenerhebung auf eine Teilmenge der Geräte beschränken, um die Anzahl der verarbeiteten Ereignisse zu reduzieren. Diese Limits sind so hoch, dass die Messwerte auch bei weniger Ereignissen repräsentativ für die App-Nutzung Ihrer Nutzer sind.

Um das Volumen der erhobenen Daten zu verwalten, verwendet Performance Monitoring die folgenden Stichprobenerhebungsoptionen:

• Taktbeschränkung auf dem Gerät: Um zu verhindern, dass ein Gerät plötzlich viele Traces sendet, beschränken 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 Schleifeninstrumentierungen, die große Mengen an Leistungsdaten senden können, und verhindert, dass ein einzelnes Gerät die Leistungsmessungen verfälscht.

• Dynamische Stichprobenerhebung: Performance Monitoring erfasst täglich eine begrenzte Anzahl von Code- und Netzwerkanfrage-Traces pro App für alle App-Nutzer. Eine dynamische Stichprobenrate wird auf Geräten (mit Firebase Remote Config) abgerufen, um zu ermitteln, ob ein zufälliges Gerät Traces erfassen und senden soll. Von Geräten, die nicht für die Stichprobenerhebung ausgewählt wurden, werden keine Ereignisse gesendet. Die dynamische Stichprobenrate ist app-spezifisch und wird so angepasst, dass das Gesamtvolumen der erfassten Daten unter dem Limit bleibt.

  Für Projekte, für die die BigQuery-Integration aktiviert ist, gilt 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 begrenzen.

• Serverseitige Ratenbegrenzung: Damit Apps das Stichprobenlimit nicht überschreiten, kann Performance Monitoring serverseitige Stichprobenerhebung verwenden, um einige von Geräten empfangene Ereignisse zu verwerfen. Diese Art der Begrenzung ändert zwar nicht die Effektivität unserer Messwerte, kann aber zu geringfügigen Musterverschiebungen führen, darunter:

  • Die Anzahl der Traces kann von der Häufigkeit abweichen, mit der ein Code ausgeführt wurde.
  • Traces, die im Code eng miteinander verbunden sind, können jeweils eine unterschiedliche Anzahl von Samples haben.

Was ist mit dem Tab Probleme in der Console passiert?

Der Tab „Probleme“ wurde durch den Tab „Benachrichtigungen“ ersetzt. Sie werden dort automatisch benachrichtigt, wenn die von Ihnen festgelegten Schwellenwerte überschritten werden. Sie müssen den Status eines Schwellenwerts nicht mehr manuell in der Firebase-Konsole prüfen. 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 mir die Spuren ansehen, die auf diesen Seiten vorhanden waren?

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

Die Tabelle mit den Aufzeichnungen 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, die Aufzeichnungen 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 Trace-Tabelle auf den Namen des Traces.

Sie können sich Ihre Traces in den folgenden Untertabs der Traces-Tabelle ansehen:

• Netzwerkanfrage-Traces (sowohl vordefinierte als auch benutzerdefinierte) – Untertab Netzwerkanfragen
• Traces mit benutzerdefiniertem Code – Untertab Benutzerdefinierte Traces
• App-Start, App im Vordergrund, App im Hintergrund – Untertab Benutzerdefinierte Traces
• Bildschirm-Rendering-Traces – Untertab Bildschirm-Rendering
• Seitenaufbau-Traces – Untertab Seitenaufbau

Weitere Informationen zur Tabelle mit den Traces sowie zu den Messwerten und Daten finden Sie auf der Übersichtsseite der Console (iOS und höher | Android | Web).

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

Frames mit langsamem Rendering und eingefrorene Frames werden mit einer angenommenen Geräteaktualisierungsrate von 60 Hz berechnet. Wenn die Bildwiederholrate eines Geräts unter 60 Hz liegt, dauert das Rendern jedes Frames länger, da weniger Frames pro Sekunde gerendert werden. Längere Renderingzeiten können dazu führen, dass mehr langsame oder eingefrorene Frames gemeldet werden, da mehr Frames langsamer gerendert werden oder einfrieren. Wenn die Bildwiederholrate eines Geräts jedoch über 60 Hz liegt, ist die Renderingzeit für jeden Frame kürzer. Dadurch werden möglicherweise weniger langsame oder eingefrorene Frames gemeldet. Das ist eine aktuelle Einschränkung des Performance Monitoring SDK.

Warum sehe ich keine Fragmente?

Wenn Sie neben den App-Aktivitäten auch die Leistung von Fragmenten sehen möchten, muss in Ihrer App das Performance Monitoring Android SDK in Version 20.1.0 oder höher verwendet werden. Weitere Informationen finden Sie unter Leistungsüberwachung zur App hinzufügen.

Wie finde ich heraus, welche Traces mit Fragmenten und Aktivitäten in Verbindung stehen?

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

Warum sehe ich weniger Fragmente als bei anderen Traces?

Bei Performance Monitoring wird eine Stichprobenerhebung für alle auf einem Gerät erfassten Ereignisse durchgeführt. So können wir die Mindestanzahl an Ereignissen von Nutzergeräten erfassen, die für die Bereitstellung von Leistungsmesswerten erforderlich sind.

Wie werde ich benachrichtigt, wenn ein Problem mit der Renderingleistung meiner Anwendung vorliegt?

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

Die Build-Zeiten sind hoch, nachdem ich das Performance Monitoring Gradle-Plug-in aktiviert habe. Wie kann ich das verbessern?

Performance Monitoring für Android verwendet 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 Abhängigkeiten) durchlaufen werden, um den Code zu instrumentieren, der für die Messung der Netzwerkanfrageleistung Ihrer Anwendung entscheidend ist.

Hier sind einige der wichtigsten Faktoren, die zu einer längeren Buildzeit führen:

• Anzahl der Kurse oder Dateien
• Größe der einzelnen Klassen (Codezeilen)
• Ihre Maschinenkonfiguration
• Erster Build im Vergleich zu einem nachfolgenden Build (nachfolgende Builds sind in der Regel schneller als der erste Build)

Um die Buildzeit zu optimieren, sollten Sie Ihren Code modularisieren.

Ab der Version 1.3.3 des Performance Monitoring-Plug-ins haben wir uns darauf konzentriert, die Verarbeitung inkrementeller Builds und das Caching von Bibliotheksinputs erheblich zu verbessern. Wenn Sie die neuesten Verbesserungen bei der Buildzeit nutzen möchten, verwenden Sie die neueste Version des Plug-ins (Version 1.4.2).

Wenn Sie lange Build-Zeiten vermeiden möchten, können Sie das Performance Monitoring-Plug-in für Ihre Debug-Builds lokal deaktivieren. Dieser Ansatz wird jedoch für Produktionsbuilds nicht empfohlen, da dies zu fehlenden Leistungsmessungen für die Netzwerkanfragen in Ihrer App führen kann.

Was kann ich tun, wenn ich Buildfehler aufgrund von nicht kompatiblen Bibliotheken mit dem Performance Monitoring Gradle-Plug-in erhalte?

Performance Monitoring für Android verwendet 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 Abhängigkeiten) durchlaufen werden, um den Code zu instrumentieren, der für die Messung der Netzwerkanfrageleistung Ihrer Anwendung entscheidend ist.

Wenn nach der Einbindung des Performance Monitoring-Plug-ins Buildfehler wie JSR/RET are not supported with computeFrames option oder ähnliche Fehler auftreten, kann das daran liegen, dass Sie auch eine Abhängigkeit von einer Bibliothek haben, die nicht mit dem Performance Monitoring-Gradle-Plug-in kompatibel ist.

Sie können dieses Problem umgehen, indem 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 Version 7.2.0 oder höher.
3. Fügen Sie der build.gradle-Datei des Moduls (auf Anwendungsebene) das folgende Flag hinzu, um die nicht kompatiblen Klassen/Bibliotheken von der Instrumentierung auszuschließen:

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

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

Bitte melden Sie ein GitHub-Problem, wenn Sie Buildfehler aufgrund von inkompatiblen Bibliotheken erhalten, damit diese auch von der Instrumentierung im Performance Monitoring-Plug-in ausgeschlossen werden können.

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

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

Die Daten für den 19. April sind beispielsweise am 20. April zwischen 12:00 Uhr und Mitternacht in BigQuery verfügbar. Alle Datumsangaben und Uhrzeiten beziehen sich auf die Pacific Time-Zeitzone.

Was bedeutet „nahezu in Echtzeit“ bei Leistungsdaten?

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

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

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

Wenn Sie die Echtzeitverarbeitung nutzen möchten, müssen Sie nur darauf achten, dass Ihre App eine Performance Monitoring SDK-Version verwendet, die mit der Echtzeitverarbeitung kompatibel ist.

Das sind die echtzeitkompatiblen SDK-Versionen:

• iOS: Version 7.3.0 oder höher
• tvOS – Version 8.9.0 oder höher
• Android: Version 19.0.10 oder höher (oder Firebase Android BoM Version 26.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 gelten als echtzeitkompatibel?

Folgende SDK-Versionen sind mit der Echtzeitdatenverarbeitung kompatibel:

• iOS: Version 7.3.0 oder höher
• tvOS – Version 8.9.0 oder höher
• Android: Version 19.0.10 oder höher (oder Firebase Android BoM Version 26.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 der Echtzeitfunktion kompatible SDK-Version aktualisiere?

Wenn Ihre App keine Echtzeit-kompatible SDK-Version verwendet, sehen Sie in der Firebase-Konsole weiterhin alle Leistungsdaten Ihrer App. Die Leistungsdaten werden jedoch erst etwa 36 Stunden nach der Erhebung angezeigt.

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

Sehr gut. Unabhängig davon, welche SDK-Version eine App-Instanz verwendet, sehen Sie Leistungsdaten aller Ihrer Nutzer.

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