如何使用requestAnimationFrame合理组织HTML5游戏的更新与绘制逻辑？

核心动画循环（animate()）的正确结构 #

标准的实现方式是先调用requestAnimationFrame()注册下一帧，再执行update()和drawing()，代码示例如下：

function animate() {
  // 先注册下一帧，避免因update/drawing耗时导致帧丢失
  requestAnimationFrame(animate);
  
  update();
  drawing();
}

为什么要这么组织？ #

• 把requestAnimationFrame()放在函数最开头，能确保浏览器在当前帧的渲染工作开始前，就已经预定好下一帧的回调，不会因为update()或drawing()的执行耗时，导致错过浏览器的渲染时机，减少丢帧概率。
• 先执行update()更新游戏逻辑，再执行drawing()渲染画面，符合"先计算状态，再绘制状态"的逻辑，避免出现画面和逻辑不同步的问题（比如先画了旧状态，再更新逻辑，会导致视觉延迟）。

适配不同帧率的关键处理 #

不同设备或帧率下的问题，大多是因为逻辑更新依赖帧率导致的。直接按帧更新（比如每帧让角色移动固定像素）会在高帧率设备上移动过快，低帧率设备上移动过慢。解决方法是基于时间差更新：

1. 记录上一帧的时间戳
2. 计算当前帧与上一帧的时间差（deltaTime）
3. 用时间差来缩放逻辑更新的量

示例代码：

let lastTime = 0;

function animate(currentTime) {
  requestAnimationFrame(animate);
  
  // 计算时间差，转换为秒方便计算
  const deltaTime = (currentTime - lastTime) / 1000;
  lastTime = currentTime;
  
  // 传入时间差，让逻辑基于时间更新
  update(deltaTime);
  drawing();
}

// 初始化时调用animate，传入初始时间
function init() {
  lastTime = performance.now();
  animate(lastTime);
}

避免踩坑的注意事项 #

• 不要把update()或drawing()作为requestAnimationFrame()的参数，这会打破循环的连贯性，且无法统一控制帧的调度。
• 不要把requestAnimationFrame()放在update()或drawing()之后，极端情况下（比如渲染耗时超过一帧的时间），会导致浏览器无法及时注册下一帧，出现卡顿。
• 不要嵌套调用animate()，这会导致循环栈溢出，或者出现重复注册帧的问题。

学习资源 #

• HTML5 Canvas官方文档中关于requestAnimationFrame的使用说明，重点理解其与浏览器渲染周期的配合机制。
• 游戏开发入门书籍中的"固定时间步长"与"可变时间步长"章节，这是处理跨帧率逻辑的核心知识点。
• 开源HTML5游戏的源码（比如2D像素类游戏），观察成熟项目的动画循环实现方式。

内容的提问来源于stack exchange，提问作者user20091357