Performance API 通过 performance.mark/measurement 精准测量每帧耗时，结合 update/render 分离、帧耗时分布统计（如 p95>25ms）及 DrawCall 关联分析，可准确定位卡顿根源而非仅依赖平均 FPS。
Performance API 本身不直接提供“帧数”这个数值，但它能精准捕获每一帧的起止时间，从而让你可靠地算出 FPS 并判断帧稳定性。关键不是数帧，而是测帧耗时、看分布、找抖动。
用 performance.mark + measure 记录单帧生命周期
在 requestAnimationFrame 回调里打点，把一帧的完整执行过程纳入高精度时间线：
- 回调开头调用 performance.mark('frame-start')
- 所有绘制操作（如 clearRect、drawImage、fill）完成后调用 performance.mark('frame-end')
- 立即执行 performance.measure('frame-duration', 'frame-start', 'frame-end')
这样每帧都会生成一条 type 为 'measure' 的记录，duration 字段就是该帧真实渲染耗时（单位毫秒），精度远高于 Date.now()，也不受系统时钟跳变干扰。
区分逻辑更新与画面渲染，避免误判瓶颈
很多 Canvas 游戏采用固定 TPS + 可变 FPS 架构，逻辑和渲染不同步。只看总帧耗时容易掩盖真实问题：
- 用 update-start / update-end 包裹碰撞检测、状态计算等 JS 逻辑
- 用 render-start / render-end 包裹所有 ctx 调用
- 分别 measure update-duration 和 render-duration
如果 update-duration 稳定但 render-duration 波动大，说明卡顿来自 DrawCall 过多或 canvas 状态频繁切换；反之则需优化 JS 执行效率。
统计帧耗时分布，识别卡顿而非只看平均值
FPS 数值本身意义有限，真正影响体验的是帧耗时的离散程度：
- 每 100 帧收集一次 performance.getEntriesByType('measure') 中 name 为 'frame-duration' 的条目
- 提取所有 duration，计算 min / avg / p95 / max
- p95 > 25ms 或 max > 40ms 就表明存在肉眼可感的卡顿
推荐用 PerformanceObserver 自动监听新 measure 条目，避免轮询开销：
const observer = new PerformanceObserver(list => {for (const entry of list.getEntries()) {
if (entry.name === 'frame-duration') { /* 累计统计 */ }
}
});
observer.observe({ entryTypes: ['measure'] });
关联 DrawCall 数量，定位渲染层瓶颈
帧耗时升高时，需确认是否由绘图命令量激增导致：
- 若使用 LayaAir、PixiJS 等引擎，读取其内部 DrawCall 计数（如 renderer.renderCount）
- 将每帧 DrawCall 数与对应 frame-duration 同步记录
- 做交叉分析：当 DrawCall 翻倍而 frame-duration 同步跃升，基本可锁定是渲染命令过载
这种关联能帮你快速区分是 JS 逻辑慢，还是 canvas 绘制慢，避免盲目优化错误方向。
