Remote Config 提取效率方面的最佳实践

Firebase Remote Config 可让您灵活控制应用的行为和外观。这样，您就可以为应用实现功能发布和跨平台 A/B 测试等功能，而无需部署新版本或浏览多个应用商店更新。

无论您是在进行原型设计、运营一家不断成长的初创公司，还是在管理大规模的企业应用，管理网络提取量都是提供快速、响应迅速的用户体验的关键。高效的配置管理可减少冷启动延迟时间、节省客户端数据和电池用量，并防止不必要的网络开销。此外，如果您的用户群快速扩大，并在未来推高用量，那么简化 Remote Config 集成有助于确保您的用量保持高效。

通过优化应用提取参数的方式和时间以及激活参数的时间，您可以显著减少客户端网络请求流量。

改用“为下一个会话提取”模式

一种应避免的常见模式是，在每次应用启动时都使用 fetchAndActivate 调用（通过网络提取新值并激活它们），同时为之前提取的值设置较短的缓存过期时间（例如 15 分钟到 1 小时）。这种方法的心理模型是，每次用户打开应用时，他们始终会提取并应用最新值。虽然有时需要立即更新（例如，开展每日促销活动或游戏促销活动），但重要的是要平衡该目标与对应用性能和提取用量的影响。

这种方法会在每次缓存过期时强制执行新的网络调用，从而为每天多次打开应用的用户产生大量提取。

相反，请考虑单独使用 fetch 和 activate 调用，并设置更长的最短提取间隔，以采用“为下一个会话提取”模型。您仍然可以使用 fetchAndActivate，并设置更长的最短提取间隔时间，因为 fetch 仅在缓存失效时才会执行网络请求，但分别使用这两个调用有助于巩固该模式，并将其确立为应用开发过程中的标准做法。此外，通过单独激活，您不会面临在会话中途应用配置值并中断用户体验的风险。

此方法的运作方式

  • 启动时立即激活：立即应用从上一个会话缓存的配置（0 毫秒网络延迟）。
  • 在后台提取，并设置较长的缓存时间（例如，超过 12 或 24 小时）：异步请求更新后的配置，以便为下一个会话刷新本地缓存。

此功能如何优化提取量

最小提取间隔越长，提取请求就越少。为下一个会话提取新值并为当前会话激活缓存值，意味着您的应用会在更长的验证期内从本地缓存即时加载，从而带来更好的用户体验。

例如，如果您将 minimumFetchInterval 设置为 24 小时，而用户在一天内打开您的应用 5 次或 10 次，则 SDK 会自动直接从本地缓存中满足第 2 次到第 10 次启动的需求，从而将该用户的每日网络请求数从 10 次或更多次提取减少到 1 次。

以下示例展示了 Android、Apple 平台和 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
});

实现有条件的“智能”提取

如果“为下一个会话提取”模式在您需要更新 Remote Config 值和这些值在客户端应用中可用之间引入了过多的延迟，请考虑采用条件式“智能”提取。

为了有效实现这一点，请避免将 fetch 触发器附加到宽泛的界面生命周期钩子，例如每次屏幕加载、标签页切换或视图获得焦点时。

相反，应根据明确的应用操作或状态选择性地触发提取请求，例如：

  • 用户登录事件
  • 过渡到使用参数的特定用户体验流程（例如，进入结账漏斗或在游戏中升级）

相反，请避免针对以下常规操作触发提取请求：

  • 当用户打开应用或开始新会话时
  • 应用在后台和前台状态之间切换时

后续步骤