Firebase Performance: Was es ist, Metriken und wie man sie verfolgt

Was ist Firebase Performance Monitoring

Firebase Performance Monitoring ist ein SDK und eine Cloud-Plattform zum Sammeln, Aggregieren und Visualisieren von Leistungskennzahlen mobiler Apps. Das SDK wird in die App eingebettet und instrumentiert automatisch wichtige Punkte: den Activity-Lebenszyklus (Android) oder ViewController (iOS), Netzwerkanfragen über URLSession (iOS) oder OkHttp (Android) und Systemaufrufe. Die gesammelten Daten werden an den Firebase-Server gesendet, wo sie nach App-Version, Gerät, Land und anderen Attributen aggregiert werden.

Die Architektur des Performance SDK basiert auf dem Prinzip des minimalen Overheads: Die Instrumentierung fügt nicht mehr als 1–2 % zur Ausführungszeit der gemessenen Operationen hinzu. Die Daten werden asynchron gesammelt und vor dem Senden auf dem Gerät zwischengepuffert, wodurch jegliche Auswirkungen auf die Leistung des UI-Threads ausgeschlossen werden. Die Daten werden nach einem Zeitplan (standardmäßig alle 30 Minuten) oder bei Erreichen des 100-KB-Puffers gesendet.

Der Hauptunterschied zwischen Firebase Performance und den Profilern von Android Studio (CPU Profiler) oder Xcode Instruments ist die Produktionsüberwachung. Firebase Performance sammelt Daten von echten Benutzergeräten, nicht nur von Entwicklergeräten. Dadurch können Probleme erkannt werden, die nur auf bestimmten Modellen, OS-Versionen oder in bestimmten Regionen auftreten – Probleme, die in einer kontrollierten Umgebung nicht reproduziert werden können.

Wie das SDK Daten ohne Codeänderungen sammelt

Automatische Instrumentierung ist das Hauptmerkmal von Firebase Performance. Für Android registriert das SDK automatisch ActivityLifecycleCallbacks und misst die Zeit zwischen onCreate und onResume (Bildschirm-Rendering-Zeit). Für iOS swizzelt es die Methoden viewDidLoad und viewDidAppear. Netzwerkanfragen werden auf OkHttpInterceptor-Ebene (Android) oder NSURLProtocol-Ebene (iOS) abgefangen. Der Entwickler muss keine Start/Stop-Aufrufe für Standardmetriken hinzufügen.

Aktivieren und Deaktivieren des Performance SDK wird über das Google Services Plugin (Android) oder Info.plist (iOS) verwaltet. Zum Debuggen können Sie die ausführliche Protokollierung des Performance SDK aktivieren, die anzeigt, welche Metriken gesammelt und gesendet werden. In der Produktion wird empfohlen, die Protokollierung auf Warnungsebene zu belassen, um die Protokolle nicht mit unnötigen Informationen zu überladen. Für Projekte mit Flutter oder React Native kann die automatische Instrumentierung eingeschränkt sein – weitere Details im Abschnitt Codebeispiele.

Kostenlose Grenzen und Preisgestaltung

Firebase Performance ist im kostenlosen Spark-Tarif ohne Begrenzung der Anzahl der Traces oder des Datenvolumens verfügbar. Der kostenpflichtige Blaze-Tarif berechnet ebenfalls keine Gebühren für Performance Monitoring – es ist einer der wenigen Firebase-Dienste, die in beiden Tarifen völlig kostenlos sind. Es gibt nur eine Einschränkung: Die Daten werden 30 Tage (im Spark) und bis zu 365 Tage (im Blaze) gespeichert. Für eine langfristige Analyse exportieren Sie die Daten über den BigQuery-Export.

Keine Kosten machen Firebase Performance zur idealen Wahl für jedes Projekt – vom Prototyp bis zur Unternehmensanwendung mit Millionen von Benutzern. Die einzigen Kosten sind der ausgehende Datenverkehr des Performance SDK, der jedoch im Vergleich zu anderen Netzwerkoperationen der App vernachlässigbar ist (weniger als 1 MB pro Monat pro Gerät). Der BigQuery-Export berechnet Gebühren für Speicher und Abfragen, aber das Performance SDK selbst ist kostenlos.

