Best Practices für effiziente Remote Config-Fetches

Firebase Remote Config bietet Ihnen flexible Kontrolle über das Verhalten und die Darstellung Ihrer App. So können Sie Funktionen für Ihre Apps einführen und plattformübergreifende A/B-Tests durchführen, ohne neue Versionen bereitzustellen oder mehrere App-Store-Updates durchzuführen.

Ganz gleich, ob Sie einen Prototyp erstellen, ein wachsendes Startup leiten oder eine Unternehmensanwendung im großen Maßstab verwalten – die Verwaltung des Netzwerkabrufvolumens ist entscheidend für eine schnelle, reaktionsschnelle Nutzererfahrung. Eine effiziente Konfigurationsverwaltung reduziert die Kaltstartlatenz, schont Clientdaten und Akku und vermeidet unnötigen Netzwerk-Overhead. Wenn Ihre Nutzerbasis schnell wächst und die Nutzung in Zukunft steigt, können Sie durch die Optimierung Ihrer Remote Config-Integration dafür sorgen, dass die Nutzung effizient bleibt.

Sie können den clientseitigen Netzwerkanfrage-Traffic erheblich reduzieren, indem Sie optimieren, wie und wann Apps Parameter abrufen und aktivieren.

Zum Muster „für die nächste Sitzung abrufen“ wechseln

Ein häufiges Muster, das Sie vermeiden sollten, ist die Verwendung des fetchAndActivate-Aufrufs, der sowohl neue Werte über das Netzwerk abruft als auch aktiviert, bei jedem App-Start in Kombination mit einer kurzen Cache-Ablaufzeit für zuvor abgerufene Werte (z. B. 15 Minuten bis eine Stunde). Das zugrunde liegende mentale Modell ist, dass jedes Mal, wenn ein Nutzer die App öffnet, immer die neuesten Werte abgerufen und angewendet werden. Manchmal ist eine sofortige Aktualisierung erforderlich, z. B. bei einer täglichen Verkaufsaktion oder einer Spielewerbung. Es ist jedoch wichtig, dieses Ziel mit den Auswirkungen auf die Leistung Ihrer App und die Abrufnutzung in Einklang zu bringen.

Bei diesem Ansatz werden jedes Mal, wenn der Cache abläuft, neue Netzwerkaufrufe erzwungen. Das führt zu einem hohen Abrufvolumen für Nutzer, die die App mehrmals täglich öffnen.

Verwenden Sie stattdessen fetch- und activate-Aufrufe separat mit einem höheren Mindestabrufintervall, um ein „Abruf für die nächste Sitzung“-Modell zu verwenden. Sie können fetchAndActivate weiterhin mit einem höheren Mindestabrufintervall verwenden, da mit fetch nur eine Netzwerkanfrage ausgeführt wird, wenn der Cache ungültig ist. Wenn Sie die beiden Aufrufe jedoch separat verwenden, wird das Muster gefestigt und als Standardverfahren in Ihrem Anwendungsentwicklungsprozess etabliert. Außerdem besteht bei einer separaten Aktivierung nicht das Risiko, dass Konfigurationswerte während einer Sitzung angewendet werden und die Nutzerfreundlichkeit beeinträchtigen.

Funktionsweise dieses Ansatzes

  • Sofort bei Start aktivieren:Konfigurationen, die aus der vorherigen Sitzung im Cache gespeichert wurden, werden sofort angewendet (0 ms Netzwerkverzögerung).
  • Im Hintergrund mit einem längeren Cache abrufen (z. B. mehr als 12 oder 24 Stunden): Fordern Sie aktualisierte Konfigurationen asynchron an, um den lokalen Cache für die nächste Sitzung zu aktualisieren.

So wird das Abrufvolumen optimiert

Ein längeres minimales Abrufintervall führt zu weniger Abrufanfragen. Wenn neue Werte für die nächste Sitzung abgerufen und zwischengespeicherte Werte für die aktuelle Sitzung aktiviert werden, lädt Ihre App über einen längeren Validierungszeitraum sofort aus dem lokalen Cache. Das führt zu einer besseren Nutzererfahrung.

