17370845950

游戏循环应使用requestAnimationFrame而非setInterval，以对齐屏幕刷新率、省电且稳定；需分离更新与渲染，用固定时间步长累积deltaTime并保留余量，避免逻辑帧率波动；update只改状态，render只负责绘制；须清理raf防止内存泄漏。

游戏循环的核心是 requestAnimationFrame，不是 setInterval

用 setInterval 驱动游戏帧更新会导致时间漂移、卡顿、掉帧不可控。浏览器原生的 requestAnimationFrame 会自动对齐屏幕刷新率（通常是 60Hz），并能在标签页非激活时暂停调用，省电又稳定。

常见错误是把游戏逻辑和渲染混在同一个 requestAnimationFrame 回调里，导致逻辑帧率被渲染拖累。理想做法是分离「更新」和「渲染」：

• 用固定时间步长（如 16.67ms）累积时间，只在达到阈值时执行一次 update()
• 每次 requestAnimationFrame 都执行 render()，不管逻辑是否更新
• 用 performance.now() 获取高精度时间戳，避免 Date.now() 的毫秒截断误差

如何实现带时间补偿的固定逻辑帧率

真实帧率波动不可避免，直接按每帧 16.67ms 更新会导致加速或减速。必须做时间差累积 + 剩余时间保留。关键点：

• 目标帧时间为 1000 / 60 ≈ 16.666... ms，记为 TARGET_FRAME_TIME
• 每次回调用当前时间减去上一帧时间，得到 deltaTime
• 把 deltaTime 累加到 accumulator，再循环执行 update() 直到 accumulator
• 最后把剩余的 accumulator 留给下一帧，避免时间丢失

const TARGET_FRAME_TIME = 1000 / 60;
let lastTime = performance.now();
let accumulator = 0;
function gameLoop(currentTime) {
const deltaTime = currentTime - lastTime;
lastTime = currentTime;
accumulator += deltaTime;
while (accumulator >= TARGET_FRAME_TIME) {
update(TARGET_FRAME_TIME); // 固定步长更新
accumulator -= TARGET_FRAME_TIME;
}
render(); // 每帧都渲染，利用最新状态
requestAnimationFrame(gameLoop);
}
requestAnimationFrame(gameLoop);

立即学习“Java免费学习笔记（深入）”；

为什么不能在 update() 里直接修改 DOM 或 Canvas 坐标

DOM 操作和 Canvas 绘制本身不耗时，但若在 update() 中触发重排（offsetTop、getComputedStyle）或频繁创建绘图路径，会打断渲染流水线，造成隐式同步开销。更严重的是：如果 update() 耗时超过 16ms，就会挤占 render() 时间，导致画面撕裂或跳帧。

• 所有状态变更（如 player.x += speed * dt）应在 update() 中完成
• 所有绘制指令（ctx.fillRect()、element.style.left）必须只出现在 render() 中
• 避免在 update() 中调用 console.log、alert 或任何可能触发微任务/宏任务的操作

cancelAnimationFrame 必须在页面卸载或暂停时显式调用

即使用户切走标签页，requestAnimationFrame 在部分旧版浏览器中仍可能继续触发（尤其配合 Web Workers 时）。没清理会导致内存泄漏、后台 CPU 占用升高，甚至影响其他页面性能。

• 监听 visibilitychange 事件，在 document.hidden === true 时调用 cancelAnimationFrame
• 在组件销毁（如 React useEffect 清理函数、Vue beforeUnmount）中保存并清除 requestId
• 不要依赖浏览器自动暂停——Safari 15.4 之前、某些 WebView 环境下行为不一致

最易被忽略的是：游戏暂停（pause）状态 ≠ 循环停止。暂停时应保留 lastTime 和 accumulator，等恢复后继续累积，否则 resume 会瞬间补一大段逻辑更新，角色瞬移或判定错乱。