Automatische Metriken: Was wird ohne Code gemessen

Firebase Performance sammelt automatisch fünf Kategorien von Metriken ohne eine einzige Codezeile: App-Startzeit, langsame HTTP-Anfragen, Bildschirm-Rendering-Geschwindigkeit, Speichernutzung (nur Android) und Bildrate (nur Android). Diese Metriken sind in der Firebase-Konsole sofort nach dem Verbinden des SDK und der ersten Benutzersitzung verfügbar.

App-Startzeit – die Zeit vom Prozessstart bis zur vollständigen Bereitschaft der UI für Interaktionen. Sie wird unterteilt in Kaltstart (App startet von Grund auf) und Warmstart (App wird aus dem Hintergrundzustand fortgesetzt). Der Kaltstart umfasst das Laden von DEX-Dateien, die Initialisierung statischer Felder, den Aufruf von Application.onCreate und Activity.onCreate. Firebase klassifiziert automatisch den Starttyp und zeigt die Zeitverteilung für jeden Typ an.

Bildschirm-Rendering-Zeit – die Zeit vom Beginn des Bildschirm-Ladevorgangs (onCreate für Android, viewDidLoad für iOS) bis zum Zeitpunkt, an dem der Bildschirm für Interaktionen bereit ist (onResume, viewDidAppear). Firebase aggregiert Daten nach jedem Bildschirm (nach Klassenname oder benutzerdefiniertem Bildschirmnamen) und ermöglicht so die Identifizierung, welcher Bildschirm am längsten lädt. Für Android werden zusätzlich verworfene Bilder (Dropped Frames) gemessen – die Anzahl der beim Bildschirm-Rendering ausgelassenen Bilder (Jank).

Netzwerkanfragen (HTTP/HTTPS)

Das Performance SDK fängt jede HTTP/HTTPS-Anfrage automatisch ab und misst sie, die von der App über URLSession, OkHttp oder URLConnection gesendet wird. Für jede Anfrage werden aufgezeichnet: URL (Pfad ohne Abfrageparameter aus Sicherheitsgründen), HTTP-Methode, Antwortcode, Antwortgröße in Bytes, Anfragedauer und Verbindungsgeschwindigkeit (WiFi, Mobilfunk). Die Daten werden im Dashboard für Netzwerkanfragen der Firebase-Konsole aggregiert.

Langsame Anfragen – Anfragen, deren Dauer einen festgelegten Schwellenwert überschreitet. Standardmäßig beträgt der Schwellenwert für langsame Anfragen 4000 ms. Diese Metrik ist entscheidend für die Identifizierung von Backend-Problemen: Wenn nach einem Backend-Update die Anzahl der langsamen Anfragen von 1 % auf 15 % steigt, ist dies ein Signal für eine sofortige Server-Log-Analyse. Benutzer warten nicht länger als 5 Sekunden auf eine Antwort – Firebase-Daten zeigen, dass 53 % der Benutzer die App schließen, wenn eine Anfrage länger als 3 Sekunden dauert.

Einschränkungen der automatischen Instrumentierung

iOS-Einschränkungen: Unter iOS kann das Performance SDK keine verworfenen Bilder messen (dies ist eine private API). Verwenden Sie zum Messen von Jank unter iOS MetricKit oder CADisplayLink. Außerdem fängt das SDK unter iOS keine Anfragen ab, die über HTTP-Clients von Drittanbietern ausgeführt werden, die URLSession nicht verwenden (z. B. SwiftNIO). Verwenden Sie in solchen Fällen benutzerdefinierte Traces mit HTTP-Attributen.

Android-Einschränkungen: Unter Android ist die automatische Speichermessung nur auf Geräten mit Android 8.0+ (API 26+) verfügbar. Verwenden Sie für ältere Versionen benutzerdefinierte Traces mit Daten, die über Debug.getMemoryInfo() abgerufen werden. Außerdem fängt das SDK keine WebSocket-Verbindungen ab – diese erfordern separate Traces. Trotz dieser Einschränkungen decken die automatischen Metriken 80 % der Anforderungen an die Leistungsüberwachung ab.

