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 wie Feature-Rollouts und plattformübergreifende A/B-Tests für Ihre Apps nutzen, ohne neue Versionen bereitstellen oder mehrere App-Store-Updates durchführen zu müssen.

Ganz gleich, ob Sie Prototypen erstellen, ein wachsendes Start-up leiten oder eine Unternehmensanwendung in großem Umfang verwalten – die Verwaltung des Netzwerkabrufvolumens ist entscheidend für eine schnelle, reaktionsfähige Nutzererfahrung. Eine effiziente Konfigurationsverwaltung reduziert die Latenz bei Kaltstarts, spart Clientdaten und Akkuverbrauch und verhindert unnötigen Netzwerk-Overhead. Wenn sich Ihre Nutzerbasis schnell vergrößert 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 Netzwerkanfragetraffic erheblich reduzieren, indem Sie optimieren, wie und wann Apps Parameter abrufen und wann sie sie aktivieren.

Wechsel zum Muster „Für die nächste Sitzung abrufen“

Ein häufiges Muster, das vermieden werden sollte, 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 mentale Modell hinter diesem Ansatz ist, dass jedes Mal, wenn ein Nutzer die App öffnet, die neuesten Werte abgerufen und angewendet werden. Es gibt zwar Zeiten, in denen ein sofortiges Update erforderlich ist (z. B. bei einer täglichen Verkaufsaktion oder einer Spiele-Promotion), aber es ist wichtig, dieses Ziel mit den Auswirkungen auf die Leistung Ihrer App und die Abrufhäufigkeit abzuwägen.

Bei diesem Ansatz werden jedes Mal, wenn der Cache abläuft, neue Netzwerkaufrufe erzwungen. Dadurch entsteht ein hohes Abrufvolumen für Nutzer, die die App mehrmals am Tag öffnen.

Verwenden Sie stattdessen die Aufrufe fetch und activate separat mit einem höheren Mindestabrufintervall, um ein Modell vom Typ „Für die nächste Sitzung abrufen“ zu verwenden. Sie können fetchAndActivate weiterhin mit einem höheren Mindestabrufintervall verwenden, da fetch nur dann eine Netzwerkanfrage ausführt, 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 durch die separate Aktivierung nicht das Risiko, dass Konfigurationswerte mitten in einer Sitzung angewendet werden und die Nutzererfahrung beeinträchtigt wird.

Funktionsweise

  • Sofort beim 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 Mindestabrufintervall führt zu weniger Abrufanfragen. Wenn Sie neue Werte für die nächste Sitzung abrufen und im Cache gespeicherte Werte für die aktuelle Sitzung aktivieren, wird Ihre App über einen längeren Validierungszeitraum sofort aus dem lokalen Cache geladen. Das führt zu einer besseren Nutzererfahrung.

Wenn Sie beispielsweise minimumFetchInterval auf 24 Stunden festlegen und ein Nutzer Ihre App an einem Tag fünf- oder zehnmal ö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 zehn oder mehr Abrufen auf einen 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 „intelligentes“ Abrufen implementieren

Wenn das Muster „Für nächste Sitzung abrufen“ zu viel Latenz zwischen dem Zeitpunkt, an dem Sie Remote Config-Werte aktualisieren müssen, und dem Zeitpunkt, an dem sie in Ihren Client-Apps verfügbar sind, verursacht, sollten Sie bedingtes „intelligentes“ Abrufen in Betracht ziehen.

Um dies effektiv umzusetzen, sollten Sie fetch-Trigger nicht an allgemeine UI-Lebenszyklus-Hooks anhängen, z. B. jedes Mal, wenn ein Bildschirm geladen wird, ein Tab gewechselt wird oder eine Ansicht den Fokus erhält.

Lösen Sie Abrufanfragen stattdessen selektiv auf Grundlage expliziter App-Aktionen oder -Zustände aus, z. B.:

  • Nutzeranmeldeereignisse
  • Übergang zu bestimmten User-Flows, in denen Ihre Parameter verwendet werden (z. B. Aufrufen eines Trichters für den Bezahlvorgang oder Erreichen eines neuen Levels in einem Spiel)

Vermeiden Sie es, Abrufanfragen für Routineaktionen auszulösen, wie z. B.:

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

Nächste Schritte