移动端H5帧率监控需全链路闭环：一用PerformanceObserver捕获≥50ms长任务定位阻塞根源；二用requestAnimationFrame交叉验证是否真丢帧；三分层节流上报，每30秒聚合≤1.5KB；四按场景设报警阈值，如首屏longtask＞100ms即告警。
移动端 H5 的帧率监控不能只看平均 FPS，必须结合长任务、渲染流水线和用户真实操作做全链路闭环。关键不是“有没有掉帧”，而是“为什么掉帧”以及“是否影响了用户”。
一、用 PerformanceObserver 捕获长任务（主线程阻塞根源）
浏览器将执行超过 50ms 的 JS 任务标记为 longtask，这是导致掉帧的直接原因。必须在 最顶部内联注册，否则首屏关键卡顿会漏捕：
- 启用
buffered: true，可读取注册前已发生的长任务记录 - 只监听
longtask类型，避免混入 resource/mark 增加开销 - 每个 entry 提供
duration（耗时）、startTime（高精度时间戳）、attribution（来源，如主文档或 iframe），便于定位第三方脚本或嵌套内容干扰
二、用 requestAnimationFrame 交叉验证实际帧表现
单靠 longtask 只知道“哪里卡”，但无法确认是否真丢帧。需同步检测渲染帧间隔：
- 连续调用
requestAnimationFrame，记录时间差；若持续 ≥16.7ms（即低于 60fps），且与某 longtask 时间重叠，基本可断定该任务引发掉帧 - 避免仅依赖“连续 3 帧低于 20fps”这类阈值判断——低端设备刷新率本就低，应以 50ms 长任务为锚点，再看其是否造成后续帧延迟
三、分层采集 + 节流上报，避免监控本身成瓶颈
帧率数据高频、量大，生产环境必须轻量可控：
- 开发阶段可用
console.warn输出，生产环境改用navigator.sendBeacon异步发送 - 每 30 秒聚合成一批上报，单次 payload 控制在 1.5KB 内
- 上报字段聚焦核心：longtask duration/startTime/attribution、连续帧间隔序列、设备型号与系统版本（用于归因）
四、设置可落地的性能报警规则
报警不是越早越好，而是要能触发有效干预：
- 单次 longtask > 100ms 且发生在首屏加载阶段（startTime
- 连续 5 帧间隔 ≥ 33.3ms（即 ≤30fps）且伴随用户滚动或点击操作，触发交互卡顿告警
- 同一页面 1 小时内出现 ≥10 次上述任一告警，自动聚合为“页面级渲染稳定性问题”，推送给前端负责人
