关键是要将帧耗时、丢帧位置、主线程阻塞原因三者串联分析：用requestanimationframe精确采集帧耗时，维护60帧滑动窗口计算p95值；结合performanceobserver捕获longtask定位阻塞源头；再通过chrome渲染流水线阶段（script/style/layout/paint/composite）区分js执行、样式重算或绘制合成等不同卡顿类型。
监控前端运行时帧率波动，关键不是只看 FPS 数字，而是把帧耗时、丢帧位置、主线程阻塞原因三者串联起来分析。单纯显示“当前 42fps”没有诊断价值，必须定位到具体哪段 JS、哪个样式计算或哪次布局触发了掉帧。
用 requestAnimationFrame 精确采集帧耗时
RAF 天然绑定浏览器渲染周期，比 setInterval 更可靠。核心逻辑是记录连续两帧的时间差，并维护滑动窗口做统计：
- 每次 RAF 回调中调用 performance.now() 记录时间戳，与上一帧差值即为本帧耗时
- 保留最近 60 帧（约 1 秒）的耗时数组，实时计算移动平均值和 P95 值
- 当单帧耗时 >33ms（即低于 30fps）且连续出现 ≥3 次，标记为“卡顿区间”
- 结合 document.hidden 过滤后台标签页数据，避免干扰
关联长任务（longtask）定位阻塞源头
帧率骤降往往对应主线程被长时间独占。Chrome 提供原生 longtask 观测点，能直接捕获 >50ms 的执行块：
- 在页面加载早期注册 PerformanceObserver，监听 entryTypes: ['longtask']
- 每条记录含 duration、startTime 和 attribution（可定位到具体脚本、框架甚至行号）
- 将 longtask 时间段与卡顿区间对齐：若某次掉帧前 100ms 内发生 80ms 长任务，大概率就是它导致的
- 注意：未注册前的初始化长任务会丢失，建议在 最顶部立即执行 observer 注册
区分卡顿类型：JS 执行 vs 渲染开销
同样是 40ms 帧耗时，原因可能完全不同。需结合 Chrome DevTools 的渲染流水线阶段判断：
- JS 执行久：Performance 面板中 “Main” 线程有长绿色块（Script Evaluation），对应 CPU 占用高
- 样式/布局重算久：出现大量黄色 “Recalculate Style” 或红色 “Layout” 块，常见于强制同步布局（如读 offsetTop 后立刻改 class）
- 绘制/合成久：绿色 “Paint” 或紫色 “Composite Layers” 块变长，多由大图、复杂阴影、频繁 canvas 重绘引起
- 线上无法用 DevTools？可通过 Performance.getEntriesByType('measure') 配合自定义 mark（如 mark('before-layout') / mark('after-layout')）做轻量归因
微任务链过载也会影响帧率
微任务虽不触发渲染，但会阻塞下一个 RAF 和用户交互。连续微任务总耗时 >10ms 就可能导致“点了没反应”：
- 对 Promise.prototype.then 和 queueMicrotask 做轻量打补丁，在入口和出口埋点计时
- 重点监控单批次内嵌套深度是否超 10 层，或总耗时是否突破阈值
- 典型场景：状态库批量更新触发数十次响应式依赖通知，或错误地在 then 中循环 resolve 新 Promise
- 上报时带上调用栈前 3 层，便于快速识别是业务代码还是框架内部行为
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
