Firebase Performance Monitoring，采集开销实测

「Firebase Performance Monitoring，采集开销实测」

Firebase Performance Monitoring 在 Android 社区里的存在感一直有点微妙。官方文档把它包装成"开箱即用的性能监控方案"，接入两行代码就能看启动耗时、网络请求延迟、自定义 trace。但我在一个日活百万级别的应用里把它接进去之后，发现事情没那么简单。这篇文章不是接入教程，而是围绕一个核心问题：Performance Monitoring 的自动采集到底会带来多少运行时开销？我花了两周时间做了一组可控实验，数据有些出乎意料。

自动采集的边界：官方没说清的部分

Performance Monitoring 的自动采集分成三块：应用启动时间（app start）、屏幕渲染性能（screen rendering）、网络请求（HTTP/S network requests）。前两个相对单纯，第三个最容易踩坑。

我测试的基准环境是 Pixel 7，Android 14，Firebase BOM 32.7.0，Performance Monitoring SDK 具体版本是 20.5.2。应用本身是个中等复杂度的电商客户端，OkHttp 4.12.0，Retrofit 2.9.0，启动阶段大约触发 15-18 个网络请求。

按照官方文档，网络自动采集只需要确保依赖了 com.google.firebase:firebase-perf，然后在 AndroidManifest.xml 里加 <meta-data android:name="firebase_performance_logcat_enabled" android:value="true" /> 就能在 logcat 里看到采集痕迹。但实际跑起来，我发现自动采集的覆盖范围比预期窄得多。

OkHttp 的自动注入依赖 FirebasePerfOkHttpClient，这个类在运行时通过字节码插桩（bytecode instrumentation）替换掉原始的 OkHttpClient实例。问题在于，如果你的网络层封装了一层自定义的 Interceptor 或者用了 OkHttpClient.newBuilder() 链式构建，插桩很容易漏掉。我花了半天时间排查为什么某个核心 API 的耗时没有出现在控制台，最后发现是团队里一个老项目遗留下来的 CertificatePinner 配置导致 FirebasePerfOkHttpClient 的代理逻辑被绕过。具体表现是 logcat 里完全看不到 FirebasePerformance 的 tag，但其他请求正常采集。

更隐蔽的是 HTTP/2 和连接复用的场景。Performance Monitoring 把"请求耗时"定义为从 Call.execute() 或 enqueue() 开始到 Response 完全读取结束。如果连接池里有复用的连接，TCP 握手时间被摊薄，但 SDK 依然会把整个事件算成一次完整的网络 trace。这在控制台里看起来像是某次请求"异常地快"，实际上只是连接复用的假象。我对比了 Stetho 的抓包数据和 Firebase 的上报数据，发现两者的时间差最高能达到 40%，就是因为计算口径不一致。

启动耗时的测量偏差

应用启动时间是 Performance Monitoring 最吸引我的功能，因为启动优化是 Android 性能工作的永恒主题。但实测下来，这个指标的可靠性需要打折扣。

Firebase 把启动分成两类：onCreate() 到第一个 Activity.onResume() 之间的"冷启动时间"，以及应用处于后台被重新唤起时的"热启动时间"。这个定义本身就有问题。Android 12 引入的 SplashScreen API 让启动流程多了一层系统级回调，而 Firebase 的计时点并没有跟着适配。我在 Android 14 的设备上测试，发现如果使用了 SplashScreen.setKeepOnScreenCondition()，Performance Monitoring 上报的启动时间会比 reportFullyDrawn() 早 200-400ms 不等。这意味着控制台里显示的"启动耗时"实际上没有包含 SplashScreen 的展示时长，用户视角的启动体验被低估了。

为了验证这个偏差，我同时埋了三种测量方式：

// 方式一：Firebase 自动采集
// 无需代码，SDK 自动上报

// 方式二：自定义 Trace 对齐 reportFullyDrawn
val trace = FirebasePerformance.getInstance().newTrace("custom_launch")
trace.start()
// ... 在 onResume 之后
findViewById<View>(R.id.root).post {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
        reportFullyDrawn()
    }
    trace.stop()
}