Benutzerdefinierte Traces und HTTP-Attribute

Benutzerdefinierte Traces sind benannte Zeitintervalle, die der Entwickler manuell erstellt, um die Leistung bestimmter Szenarien zu messen: Laden eines Nachrichtenfeeds, Verarbeiten eines Bildes, Synchronisieren von Daten, Ausführen einer komplexen Datenbankabfrage. Benutzerdefinierte Traces ergänzen die automatischen Metriken und ermöglichen die Messung genau der Codeabschnitte, die der Entwickler als kritisch für die Leistung betrachtet.

Jeder Trace hat einen Namen (maximal 100 Zeichen) und kann bis zu 5 benutzerdefinierte Metriken enthalten – numerische Werte, die innerhalb des Traces aufgezeichnet werden. Beispielsweise können Sie in einem Trace „image_processing“ Metriken wie „original_file_size“ und „processed_file_size“ messen. Die Metriken werden in der Firebase-Konsole als Verteilungen (Min, Max, Durchschnitt, Perzentile) angezeigt, sodass nicht nur die Dauer, sondern auch die Operationsmerkmale analysiert werden können.

HTTP-Attribute – eine spezielle Art von benutzerdefinierten Traces für Netzwerkanfragen, die nicht automatisch vom SDK abgefangen wurden (z. B. über WebSocket oder Bibliotheken von Drittanbietern). HTTP-Attribute umfassen URL, HTTP-Methode, Antwortcode und Antwortgröße. Firebase zeigt sie im Abschnitt Netzwerkanfragen zusammen mit automatisch erfassten Anfragen an und bietet so ein einheitliches Bild der Netzwerkinteraktion.

Wann benutzerdefinierte Traces verwendet werden sollten

Benutzerdefinierte Traces sind unverzichtbar für die Messung von: Ladezeit von Daten aus der lokalen Datenbank (Room, CoreData), Dauer komplexer Berechnungen (Verschlüsselung, Komprimierung), Leistung von Animationen und Übergängen, Antwortzeit von SDKs Dritter (Karten, Zahlungen, Analysen). Erstellen Sie für jedes dieser Szenarien einen Trace, umschließen Sie den gemessenen Code mit Start/Stop und fügen Sie Attribute für die spätere Segmentierung hinzu.

Übertreiben Sie es nicht mit benutzerdefinierten Traces. Jeder Trace verursacht zusätzlichen Batterie- und Datenverbrauch. Es wird empfohlen, nicht mehr als 10–15 aktive Traces in der Produktionsversion der App zu haben. Zum Debuggen können Sie weitere Traces hinzufügen, aber deaktivieren Sie vor der Veröffentlichung übermäßige Traces über Remote Config (verwenden Sie das Flag performance_tracing_enabled). Dadurch kann die detaillierte Ablaufverfolgung nur für ausgewählte Benutzer oder Sitzungen aktiviert werden.

Trace-Attribute zur Segmentierung

Benutzerdefinierte Attribute sind Schlüssel-Wert-Paare, die einem Trace zur späteren Filterung in der Firebase-Konsole hinzugefügt werden können. Beispielsweise können Sie für den Trace „feed_load“ Attribute wie „feed_type“ (main, explore, following) und „cache_status“ (cold, warm) hinzufügen. In der Konsole können die Trace-Daten nach diesen Attributen gefiltert werden, um zu ermitteln, welcher Feed-Typ am langsamsten lädt.

Einschränkungen: Jeder Trace kann bis zu 5 benutzerdefinierte Attribute haben. Attributwerte sind Zeichenfolgen mit bis zu 100 Zeichen. Attribute müssen vor dem Start des Traces festgelegt werden; das Ändern eines Attributs nach dem Start wird ignoriert. Diese Einschränkung hängt mit der Leistung zusammen: Das Fixieren von Attributen nach dem Start würde eine zusätzliche Synchronisation erfordern.

Leistungsschwellenwerte und Benachrichtigungen

