Bonnes pratiques pour l'efficacité des extractions Remote Config

Firebase Remote Config vous permet de contrôler de manière flexible le comportement et l'apparence de votre application. Cela permet d'activer des fonctionnalités telles que les déploiements de fonctionnalités et les tests A/B multiplates-formes pour vos applications, sans avoir à déployer de nouvelles versions ni à gérer plusieurs mises à jour de magasins d'applications.

Que vous soyez en train de créer un prototype, de gérer une start-up en pleine croissance ou de gérer une application d'entreprise à grande échelle, la gestion du volume de récupération réseau est essentielle pour offrir une expérience utilisateur rapide et réactive. Une gestion efficace de la configuration réduit la latence de démarrage à froid, économise les données client et l'utilisation de la batterie, et évite les frais généraux de réseau inutiles. De plus, si votre base d'utilisateurs s'étend rapidement et que l'utilisation augmente à l'avenir, la rationalisation de votre intégration de Remote Config vous aidera à garantir l'efficacité de votre utilisation.

Vous pouvez réduire considérablement le trafic des requêtes réseau côté client en affinant la manière dont les applications récupèrent les paramètres et le moment où elles les activent.

Passer au modèle "récupérer pour la session suivante"

Un modèle courant à éviter consiste à utiliser l'appel fetchAndActivate, qui récupère les nouvelles valeurs sur le réseau et les active, à chaque lancement de l'application, en combinaison avec une courte période d'expiration du cache pour les valeurs précédemment récupérées (par exemple, de 15 minutes à une heure). Le modèle mental derrière cette approche est que chaque fois qu'un utilisateur ouvre l'application, les dernières valeurs sont toujours récupérées et appliquées. Bien qu'une mise à jour immédiate soit parfois nécessaire (par exemple, pour lancer une campagne de vente quotidienne ou une promotion de jeu), il est important de trouver un juste équilibre entre cet objectif et l'impact sur les performances de votre application et l'utilisation de la récupération.

Cette approche force de nouveaux appels réseau chaque fois que le cache expire, ce qui génère un volume de récupération élevé pour les utilisateurs qui ouvrent l'application plusieurs fois par jour.

Envisagez plutôt d'utiliser les appels fetch et activate séparément avec un intervalle de récupération minimal plus élevé pour adopter un modèle de "récupération pour la session suivante". Vous pouvez toujours utiliser fetchAndActivate avec un intervalle de récupération minimal plus élevé, car fetch n'exécute une requête réseau que si le cache est invalidé. Toutefois, l'utilisation des deux appels séparément permet de consolider le modèle et de l'établir comme une pratique standard dans votre processus de développement d'applications. De plus, en activant séparément, vous ne risquez pas d'appliquer des valeurs de configuration en cours de session et de perturber l'expérience utilisateur.

Fonctionnement de cette approche

  • Activer immédiatement au lancement : appliquez instantanément les configurations mises en cache de la session précédente (délai réseau de 0 ms).
  • Récupérer en arrière-plan avec un cache plus long (par exemple, plus de 12 ou 24 heures) : demandez des configurations mises à jour de manière asynchrone pour actualiser le cache local pour la session suivante.

Comment cela optimise-t-il le volume de récupération ?

Un intervalle de récupération minimal plus long entraîne moins de requêtes de récupération. Récupérer de nouvelles valeurs pour la prochaine session et activer les valeurs mises en cache pour la session en cours signifie que votre application se charge instantanément à partir du cache local sur une période de validation plus longue, ce qui améliore l'expérience utilisateur.

Par exemple, si vous définissez minimumFetchInterval sur 24 heures et qu'un utilisateur ouvre votre application 5 ou 10 fois en une seule journée, le SDK répond automatiquement aux lancements 2 à 10 directement à partir du cache local, ce qui réduit le nombre de requêtes réseau quotidiennes de cet utilisateur de 10 récupérations ou plus à une seule.

Les exemples suivants montrent à quoi ressemble cette implémentation pour Android, les plates-formes Apple et les applications Web :

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
});

Implémenter la récupération "intelligente" conditionnelle

Si le modèle "récupérer pour la prochaine session" introduit trop de latence entre le moment où vous devez mettre à jour les valeurs Remote Config et celui où elles deviennent disponibles dans vos applications clientes, envisagez d'adopter la récupération "intelligente" conditionnelle.

Pour implémenter cela efficacement, évitez d'associer des déclencheurs fetch à des hooks de cycle de vie d'UI généraux, par exemple à chaque chargement d'écran, changement d'onglet ou sélection d'une vue.

Déclenchez plutôt les requêtes de récupération de manière sélective en fonction d'actions ou d'états explicites de l'application, par exemple :

  • Événements de connexion des utilisateurs
  • Transition vers des parcours utilisateur spécifiques dans lesquels vos paramètres sont utilisés (par exemple, l'accès à un entonnoir de paiement ou le passage au niveau supérieur dans un jeu)

À l'inverse, évitez de déclencher des requêtes de récupération pour des actions de routine telles que :

  • Lorsqu'un utilisateur ouvre l'application ou démarre une nouvelle session
  • Lorsque l'application passe de l'arrière-plan au premier plan, et inversement

Étapes suivantes