Best practice per l'efficienza del recupero di Remote Config

Firebase Remote Config ti offre un controllo flessibile sul comportamento e sull'aspetto della tua app. Ciò consente funzionalità come il rilascio di funzionalità e test A/B multipiattaforma per le tue app, il tutto senza eseguire il deployment di nuove versioni o navigare tra più aggiornamenti degli store.

Che tu stia prototipando, gestendo una startup in crescita o un'applicazione aziendale su larga scala, la gestione del volume di recupero della rete è fondamentale per offrire un'esperienza utente rapida e reattiva. La gestione efficiente della configurazione riduce la latenza di avvio a freddo, consente di risparmiare dati client e utilizzo della batteria e previene l'overhead di rete non necessario. Inoltre, se la tua base utenti si espande rapidamente e aumenta l'utilizzo in futuro, semplificare l'integrazione di Remote Config contribuisce a garantire che l'utilizzo rimanga efficiente.

Puoi ridurre significativamente il traffico delle richieste di rete lato client perfezionando la modalità e il momento in cui le app recuperano i parametri e li attivano.

Passa al pattern "recupera per la sessione successiva"

Un pattern comune da evitare è l'utilizzo della chiamata fetchAndActivate, che recupera nuovi valori sulla rete e li attiva, a ogni avvio dell'app, in combinazione con un breve periodo di scadenza della cache per i valori recuperati in precedenza (ad esempio, da 15 minuti a un'ora). Il modello mentale alla base di questo approccio è che ogni volta che un utente apre l'app, i valori più recenti vengono recuperati e applicati. Anche se a volte è necessario un aggiornamento immediato (ad esempio, per eseguire una campagna di vendita giornaliera o una promozione di un gioco), è importante bilanciare questo obiettivo con l'impatto sul rendimento e sull'utilizzo del recupero della tua app.

Questo approccio forza nuove chiamate di rete ogni volta che la cache scade, generando un volume di recupero elevato per gli utenti che aprono l'app più volte al giorno.

In alternativa, valuta la possibilità di utilizzare le chiamate fetch e activate separatamente con un intervallo di recupero minimo più elevato per adottare un modello di "recupero per la sessione successiva". Puoi comunque utilizzare fetchAndActivate con un intervallo di recupero minimo più elevato, poiché fetch esegue una richiesta di rete solo se la cache viene invalidata, ma l'utilizzo delle due chiamate separatamente contribuisce a consolidare il pattern e a stabilirlo come pratica standard nel processo di sviluppo dell'applicazione. Inoltre, attivandoli separatamente, non corri il rischio di applicare valori di configurazione a metà sessione e interrompere l'esperienza utente.

Come funziona questo approccio

  • Attiva immediatamente all'avvio:applica immediatamente le configurazioni memorizzate nella cache della sessione precedente (ritardo di rete di 0 ms).
  • Recupero in background con una cache più lunga (ad esempio, più di 12 o 24 ore): richiedi in modo asincrono le configurazioni aggiornate per aggiornare la cache locale per la sessione successiva.

In che modo questa operazione ottimizza il volume di recupero

Un intervallo di recupero minimo più lungo comporta un numero inferiore di richieste di recupero. Il recupero di nuovi valori per la sessione successiva e l'attivazione dei valori memorizzati nella cache per la sessione corrente fanno sì che la tua app venga caricata istantaneamente dalla cache locale per un periodo di convalida più lungo, il che porta a esperienze utente migliori.

Ad esempio, se imposti minimumFetchInterval su 24 ore e un utente apre la tua app 5 o 10 volte in un solo giorno, l'SDK soddisfa automaticamente i lanci da 2 a 10 direttamente dalla cache locale, riducendo il numero di richieste di rete giornaliere dell'utente da 10 o più recuperi a 1.

I seguenti esempi mostrano l'aspetto di questa implementazione per Android, le piattaforme Apple e le app 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
});

Implementare il recupero "intelligente" condizionale

Se il pattern "Recupera per la sessione successiva" introduce una latenza eccessiva tra il momento in cui devi aggiornare i valori di Remote Config e il momento in cui diventano disponibili nelle tue app client, valuta l'adozione del recupero "smart" condizionale.

Per implementare questa funzionalità in modo efficace, evita di collegare trigger fetch a hook del ciclo di vita dell'interfaccia utente generici, ad esempio ogni volta che viene caricata una schermata, viene cambiata una scheda o una visualizzazione acquisisce lo stato attivo.

Attiva invece le richieste di recupero in modo selettivo in base a stati o azioni app espliciti, ad esempio:

  • Eventi di accesso utente
  • Transizione in flussi utente specifici in cui vengono utilizzati i parametri (ad esempio, l'inserimento di un funnel di checkout o l'avanzamento di livello in un gioco)

Al contrario, evita di attivare richieste di recupero per azioni di routine come:

  • Quando un utente apre l'app o inizia una nuova sessione
  • Quando l'app passa dallo stato in background a quello in primo piano

Passaggi successivi