Schwellenwerte sind konfigurierbare Grenzwerte für Metriken, bei deren Überschreitung Firebase Performance eine Warnung generiert. Die Schwellenwerte werden in der Firebase-Konsole (Performance > Thresholds) für jede automatische Metrik festgelegt: App-Startzeit (kalt/warm), Bildschirm-Rendering-Zeit, langsame HTTP-Anfragen, HTTP-Antwortzeit. Sie können globale Schwellenwerte für alle App-Versionen oder spezifische für bestimmte Versionen festlegen.

Benachrichtigungen sind automatische Mitteilungen, die Firebase sendet, wenn ein Schwellenwert überschritten wird. Benachrichtigungen können per E-Mail, Slack-Webhook, PagerDuty oder Cloud Functions (für benutzerdefinierte Verarbeitung) konfiguriert werden. Jede Benachrichtigung enthält: Metrikname, aktuellen Wert, Schwellenwert, App-Version, Segment (Gerät, Land). Benachrichtigungen ermöglichen es, auf Leistungsverschlechterungen zu reagieren, bevor sie für Benutzer bemerkbar werden.

Empfohlene Schwellenwerte nach Industriestandard (Google I/O 2025): Kaltstart – unter 2 Sekunden, Warmstart – unter 1 Sekunde, Bildschirm-Rendering – unter 500 ms, HTTP-Anfragedauer – unter 3000 ms (95. Perzentil), Anteil langsamer Anfragen – unter 5 %. Für stark wettbewerbsorientierte Apps (Social, E-Commerce) können die Zielschwellenwerte strenger sein: Kaltstart < 1,5 Sekunden, HTTP < 1000 ms.

Festlegen von Schwellenwerten in der Firebase-Konsole

In der Firebase-Konsole gehen Sie zum Bereich Performance und öffnen Sie die Registerkarte Thresholds. Legen Sie für jede Metrik den gewünschten Schwellenwert und den Prozentsatz der Benutzer fest, die von der Überschreitung betroffen sein sollen. Beispiel: „Kaltstart als langsam betrachten, wenn er 2 Sekunden für mehr als 10 % der Benutzer überschreitet“. Firebase zeigt die aktuellen Metrikwerte und den Verlauf der Überschreitungen an, um bei der Auswahl realistischer Schwellenwerte zu helfen.

Wichtig: Schwellenwerte beeinflussen die Datenerfassung nicht, sie steuern nur die Generierung von Benachrichtigungen. Wenn der Schwellenwert zu niedrig ist (z. B. Kaltstart 1 Sekunde, obwohl 50 % der Geräte in 3 Sekunden starten), werden ständig Benachrichtigungen eingehen und zu „Rauschen“ werden, das Entwickler nicht mehr beachten. Legen Sie Schwellenwerte auf Basis der aktuellen Leistung fest und verschärfen Sie sie dann schrittweise, während Sie die App optimieren.

Leistungs-Dashboard in der Firebase-Konsole

Das Leistungs-Dashboard zeigt die wichtigsten Metriken als Zeitreihen an, aufgeschlüsselt nach App-Version, Gerät, Land, Verbindungstyp und OS-Version. Für jede Metrik stehen zur Verfügung: Durchschnitt, Median, 95. Perzentil, 99. Perzentil. Das 95. Perzentil ist die aussagekräftigste Metrik zur Leistungsbewertung, da sie zeigt, wie die App auf schwachen Geräten funktioniert, während Ausreißer ignoriert werden.

Das Dashboard unterstützt den Versionsvergleich: Wählen Sie zwei App-Versionen (aktuell und vorherig) für den visuellen Metrikvergleich aus. Wenn nach einem Update das 95. Perzentil der Startzeit von 2,1 auf 3,4 Sekunden gestiegen ist – die Regression ist offensichtlich, und Sie müssen den Commit finden, der die Verlangsamung verursacht hat. Firebase Performance ist in GitHub, GitLab und Bitbucket integriert, sodass Metrikänderungen mit bestimmten Commits verknüpft werden können.

Codebeispiele für Performance Monitoring

