一、渲染帧率监控概述
大家好，我是做渲染性能优化的工程师。今天咱们聊聊帧率监控这件事。说实话，这玩意儿看着简单，里面的坑可不少。
帧率，说白了就是每秒画面刷新的次数。单位是 FPS（Frames Per Second）。你玩游戏卡不卡，看视频流不流畅，全靠它。
为什么需要帧率监控？
我遇到过很多团队，产品上线前才想起来测帧率。结果发现低端机掉帧严重，改都来不及。这里我把核心原因拆开说：
- 定位卡顿根因：到底是渲染管线瓶颈，还是 JS 计算阻塞？帧率曲线会告诉你。
- 量化优化效果：改了一行代码，帧率从 30 涨到 55。没有监控，全是感觉。
- 避免负面体验：卡顿超过 100ms，用户就会烦躁。咱们得做到心里有数。
- 适配多端差异：同一页面在 iPhone 14 跑 120fps，在千元安卓只有 20fps。不监控，怎么发现？
我个人习惯，项目立项时就埋好帧率打点。等上线再补，数据就不完整了。
帧率与用户体验的关系
你以为 60fps 和 30fps 只是数字差别？不，差远了。
| 帧率区间 | 用户感知 | 典型场景 |
|---|---|---|
| 60fps 以上 | 极度流畅，滑动如丝 | 原生 App 主界面 |
| 30~60fps | 轻微掉帧，可以接受 | 列表快速滚动 |
| 15~30fps | 明显卡顿，影响操作 | 复杂动画、游戏 |
| 15fps 以下 | 无法使用，幻灯片一样 | 极端重负载 |
你想想看，用户点击按钮，100ms 内没反应就会觉得“卡”。而一帧的预算只有 16.67ms（60fps）。如果渲染超过这个时间，就会出现掉帧。连续掉帧超过 3 帧，用户就会觉得“这 App 好烂”。
我记得有个项目，页面加载一个 5MB 的 JSON，解析耗时 200ms，直接导致帧率跌到 5fps。用户反馈一片骂声。所以，监控不能只看平均值，要看 掉帧次数 和 卡顿时长。
监控的基本原则
做监控不能瞎搞。我总结了几条底线原则，大家参考：
- 低侵入：监控代码不能拖慢主流程。采集自己不能成为性能瓶颈。我之前见过有人用
setInterval每秒采样上千次，结果监控本身就把帧率拉低了。嗯，这里要注意：采样间隔建议在 50ms~200ms 之间。 - 分层设计：从底层到顶层，分为数据采集、数据聚合、可视化展示。每层独立，方便替换。比如底层用
requestAnimationFrame记录时间戳，上层用 Web Worker 计算统计量。 - 采样合理性：不要所有帧都记录。记录关键帧、掉帧时刻、操作起始帧即可。否则数据量爆炸。
- 上报策略：不能每帧都发网络请求。攒一批（比如 100 帧或 1 秒），用
sendBeacon或低优先级请求上报。 - 异常兜底：当帧率长时间低于 20fps，建议降级渲染（比如关闭阴影、降低分辨率）。监控不能只测不治。
核心原则总结
- 采集开销 < 0.1ms
- 上报间隔 >= 1s
- 告警阈值：连续 1 秒低于 30fps
- 数据保留：本地缓存 10 分钟，超过自动丢弃
💡 我个人小技巧：在监控中增加一个“帧间隔标准差”指标。单看平均值有时候会骗人——平均 50fps，但方差很大，用户依然觉得卡。标准差低才说明稳定。
⚠ 注意：不要在 requestAnimationFrame 回调中做太多计算。我曾经在里面做了个 console.log，结果每次打印都额外消耗 0.3ms，累积起来帧率从 60 掉到了 55。别小看这个。
帧率监控的知识体系
下面这张图，把帧率监控的核心要素串起来了。你一看就明白。
小结
帧率监控不是搞个数值就完事的。你得理解它背后的意思：为什么掉帧？用户感受如何？怎么采不伤性能？这些是基本功。后面咱们会深入讲采集、计算、上报的模块化设计。先把原则记住了，后面才不会踩坑。