// 方式三：Choreographer 帧回调
Choreographer.getInstance().postFrameCallback {
    // 记录第一帧实际渲染时间
}

三种方式的数据差异在低端机上被放大。Redmi Note 12（骁龙 4 Gen 1）上，Firebase 自动采集的冷启动中位数是 1.8s，自定义 trace 是 2.4s，Choreographer 帧回调是 2.6s。差距主要来自 Firebase 的计时终点偏早，以及没有计入 ContentProvider.onCreate() 阶段某些初始化任务的异步回调。

这个发现让我调整了内部优化的优先级。原来盯着 Firebase 控制台里的 1.8s 做优化，以为已经达标，实际上用户看到的完整启动时间要长得多。现在我们把自定义 trace 作为基准，Firebase 自动采集只作为趋势参考。

采集本身的 CPU 与内存开销

这是本文的核心。Performance Monitoring 的自动采集不是免费的午餐，SDK 需要在运行时做事件拦截、数据序列化、批量上报。我想知道的是：这些操作在大量网络请求和频繁页面切换的场景下，到底会吃掉多少资源。

测试方案分两组。A 组是基准组，完全移除 Performance Monitoring SDK，只保留 Firebase Analytics（因为项目里其他功能依赖）。B 组是实验组，完整接入 Performance Monitoring，开启所有自动采集项。两组都关闭日志输出，避免 logcat 本身的 I/O 干扰。

测试场景设计得偏极端，目的是放大开销：连续 100 次网络请求，每次请求返回 50KB JSON，同时触发 20 个 Activity 的跳转和 finish。每个场景跑 10 轮取中位数。

CPU 开销通过 Android Studio Profiler 的 CPU 记录功能采样，关注 com.google.firebase.perf 包名下的方法耗时。内存开销通过 Memory Profiler 的堆转储对比，看采集过程中是否引入额外的对象分配。

结果在 CPU 侧比预期明显。B 组在 100 次请求的场景中，FirebasePerformance 相关代码的 CPU 占用占总时间的 3.2%。细分下去，TraceMetric 的 protobuf 序列化占了 1.1%，NetworkRequestMetricBuilder 的字段组装占了 0.9%，剩下的 1.2% 分散在定时上报的 FlaconClient 和主线程的 AppStateMonitor 回调里。

3.2% 听起来不高，但要注意这是相对 CPU 时间的占比。在低端机上，同样的 100 次请求总耗时更长，但 Firebase 的绝对耗时几乎不变，因为序列化和上报的逻辑是固定的。这意味着低端机的相对占比会被放大到 5-6%。我在 Redmi Note 12 上复测，占比确实升到了 5.8%。

内存侧的发现更有意思。Performance Monitoring 对每次网络请求都会创建一个 NetworkRequestMetricBuilder 实例，内部持有 HttpMetric 的弱引用，以及请求头、响应码等字段的字符串拷贝。100 次请求的场景中，堆转储显示这些对象在 GC 前的存活数量是 127 个（因为部分请求并发，builder 实例有重叠），总大小约 86KB。真正的问题不是单次分配，而是高频请求时的 GC 压力。B 组的 GC 次数比 A 组多 2 次（10 轮测试中），平均每次 GC 暂停时间增加 3ms。

这个 3ms 的增量在常规应用里可以忽略，但在启动阶段或动画播放期间，主线程的任意停顿都可能掉帧。我专门测试了一个场景：在 RecyclerView 快速滑动时同时触发网络分页加载。A 组的帧率稳定在 58-60fps，B 组在分页加载的瞬间会掉到 52-54fps，Profiler 的帧时间线显示卡顿点恰好对齐 FirebasePerformance 的 onUpdateAppState 回调。

自定义 Trace 的隐藏成本

自动采集之外，Performance Monitoring 还支持手动自定义 trace。官方示例看起来很简单：

val trace = FirebasePerformance.getInstance().newTrace("load_data")
trace.start()
// ... 业务逻辑
trace.putAttribute("cache_hit", "false")
trace.putMetric("item_count", items.size.toLong())
trace.stop()

但实际用起来有几个性能陷阱。

