Firebase Remote Config fetch耗时6-25秒是否正常？

该耗时表现不属于正常情况，正常良好网络环境下，Remote Config的fetch请求耗时通常在200ms-2s区间，即便是跨区域访问也极少超过3s，你遇到的情况基本可以判定为接入实现问题，而非服务端正常表现。

• 首先排查初始化时序问题
  你提到应用启动时立即执行初始化，最常见的错误是在FirebaseApp.initializeApp()完成回调前就调用了fetch方法。此时SDK内部未完成核心上下文加载，会触发内部等待、重复建连、重试逻辑，直接将总耗时拉升到数秒到数十秒级别。不要在应用启动的最前置节点同步调用fetch，等Firebase核心初始化完成的回调触发后再执行拉取逻辑。

• 检查fetch调用参数与限流情况
  如果你调用fetch时传入0作为最小缓存过期时间，会强制SDK绕过本地缓存走服务端实时拉取，该操作本身不会导致十几秒耗时，但如果短时间内频繁触发fetch超过服务端配额，SDK会自动触发指数退避重试，重试等待时间会直接叠加到总耗时里。测试阶段不要高频无间隔调用fetch，很容易触发限流退避。

• 排查SDK版本与线程调度问题
  2022年之前发布的部分旧版Firebase客户端SDK，存在冷启动阶段Remote Config工作线程优先级被系统压低的问题，会导致请求发起、回调调度被延迟，表现为整体耗时异常高，先升级到最新稳定版SDK再复测。
  另外不要在主线程同步阻塞等待fetch结果，主线程被其他启动任务占满时，SDK的网络回调无法被及时调度，会出现“网络请求早已返回但代码等了十几秒才拿到结果”的假象。

• 跨区域测试结果的参考说明
  你在欧洲、美国两个区域都观测到一致的耗时表现，基本可以排除服务端区域节点故障的可能——Remote Config是全球边缘节点分发服务，欧美本地用户访问就近节点的延迟通常在百毫秒级，两个区域同时出现服务端级别的高延迟概率极低，问题点一定在客户端实现侧。

快速定位根因的方法：加埋点拆分三段耗时单独统计：1. Firebase核心初始化从开始到完成的耗时；2. fetch方法从调用到实际发出网络请求的耗时；3. 网络请求本身从发出去到收到完整响应的耗时。如果前两段耗时占比超过50%，就是初始化时序、线程调度的问题；如果是网络请求本身耗时高，抓包确认是否被本地网络拦截框架、代理、VPN工具劫持。

内容的提问来源于stack exchange，提问作者Carl