Canvas动画流畅的核心是精准控制绘制时机与工作量，需用requestAnimationFrame配合delta time计算、对象复用、高DPI适配及避免隐式开销。
Canvas 动画要流畅，核心不是“怎么画”，而是“什么时候画”和“画多少”。60fps 是目标，但直接 setInterval 或乱用 requestAnimationFrame 反而掉帧。
为什么 requestAnimationFrame 比 setInterval 更适合 Canvas 动画
requestAnimationFrame 由浏览器调度，自动对齐屏幕刷新周期（通常 60Hz），且在标签页不可见时暂停调用；setInterval 则按固定毫秒硬执行，容易错过帧、累积延迟、白屏时还在跑定时器耗电。
- 使用
requestAnimationFrame时，函数执行时机由浏览器决定，不保证每次间隔正好 16.67ms，但能避免撕裂和卡顿 - 不要在回调里做重计算（如遍历大量对象+复杂物理运算），否则单帧超时，直接掉帧
- 若需固定逻辑更新步长（比如物理引擎），得自己实现时间差分逻辑，不能依赖回调频率
如何正确处理动画时间差（delta time）
用户设备性能不同，requestAnimationFrame 的实际间隔会浮动。靠 Date.now() 或 performance.now() 记录上一帧时间戳，算出真实经过毫秒数，再按比例更新状态。
let lastTime = 0;
function animate(currentTime) {
const deltaTime = currentTime - lastTime;
lastTime = currentTime;
<p>// 例如：物体每秒移动 100px，则这一帧应移动 (deltaTime / 1000) <em> 100
ball.x += (deltaTime / 1000) </em> 100;</p><p>ctx.clearRect(0, 0, canvas.width, canvas.height);
ctx.fillRect(ball.x, ball.y, 20, 20);
requestAnimationFrame(animate);
}
requestAnimationFrame(animate);- 必须用
performance.now()（毫秒精度达微秒级），不用Date.now()，后者可能被系统时钟调整干扰 - 避免把
deltaTime直接用于累加位置而不归一化——比如写成ball.x += deltaTime * 0.1，数值含义模糊且难调试 - 若逻辑更新需稳定步长（如 1/60 秒），可累积
deltaTime后按固定步长多次更新，防止低帧率下动作跳跃
哪些操作最容易导致 Canvas 动画卡顿
卡顿往往不出现在绘图本身，而在“画之前”或“画之外”的隐式开销。
立即学习“Java免费学习笔记（深入）”；
- 频繁创建对象（如每帧 new Array()、{x,y}）→ 触发 GC，造成偶发卡顿；复用数组、对象池更稳
- 读取
canvas.width/canvas.height或ctx.fillStyle等属性 → 强制同步回读，打断 GPU 流水线 - 在动画循环中调用
getBoundingClientRect()、getComputedStyle()→ 触发重排重绘 - 未清空画布就重绘（漏掉
clearRect或用半透明色覆盖）→ 像素叠加导致显存压力上升 - 使用
shadowBlur、globalAlpha、多层drawImage缩放 → 软件渲染 fallback，尤其在低端 Android 上明显
Canvas 尺寸设置与 devicePixelRatio 的关系
高 DPI 屏幕（如 MacBook Retina、iPhone）下，CSS 像素 ≠ 物理像素。若只设 canvas.width=800，但 CSS 设为 width: 800px，浏览器会拉伸 canvas 导致模糊 + 性能下降。
- 先读
window.devicePixelRatio，再按比例放大 canvas 的width/height属性值 - 用 CSS 控制显示尺寸（如
style="width: 800px; height: 600px;"），再用canvas.width = 800 * dpr设置实际缓冲区大小 - 绘图坐标也要乘
dpr，或用ctx.scale(dpr, dpr)统一缩放（注意影响文字渲染） - 忽略
dpr不仅模糊，还会让相同内容在高分屏上渲染更多像素，GPU 填充压力陡增
真正卡顿的点，常藏在看似无害的属性读取、对象分配或尺寸适配里。动效是否流畅，80% 取决于你有没有在每一帧里“少做一点事”。