Betrachten wir Integrationsbeispiele für Firebase Performance Monitoring in einer Android-App mit Kotlin. Der Code demonstriert die Erstellung eines benutzerdefinierten Traces zur Messung des Nachrichten-Feed-Ladens, das Hinzufügen eines HTTP-Attributs für eine nicht automatisch abgefangene Anfrage und die Verwendung von Trace zur Messung der Bildverarbeitungszeit. Alle Beispiele berücksichtigen die Möglichkeit, die Ablaufverfolgung über Remote Config zu deaktivieren.

Fügen Sie vor der Verwendung die Abhängigkeit hinzu: implementation("com.google.firebase:firebase-perf") über Firebase BOM. Für die automatische Instrumentierung ist keine zusätzliche Einrichtung erforderlich – das SDK fängt Standardoperationen automatisch ab, nachdem die Abhängigkeit hinzugefügt wurde.

Benutzerdefinierter Trace für Feed-Laden

Das erste Beispiel – Messung der Ladezeit des Nachrichtenfeeds vom Server. Der Trace umschließt den asynchronen fetchFeed-Vorgang, der Daten aus dem Netzwerk abruft und JSON parst. Dem Trace wurden benutzerdefinierte Attribute hinzugefügt: Datenquelle (Cache oder Netzwerk) und die Anzahl der empfangenen Beiträge. Dadurch können die Daten segmentiert werden und es wird verstanden, unter welchen Bedingungen der Feed am langsamsten lädt.

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

Die Funktion loadFeedWithTrace nimmt einen Source-Parameter („cache“ oder „network“) entgegen, der als Trace-Attribut verwendet wird. Nach Abschluss des asynchronen Vorgangs stoppt der Trace in einem finally-Block, was den Stopp auch bei Ausnahmen garantiert. Die Metrik items_count ermöglicht die Analyse, wie sich die Anzahl der Beiträge auf die Ladezeit auswirkt. In der Firebase-Konsole können Sie die Traces nach dem Source-Attribut filtern und sehen, dass das Laden über das Netzwerk dreimal langsamer ist als über den Cache.

HTTP-Attribut für nicht standardmäßige Anfrage

Das zweite Beispiel – HTTP-Attribut für eine über WebSocket durchgeführte Anfrage (nicht automatisch abgefangen). Die Klasse HttpMetric wird verwendet, die es ermöglicht, eine URL-Anfrage, ihre Methode, den Antwortcode und die Größe manuell zu registrieren. Firebase zeigt diese Anfrage im Abschnitt Netzwerkanfragen zusammen mit den automatisch abgefangenen Anfragen an.

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

Im Beispiel verwendet sendWithHttpMetric newHttpMetric, um einen nicht standardmäßigen HTTP-Aufruf zu registrieren. Das SDK fängt ihn nicht automatisch ab, daher legt der Entwickler manuell die URL, die Methode, den Antwortcode und die Größen fest. Es ist wichtig, die URL ohne Abfrageparameter zu setzen (aus Sicherheits- und Aggregationsgründen) – also /data, nicht /data?token=abc. Firebase gruppiert automatisch identische URL-Muster.

Messung der Bildverarbeitungszeit

Das dritte Beispiel demonstriert die Messung der Zeit für die Bildverarbeitung (Komprimierung, Größenänderung) mit einem benutzerdefinierten Trace. In diesem Fall umschließt der Trace einen synchronen Vorgang, aber für die Produktion verwenden Sie Coroutinen oder RxJava, um den UI-Thread nicht zu blockieren.

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

Die Funktion compressImage misst die Bildkomprimierungszeit auf JPEG mit 80 % Qualität. Das Attribut format ermöglicht zukünftige Vergleiche der JPEG- gegenüber WebP-Komprimierungszeit. Die Metrik output_size_kb zeigt, wie effizient die Komprimierung ist. In der Firebase-Konsole können Sie die Verteilung sehen: Auf schwachen Geräten (Budget-Android) dauert die Komprimierung viermal länger als auf Flaggschiffen, was die Ursache für Verzögerungen beim Hochladen von Bildern auf den Server sein kann.

Wie man die Leistung datenbasiert verbessert

