Prácticas recomendadas para la eficiencia de la recuperación de Remote Config

Firebase Remote Config te brinda un control flexible sobre el comportamiento y la apariencia de tu app. Esto habilita funciones como el lanzamiento de funciones y las pruebas A/B multiplataforma para tus apps, todo sin implementar versiones nuevas ni navegar por varias actualizaciones de la tienda de aplicaciones.

Ya sea que estés creando un prototipo, dirigiendo una startup en crecimiento o administrando una aplicación empresarial a gran escala, administrar el volumen de recuperación de tu red es clave para ofrecer una experiencia del usuario rápida y responsiva. La administración eficiente de la configuración reduce la latencia de inicio en frío, ahorra datos del cliente y uso de batería, y evita la sobrecarga innecesaria de la red. Además, si tu base de usuarios se expande rápidamente y aumenta el uso en el futuro, optimizar tu integración de Remote Config te ayudará a garantizar que el uso siga siendo eficiente.

Puedes reducir significativamente el tráfico de solicitudes de red del cliente si refinas cómo y cuándo las apps recuperan parámetros y cuándo los activan.

Cambio al patrón de "búsqueda para la próxima sesión"

Un patrón común que se debe evitar es usar la llamada fetchAndActivate, que recupera valores nuevos a través de la red y los activa, en cada inicio de la app, junto con un período de vencimiento de caché corto para los valores recuperados anteriormente (por ejemplo, de 15 minutos a una hora). El modelo mental detrás de este enfoque es que, cada vez que un usuario abre la app, siempre tiene los valores más recientes recuperados y aplicados. Si bien hay ocasiones en las que es necesaria una actualización inmediata (por ejemplo, cuando se ejecuta una campaña de ventas diaria o una promoción de un juego), es importante equilibrar ese objetivo con el impacto en el rendimiento de la app y el uso de la recuperación.

Este enfoque fuerza llamadas de red nuevas cada vez que vence la caché, lo que genera un gran volumen de recuperación para los usuarios que abren la app varias veces al día.

En su lugar, considera usar las llamadas fetch y activate por separado con un intervalo de recuperación mínimo más alto para adoptar un modelo de "recuperación para la próxima sesión". Aun así, puedes usar fetchAndActivate con un intervalo de recuperación mínimo más alto, ya que fetch solo ejecuta una solicitud de red si se invalida la caché, pero usar las dos llamadas por separado ayuda a consolidar el patrón y establecerlo como una práctica estándar en el proceso de desarrollo de tu aplicación. Además, si la activas por separado, no corres el riesgo de aplicar valores de configuración a mitad de la sesión y, de este modo, interrumpir la experiencia del usuario.

Cómo funciona este enfoque

  • Activar de inmediato al iniciar: Aplica al instante (0 ms de retraso de red) los parámetros de configuración almacenados en caché de la sesión anterior.
  • Recuperación en segundo plano con una caché más larga (por ejemplo, más de 12 o 24 horas): Solicita configuraciones actualizadas de forma asíncrona para actualizar la caché local para la próxima sesión.

Cómo optimiza el volumen de recuperación

Un intervalo de recuperación mínimo más largo genera menos solicitudes de recuperación. Recuperar valores nuevos para la sesión siguiente y activar los valores almacenados en caché para la sesión actual significa que tu app se carga de forma instantánea desde la caché local durante un período de validación más largo, lo que genera mejores experiencias del usuario.

Por ejemplo, si estableces minimumFetchInterval en 24 horas y un usuario abre tu app 5 o 10 veces en un solo día, el SDK satisface automáticamente los inicios del 2 al 10 directamente desde la caché local, lo que reduce el recuento diario de solicitudes de red de ese usuario de 10 o más recuperaciones a 1.

En los siguientes ejemplos, se muestra cómo se ve esta implementación en Android, las plataformas de Apple y las apps 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
});

Implementa la recuperación "inteligente" condicional

Si el patrón de "recuperación para la próxima sesión" introduce demasiada latencia entre el momento en que necesitas actualizar los valores de Remote Config y el momento en que están disponibles en tus apps cliente, considera adoptar la recuperación "inteligente" condicional.

Para implementar esto de manera eficaz, evita adjuntar activadores fetch a hooks amplios del ciclo de vida de la IU, como cada vez que se carga una pantalla, se cambia de pestaña o una vista gana el enfoque.

En cambio, activa las solicitudes de recuperación de forma selectiva según las acciones o los estados explícitos de la app, como los siguientes:

  • Eventos de acceso del usuario
  • Transición a flujos de usuarios específicos en los que se usan tus parámetros (por ejemplo, ingresar a un embudo de confirmación de compra o subir de nivel en un juego)

Por el contrario, evita activar solicitudes de recuperación para acciones de rutina como las siguientes:

  • Cuando un usuario abre la app o inicia una sesión nueva
  • Cuando la app realiza la transición entre los estados de segundo plano y primer plano

Próximos pasos