Wenn Sie minimumFetchInterval beispielsweise auf 24 Stunden festlegen und ein Nutzer Ihre App an einem Tag 5- oder 10-mal öffnet, werden die Starts 2 bis 10 automatisch direkt aus dem lokalen Cache ausgeführt. Dadurch wird die Anzahl der täglichen Netzwerkanfragen dieses Nutzers von 10 oder mehr Abrufen auf 1 reduziert.

Die folgenden Beispiele zeigen, wie diese Implementierung für Android, Apple-Plattformen und Web-Apps aussieht:

Android

val remoteConfig = Firebase.remoteConfig

// Set a 24-hour minimum fetch interval (86,400 seconds)
val configSettings = remoteConfigSettings {
    minimumFetchIntervalInSeconds = 86400
}
remoteConfig.setConfigSettingsAsync(configSettings)

// 1. Instantly activate values cached from the LAST session
remoteConfig.activate().addOnCompleteListener {
    applyAppConfigurations()
}

// 2. Fetch new values in the background for the NEXT session
remoteConfig.fetch().addOnCompleteListener { task ->
    if (task.isSuccessful) {
        // Optional: Activate values if needed
    }
}

iOS+

let remoteConfig = RemoteConfig.remoteConfig()

// Set a 24-hour minimum fetch interval (86,400 seconds)
let settings = RemoteConfigSettings()
settings.minimumFetchInterval = 86400
remoteConfig.configSettings = settings

// 1. Instantly activate values cached from the LAST session
remoteConfig.activate { changed, error in
    guard error == nil else { return }
    DispatchQueue.main.async {
        self.applyAppConfigurations()
    }
}

// 2. Fetch new values in the background for the NEXT session
remoteConfig.fetch { status, error in
    if status == .success {
        // Optional: Activate values if needed
    }
}

Web

import { getRemoteConfig, fetchConfig, activate } from "firebase/remote-config";

const remoteConfig = getRemoteConfig(app);

// Set a 24-hour minimum fetch interval (86,400,000 ms)
remoteConfig.settings.minimumFetchIntervalMillis = 86400000;

// 1. Instantly activate values cached from the LAST session
activate(remoteConfig).then(() => {
    applyAppConfigurations();
});

// 2. Fetch new values in the background for the NEXT session
fetchConfig(remoteConfig).then(() => {
    // Optional: Activate values if needed
});

Bedingtes „smartes“ Abrufen implementieren

Wenn das Muster „Fetch for next session“ zu viel Latenz zwischen dem Zeitpunkt, zu dem Sie Remote Config-Werte aktualisieren müssen, und dem Zeitpunkt, zu dem sie in Ihren Client-Apps verfügbar sind, verursacht, sollten Sie das bedingte „smarte“ Abrufen in Betracht ziehen.

Um dies effektiv zu implementieren, sollten Sie fetch-Trigger nicht an breite UI-Lebenszyklus-Hooks anhängen, z. B. jedes Mal, wenn ein Bildschirm geladen, ein Tab gewechselt oder eine Ansicht fokussiert wird.

Stattdessen sollten Sie Abrufanfragen selektiv auf Grundlage expliziter App-Aktionen oder ‑Status auslösen, z. B.:

  • Nutzeranmeldeereignisse
  • Übergang zu bestimmten Nutzerabläufen, in denen Ihre Parameter verwendet werden (z. B. Aufrufen eines Trichters für den Bezahlvorgang oder Erreichen eines höheren Levels in einem Spiel)

Vermeiden Sie es umgekehrt, Abrufanfragen für Routineaktionen wie die folgenden auszulösen:

  • Wenn ein Nutzer die App öffnet oder eine neue Sitzung startet
  • Wenn die App zwischen dem Hintergrund- und dem Vordergrundstatus wechselt

Nächste Schritte