Chrome DevTools Rendering面板可定位掉帧元凶：启用Paint flashing和FPS meter可识别重绘区域，Continuous page repainting配合Performance面板能区分script/layout/paint阶段瓶颈，需警惕同步layout、强制回流API及Canvas 2D离屏合成等隐性开销。
Chrome DevTools 的 Rendering 面板能直接暴露掉帧元凶
打开 Chrome，按 Ctrl+Shift+P（Win）或 Cmd+Shift+P（Mac），输入 Rendering，勾选 Paint flashing 和 FPS meter。真实掉帧时，屏幕右上角的 FPS 数字会跌破 60，同时频繁闪动的绿色矩形就是重绘区域——如果整个 canvas 每帧都在闪，说明不是局部更新问题，而是整帧重绘开销过大。
更关键的是开启 Continuous page repainting：它会强制每帧触发一次完整渲染流程，配合 Performance 面板录制，能清晰区分是 script（JS 执行）、layout（布局计算）还是 paint（绘制）阶段耗时超标。
常见误判点：
– requestAnimationFrame 回调里做了 DOM 插入或 class 切换 → 触发同步 layout，卡顿源不在 canvas 本身
– 使用了 getComputedStyle 或 offsetTop 等强制同步回流的 API → 即使只调用一次，也可能打断渲染流水线
– Canvas 2D 上用了 shadowBlur 或多次 globalAlpha 叠加 → 每次绘制都触发离屏合成，GPU 负担陡增
Canvas 2D 绘制性能差，优先检查 drawImage 的参数和图集使用方式
drawImage 是 HTML5 小游戏中最常被滥用的性能黑洞。传入 9 个参数的切片版本（drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh)）比 5 参数版本（drawImage(image, dx, dy, dw, dh)）慢 3–5 倍，尤其当 sx/sy/sw/sh 不是整数时，浏览器需做子像素采样，CPU 解码压力激增。
实操建议：
– 所有精灵图（sprite sheet）切分坐标必须对齐整数像素，用 Math.floor 显式截断浮点坐标
– 同一帧内重复绘制同一张图（如粒子效果），先用 canvas.getContext('2d').createPattern 缓存为 pattern，再用 fillRect 复用
– 避免在每帧中动态创建 Image 或 Canvas 实例；预分配好双缓冲 canvas，用 ctx.drawImage(offscreenCanvas, ...) 替代逐元素重绘
requestAnimationFrame 时间戳不准？别信 event.timeStamp，用 performance.now()
requestAnimationFrame 回调传入的时间戳（rafTime）是相对页面加载的高精度毫秒值，但很多人误用 event.timeStamp（来自 mousemove 等事件）做 delta 计算，这会导致时间跳变甚至负值——因为 event.timeStamp 在某些浏览器中会受系统休眠、tab 切换影响而“倒流”。