newTrace 的字符串参数会被用作 trace 的标识符，Firebase 控制台里按这个字符串聚合。如果动态生成 trace 名称，比如把用户 ID 拼进去，控制台会为每个用户创建一个独立的 trace 卡片，既没法看聚合数据，又会在 SDK 侧积累大量 Trace 实例。我在代码审查里见过这种写法，newTrace("profile_load_${userId}")，当时没意识到问题，实测才发现每个 unique 字符串都会在 Trace 的静态缓存里占一条记录，长期运行后内存泄漏的风险很高。

putMetric 的数值类型是 long，但业务里很多指标是浮点。比如图片加载的耗时，OkHttp 的 EventListener 给的是毫秒级 double，转成 long 会丢失小数精度。更麻烦的是，如果同一个 trace 里多次调用 putMetric 同名 key，Firebase 的行为是覆盖而不是累加。我原以为可以像 StatsD 那样在同一个 trace 里多次采样同一个 metric 然后自动聚合，结果发现控制台上只显示最后一次的值。这个设计在文档里只用一句"Sets a metric for this trace"带过，很容易误解。

自定义 trace 的启动和停止本身也有开销。我对比了空 trace（不做任何业务逻辑，只 start/stop）和直接执行同样代码但不走 Firebase API 的情况。空 trace 的耗时在 Pixel 7 上是 0.08ms，Redmi Note 12 上是 0.35ms。这个量级在单次调用里微不足道，但如果在 RecyclerView 的 onBindViewHolder 里给每个 item 打 trace，滚动 50 个 item 就是 17.5ms 的纯开销，足够掉一帧。

批量上报与网络开销

采集的数据不会实时上报，而是先写入本地缓存，按固定间隔或事件数量阈值批量发送。这个策略本身合理，但参数不可调。

SDK 内部的上报逻辑在 FirebasePerfProvider 这个 ContentProvider 里初始化，比 Application.onCreate() 还早。这意味着哪怕你的应用还没进入主界面，上报线程池已经创建好了。我通过 Systrace 抓到过这个启动阶段的痕迹：FirebasePerfProvider.onCreate() 耗时约 12ms（Pixel 7），其中 8ms 花在 FirebaseApp.initializeApp 的连锁调用上。如果项目里同时接了 Analytics、Crashlytics、Performance Monitoring 等多个 Firebase 服务，这个初始化时间会叠加。我测过只留 Analytics 和 Crashlytics 的情况，FirebasePerfProvider 移除后启动时间减少约 18ms，应该是省掉了 Performance Monitoring 特有的线程池和缓存目录创建。

上报的网络流量我通过 Charles 代理抓包分析。单次批量上报的请求体是 protobuf 格式，典型大小在 2-8KB 之间，取决于这段时间内积累了多少 trace 和网络事件。频率大约是每 30 秒一次，如果 30 秒内没有新事件则跳过。这个 30 秒的间隔在 SDK 里是硬编码的，没有公开 API 可以调整。

对于流量敏感的场景，这个开销需要计入成本。我按日活百万、平均使用时长 10 分钟、每用户产生 50 个网络事件估算，每天的上报流量大约是 50 2KB 1,000,000 / 1024 / 1024 ≈ 95GB。实际会少一些，因为批量合并有压缩，但量级在这个范围。和自研的精简上报方案对比，Firebase 的 protobuf 冗余字段较多，同样的事件体积大约是我们自研方案的 2.3 倍。

与 R8/ProGuard 的冲突

性能优化离不开代码压缩，但 Performance Monitoring 的字节码插桩和 R8 的优化之间存在已知冲突。

具体表现是，如果启用了 R8 的完整模式（Android Gradle Plugin 8.0+ 默认开启），某些被内联或去虚化的方法可能绕过 Firebase 的插桩点。我在 AGP 8.2.0、R8 8.2.33 的环境下测试，发现某个自定义的 OkHttpClient.Builder 子类在 release 构建后丢失了 FirebasePerfOkHttpClient 的代理包装，导致该构建 variant 下的网络采集完全失效。debug 构建正常，因为 R8 不启用。