Firebase Performance liefert Daten, bietet aber keine fertigen Lösungen. Die Analyse von Metriken erfordert das Verständnis typischer Ursachen für Leistungsverschlechterungen bei jeder Metrik. Betrachten wir die wichtigsten Verschlechterungsmuster und wie man sie anhand der Performance Monitoring-Daten diagnostiziert. Ansatz: Finden Sie eine Anomalie in einer Metrik → prüfen Sie typische Ursachen → wenden Sie die Optimierung an → überprüfen Sie das Ergebnis nach einer Woche.

Langsamer Kaltstart (> 2 Sekunden): Ursachen – schwere SDK-Initialisierung in Application.onCreate (Analysen, Crash-Reporting, Karten-SDK), Laden großer Ressourcen (Schriftarten, Designs), synchrone Operationen im Hauptthread beim Start. Lösungen: Lazy-Initialisierung des SDK, verzögertes Laden von Ressourcen, Verwendung der SplashScreen API (Android 12+) zum Anzeigen eines Platzhalters während der Initialisierung. Firebase Performance zeigt, welche App-Version langsamer geworden ist – prüfen Sie, welche Abhängigkeiten hinzugefügt oder aktualisiert wurden.

Langsames Bildschirm-Rendering (> 500 ms): Ursachen – komplexe View-Hierarchie (verschachteltes ConstraintLayout, mehrere Fragmente), Laden von Daten im UI-Thread (Netzwerk oder Festplatte), schwere Zeichenoperationen (große Bilder, benutzerdefinierte Views). Lösungen: Optimierung der Layout-Hierarchie (Layout Inspector in Android Studio), Auslagern von Daten in den Hintergrundthread, Zwischenspeichern von Bildern über Glide oder Coil. Verwenden Sie den Bildschirm-Rendering-Filter in Firebase, um den langsamsten Bildschirm zu finden und zuerst zu optimieren.

Optimierung von Netzwerkanfragen

Langsame HTTP-Anfragen (> 3 Sekunden): Ursachen – langsamer Server, große Payloads, fehlendes Caching, suboptimales Protokoll (HTTP/1.1 statt HTTP/2), DNS-Auflösung. Lösungen: Überprüfen Sie die Serverseite (Betriebszeit, Latenz), reduzieren Sie die Antwortgröße (Paginierung, GraphQL, protobuf statt JSON), aktivieren Sie Caching über HTTP-Header (Cache-Control), verwenden Sie OkHttp Interceptor zum Hinzufügen von Timeouts und Wiederholungslogik.

Firebase Performance zeigt die Verteilung der Anforderungszeit: DNS-Auflösung, TCP-Handshake, TLS-Handshake, Anforderung senden, Antwort empfangen. Wenn der Großteil der Zeit auf DNS entfällt – verwenden Sie DNS-Vorladen (OkHttp DNS-over-HTTPS). Wenn auf TLS – verwenden Sie Sitzungswiederaufnahme und optimieren Sie Cipher-Suites. Wenn auf Antwortempfang – überprüfen Sie die Antwortgröße und die Netzwerkgeschwindigkeit des Benutzers. Firebase-Daten ermöglichen es, das Problem auf Protokollebene zu lokalisieren, anstatt nur zu sagen „Die Anfrage ist langsam“.

Remote Config-Integration zum Deaktivieren der Ablaufverfolgung

Für die Produktion wird empfohlen, ein Remote Config-Flag performance_tracing_enabled hinzuzufügen, das das Remote-Deaktivieren benutzerdefinierter Traces ermöglicht. Wenn das Firebase Performance SDK auf dem Client zu viele Daten generiert oder die Leistung beeinträchtigt (auf schwachen Geräten), können Sie Traces für alle Benutzer deaktivieren und nur die automatischen Metriken belassen, die einen minimalen Overhead haben.

Beispiel-Logik: Beim App-Start prüfen Sie den Remote Config-Parameter performance_tracing_enabled. Wenn false – geben alle Aufrufe von Firebase.performance.newTrace() ein Stub-Objekt zurück, das keine Daten sammelt. Dies wird über eine Wrapper-Klasse implementiert, die das Flag vor dem Erstellen eines Traces prüft. Dieser Ansatz ermöglicht die Aktivierung der detaillierten Ablaufverfolgung für bestimmte Benutzer (Beta-Tester, Entwickler), ohne die gesamte Zielgruppe zu beeinträchtigen.