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 触发器附加到广泛的界面生命周期钩子上，例如每次屏幕加载、标签页切换或视图获得焦点时。

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

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

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

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

后续步骤