排查过程很折腾。先在 release 构建里开启 -printconfiguration 和 -printusage 看 R8 的优化决策，没有直接线索。最后是通过 -keep 规则逐个排除，发现是 OkHttpClient.Builder 的 build() 方法被 R8 内联后，Firebase 的 FirebasePerfOkHttpClient 替换逻辑找不到锚点。解决方案是添加一条 keep 规则：

-keepclassmembers class okhttp3.OkHttpClient$Builder {
    public okhttp3.OkHttpClient build();
}

但这个规则意味着放弃了 R8 对 build() 方法的内联优化，在其他调用点可能有微小的性能损失。Firebase 官方文档在"Performance Monitoring with R8"章节只提到"可能需要 keep 规则"，没有给出具体清单。这个坑我花了将近一天才定位，如果项目网络层封装更复杂，排查时间会更长。

控制台的延迟与数据可信度

采集之后是上报，上报之后是控制台展示。这个链路的延迟直接影响问题排查的效率。

实测从事件产生到控制台可见，中位数延迟是 4-6 小时。官方文档说"up to 24 hours"，实际比这个上限快，但 4 小时对于线上故障排查依然太慢。我对比过 Firebase Analytics 的实时事件（约 1 分钟延迟）和 Crashlytics 的崩溃上报（约 2-5 分钟），Performance Monitoring 的延迟明显是另一个量级。

更影响使用的是数据采样率。Firebase 控制台默认只展示部分设备的数据，不是全量。这个采样在服务端完成，SDK 侧实际上报了所有事件，但控制台只渲染子集。对于流量较小的应用，可能出现"昨天有数据今天没有"的假象，其实只是采样波动。控制台右上角有个小字"Based on a sampling of data"，很容易忽略。我在一次启动优化复盘会上被问到"为什么某版本启动时间突然变好"，后来发现是该版本用户量小，采样基数不足，中位数被几个异常值拉偏了。

为了获得可信的数据，我现在会额外把关键指标通过自定义 trace 同时上报到内部的数据平台，Firebase 控制台只作为快速浏览的辅助。这个双写方案增加了维护成本，但数据时效性和完整性更有保障。

最终取舍：什么场景值得用

两周的测试下来，我对 Firebase Performance Monitoring 的定位有了更清晰的判断。

对于初创团队或流量中等的应用，它的接入成本确实低，自动采集能覆盖 80% 的基础场景，控制台的可视化也比自研方案省大量前端工作。但有几个前提：网络层相对标准（OkHttp/URLConnection 原生使用，没有复杂封装），对启动耗时的精度要求不高（±200ms 可接受），团队能接受小时级的数据延迟。

对于大型应用或性能敏感的场景，自动采集的开销和不可控性会成为负担。3-6% 的 CPU 占比、额外的 GC 压力、不可调的上报频率、R8 冲突的风险，这些加在一起，不如自研一套精简的 trace 系统。自研方案可以精确控制采样率、上报时机、数据格式，代价是前期开发时间和长期维护成本。

我目前的实践是折中方案：保留 Firebase Performance Monitoring 但关闭自动采集，只用手动自定义 trace 上报最核心的 5-6 个业务指标。这样既能利用 Firebase 的控制台和告警，又把运行时开销压到最低。关闭自动采集的配置是：

<meta-data
    android:name="firebase_performance_collection_enabled"
    android:value="false" />

然后在代码里按需启动特定 trace。这个模式下，SDK 的初始化开销依然存在（FirebasePerfProvider 还是会跑），但运行时几乎没有额外负担。我对比过完全移除 SDK 和仅关闭自动采集的启动时间，差距在 5ms 以内，可以接受。

如果 Google 未来把 Performance Monitoring 的自动采集做成更细粒度的开关（比如单独关闭网络采集但保留启动时间），或者开放上报间隔的配置，这个方案的性价比会更高。现在的版本，控制力还是弱了一些。

关于开销的数据，我把完整的测试脚本和原始 Profiler 记录放在了一个内部仓库里，有兴趣深入对比的朋友可以基于同样的方法跑一遍。不同设备、不同网络环境、不同应用架构下的数字会有差异，但量级关系应该是一致的。性能优化这件事，最终还是要用自己的数据说话，而不是依赖厂商文档里的"minimal overhead"这种模糊承诺。