17370845950

游戏循环应使用 requestAnimationFrame 实现与浏览器刷新率同步的高效渲染，通过 delta time 保证逻辑稳定，结合页面可见性控制、帧率限制、性能优化及多线程处理，并借助开发者工具监控真实帧表现。

游戏循环的核心是用 requestAnimationFrame 替代 setInterval 或 setTimeout，它能与浏览器刷新率同步，天然支持 60fps（或更高），同时在页面不可见时自动暂停，省电又高效。

用 requestAnimationFrame 构建稳定主循环

每次回调都应计算自上一帧以来的经过时间（delta time），用于物理更新和动画插值，避免因帧率波动导致速度不一致。

• 在回调函数内执行“更新逻辑 → 渲染画面”两步，不要阻塞主线程
• 记录上一帧的时间戳（performance.now()），当前帧减去它即为 delta time（单位毫秒）
• 若需固定逻辑更新频率（如每 16.67ms 更新一次物理），可累积 delta time 并多次更新，避免“掉帧累积误差”

控制渲染节奏：跳帧与帧率上限

不是所有游戏都需要满帧渲染。对策略类或文字冒险游戏，锁定 30fps 可降低 CPU 占用；而动作游戏则应尽量贴近设备最大刷新率。

• 通过比较当前时间与目标帧时间间隔，决定是否跳过本次渲染（但保持逻辑更新）
• 使用 document.hidden 检测页面可见性，隐藏时暂停循环，恢复时重置时间戳
• 避免在循环中做大量 DOM 操作或未优化的 canvas 绘图——把绘制拆分为脏矩形、复用 canvas 2D 上下文、启用硬件加速（will-change: transform）

减少卡顿的关键实践

卡顿往往来自单帧耗时超标（>16ms），而非循环本身。重点在于让每一帧轻量、可预测。

• 将复杂计算（如路径寻路、AI 决策）拆分到多帧完成，用状态机逐步推进
• 用对象池管理频繁创建/销毁的游戏对象（如子弹、粒子），避免垃圾回收抖动
• 用 Web Workers 处理纯计算型任务（如地图生成、物理预演），不阻塞渲染线程

监控与调试真实帧表现

别只信理论值。用浏览器开发者工具的 Performance 面板录制运行过程，关注“Frames”轨道中的绿色长条（每帧耗时），红色标记表示超时。

• 在循环中记录并打印平均帧率（如每秒统计一次 frameCount）
• 用 console.timeLog 标记关键阶段（update / render），快速定位瓶颈
• 在低端设备上测试：开启 Chrome 的“Throttling”模拟 4x slowdown，观察是否出现持续掉帧