Práticas recomendadas para eficiência da busca da Configuração remota

O Firebase Remote Config oferece controle flexível sobre o comportamento e a aparência do app. Isso permite recursos como lançamentos de recursos e testes A/B multiplataforma para seus apps, tudo sem implantar novas versões ou navegar por várias atualizações de app stores.

Seja para prototipagem, gerenciamento de uma startup em crescimento ou de um aplicativo empresarial em grande escala, gerenciar o volume de busca de rede é fundamental para oferecer uma experiência do usuário rápida e responsiva. O gerenciamento eficiente de configurações reduz a latência de inicialização a frio, economiza dados do cliente e uso da bateria e evita sobrecarga desnecessária da rede. Além disso, se a base de usuários crescer rapidamente e aumentar o uso no futuro, simplificar a integração do Remote Config ajudará a garantir que o uso permaneça eficiente.

É possível reduzir significativamente o tráfego de solicitações de rede do lado do cliente refinando como e quando os apps buscam e ativam parâmetros.

Mudar para o padrão "buscar para a próxima sessão"

Um padrão comum a ser evitado é usar a chamada fetchAndActivate, que busca novos valores na rede e os ativa, em cada inicialização do app, combinada com um período de expiração de cache curto para valores buscados anteriormente (por exemplo, de 15 minutos a uma hora). O modelo mental por trás dessa abordagem é que sempre que um usuário abre o app, ele tem os valores mais recentes buscados e aplicados. Embora haja momentos em que uma atualização imediata é necessária (por exemplo, ao veicular uma campanha de vendas diárias ou uma promoção de jogos), é importante equilibrar esse objetivo com o impacto no desempenho do app e no uso de busca.

Essa abordagem força novas chamadas de rede sempre que o cache expira, gerando um alto volume de busca para usuários que abrem o app várias vezes por dia.

Em vez disso, considere usar as chamadas fetch e activate separadamente com um intervalo mínimo de busca maior para adotar um modelo de "busca para a próxima sessão". Você ainda pode usar fetchAndActivate com um intervalo mínimo de busca maior, já que fetch só executa uma solicitação de rede se o cache for invalidado. No entanto, usar as duas chamadas separadamente ajuda a consolidar o padrão e estabelecê-lo como uma prática padrão no processo de desenvolvimento de aplicativos. Além disso, ao ativar separadamente, você não corre o risco de aplicar valores de configuração no meio da sessão e prejudicar a experiência do usuário.

Como essa abordagem funciona

  • Ativar imediatamente na inicialização:aplique as configurações armazenadas em cache da sessão anterior instantaneamente (atraso de rede de 0 ms).
  • Busque em segundo plano com um cache mais longo (por exemplo, mais de 12 ou 24 horas): solicite configurações atualizadas de forma assíncrona para atualizar o cache local da próxima sessão.

Como isso otimiza o volume de busca

Um intervalo de busca mínimo mais longo resulta em menos solicitações de busca. Buscar novos valores para a próxima sessão next e ativar valores armazenados em cache para a sessão atual significa que seu app carrega instantaneamente do cache local em um período de validação mais longo, resultando em experiências melhores para o usuário.

Por exemplo, se você definir minimumFetchInterval como 24 horas e um usuário abrir seu app 5 ou 10 vezes em um único dia, o SDK vai atender automaticamente aos lançamentos 2 a 10 diretamente do cache local, reduzindo a contagem diária de solicitações de rede desse usuário de 10 ou mais buscas para 1.

Os exemplos a seguir mostram como essa implementação é feita para Android, plataformas da Apple e apps da 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
});

Implementar busca "inteligente" condicional

Se o padrão "buscar para a próxima sessão" introduzir muita latência entre o momento em que você precisa atualizar os valores de Remote Config e quando eles ficam disponíveis nos apps clientes, considere adotar a busca condicional "inteligente".

Para implementar isso de maneira eficaz, evite anexar gatilhos fetch a hooks amplos do ciclo de vida da interface do usuário, como sempre que uma tela é carregada, uma guia é trocada ou uma visualização ganha foco.

Em vez disso, acione solicitações de busca seletivamente com base em ações ou estados explícitos do app, como:

  • Eventos de login do usuário
  • Transição para fluxos de usuários específicos em que seus parâmetros são usados (por exemplo, entrar em um funil de finalização de compra ou subir de nível em um jogo)

Por outro lado, evite acionar solicitações de busca para ações rotineiras, como:

  • Quando um usuário abre o app ou inicia uma nova sessão
  • Quando o app faz a transição entre os estados de segundo e primeiro plano

Próximas etapas