量化Canvas渲染开销需聚焦帧时间稳定性、CPU绘制耗时分布、内存行为模式三类指标：盯单帧是否超20ms而非平均FPS；统计Canvas API调用频次与耗时乘积；监控GC触发的内存抖动。
要量化Canvas图形渲染开销，不能只看“卡不卡”，得用可测量、可复现的数据说话。核心是盯住三类相互关联但又各自独立的指标：帧时间稳定性、CPU绘制耗时分布、内存行为模式。它们分别对应“是否掉帧”“为什么掉帧”“掉帧是否由GC拖累”。
盯紧帧时间波动，而非平均FPS
60FPS对应16.67ms/帧，但真正影响体验的是单帧是否突破20ms——连续出现3帧＞20ms，人眼就能明显感知卡顿。平均FPS为58，不代表流畅；可能前两帧各耗时8ms，第三帧突然卡在45ms，造成画面撕裂感。
- 用performance.now()配合requestAnimationFrame每帧打点，计算真实帧间隔
- Chrome DevTools中开启“Rendering > FPS meter”，观察实时曲线，重点识别尖峰（spike）而非均值
- 避免用setInterval(16)模拟帧循环——它不与屏幕刷新同步，测出的FPS无参考价值
拆解CPU绘制调用的“隐性开销”
Canvas API每次调用都有固定成本：ctx.fillRect()不只是画一个矩形，还涉及状态校验、坐标转换、抗锯齿判断、像素提交等。高频小调用（如每帧drawImage 200次）比单次大绘制（如一次drawImage含完整地图图块）更伤性能。
- 重写关键方法（如ctx.drawImage）注入计时逻辑，统计每类调用的总耗时与频次
- 关注“调用次数×平均耗时”乘积，例如：1000次fillRect × 0.05ms = 50ms/帧，已超预算
- 在DevTools Performance面板中筛选“CanvasRenderingContext2D”相关条目，定位具体哪行JS触发了长绘制任务
捕捉内存抖动：GC才是静默杀手
看似流畅的动画突然卡顿半秒，大概率是垃圾回收（GC）在后台强制暂停主线程。Canvas场景中，GC常由三类操作触发：反复创建ImageData对象、未释放的离屏Canvas引用、drawImage传入未缓存的临时图像。
- 开启DevTools的“Memory > Record allocation profile”，录制动画过程，查看高频分配对象类型
- 检查是否存在ctx.getImageData()后未复用、或new Image()后未显式赋null
- 用canvas.toDataURL()导出图像属于高开销操作，应避免在动画循环中调用
