上周帮一个朋友调Canvas小游戏的Bug现象相当诡异同一份Flappy Bird风格的游戏代码在我这台165Hz高刷屏笔记本上跑小鸟下落的速度明显比公司那台60Hz显示器上快一大截。一开始怀疑是游戏内物体速度参数被改了查了一圈发现根本不是真正的原因特别基础——动画主循环里把位移写成了每帧移动固定像素没有对时间做归一化。高刷屏一秒钟执行的帧数是60Hz屏的接近三倍速度自然被放大了。类似的问题在Canvas动画、H5游戏、网页交互特效里非常常见。很多人做动画时觉得画面能跑起来就完事了一遇到为什么这台电脑上游戏这么快/这么慢为什么动画一卡一卡的为什么后台切回来物体瞬移了就懵。其实这些问题的根源都指向同一个地方帧率没有控制好。这篇文章就集中聊一聊Canvas动画里控制FPS的几种实用技巧包括最基础的时间戳跳帧、固定时间步长、动态降级以及我在实际项目里踩过的坑。内容偏实战附带的代码都是可以直接拿去用的。1. 先搞清楚FPS到底在控什么setInterval做游戏主循环的坑很多人一说控制帧率第一反应是让动画跑慢一点或者让每秒执行次数少一点。这个理解方向不算错但太片面了。真正控制帧率的目的有两个一是限制最高频率防止设备负载过高、功耗过大二是稳定逻辑步调保证物理模拟、位移、碰撞在任意设备上表现一致。后者往往更关键。1.1 一个真实场景超级玛丽复刻版为什么在高刷屏上加速了先回头看开头那个例子。用Canvas复刻经典横版过关游戏时最直观的写法是这样的function loop() { player.x 3; // 每帧向右移动3像素 if (player.x canvas.width) { player.x 0; } render(); requestAnimationFrame(loop); }在60Hz屏幕上这行代码每秒执行60次玩家角色每秒向右移动180像素。在165Hz屏幕上每秒执行165次角色每秒移动495像素。游戏整体速度变成原来的2.75倍难度瞬间拉满。同一个帧位移量在不同刷新率设备上表现完全不同这跟游戏代码逻辑本身没关系纯粹是帧率没有归一化导致的。解决思路其实一句话就能说清位移量不能按每帧多少像素算要按每秒多少像素算。也就是引入时间增量deltaTime后面会详细讲。这也是为什么说任何帧率控制方案都绕不开时间度量。1.2 setTimeout做动画主循环的三个坑聊控制帧率之前得先把setTimeout和setInterval这两个常见但问题很多的方案讲透。我知道现在很多教程还在用setInterval做游戏主循环但实际做项目时建议直接绕开它原因有三个。第一个坑定时器回调不是精确的。浏览器里的setTimeout和setInterval在嵌套层级超过5层以后最低延迟会被钳制到4ms而且回调的执行时间会被JavaScript主线程的任务排队影响。你设置16ms间隔做60FPS动画实际可能跑到20ms、25ms甚至更久。动画速度会忽快忽慢。第二个坑后台标签页被节流。用户切到别的标签页时浏览器会把定时器的回调频率大幅降低有些浏览器甚至直接暂停。很多游戏页面切出去再切回来时角色位置已经彻底偏离了预期。第三个坑跟显示器的刷新机制不同步。显示器是60Hz刷新每16.7ms扫一次屏幕。setInterval的回调随机落在刷新周期的任意位置如果不小心在两次刷新的中间执行了绘制画面就会出现撕裂或卡顿感。这个缺陷是结构性的跟你怎么调时间参数都无关。1.3 那么我们要的控制帧率到底是什么把上面两个问题摊开之后目标就清晰了。一套合格的帧率控制方案需要做到几件事动画更新频率尽量跟随浏览器的渲染节奏而不是人为制造一个定时器物体位移、物理更新速度必须依赖真实流逝的时间而不是依赖帧数在帧率过高时主动限制渲染频率避免无效绘制浪费GPU在帧率过低时要么降低渲染质量要么保证逻辑不出错切换后台再回来时不能出现时间突变导致的场景瞬移。后续的几种技巧本质都是围绕这几件事展开的。2. requestAnimationFrame 增量时间所有帧率控制方案的地基不管最终选哪种帧率限制方案requestAnimationFrame下文简称rAF都是最靠谱的主循环入口。它的回调时机由浏览器的渲染机制驱动在每次屏幕完成刷新前执行天然跟显示器的刷新周期同步。2.1 rAF的运行机制rAF的回调函数会收到一个DOMHighResTimeStamp参数表示当前帧的开始时间单位是毫秒。浏览器会尽量让这个回调频率跟屏幕刷新率一致60Hz屏幕上就是每秒大约60次120Hz屏幕上就是每秒大约120次。有个细节值得注意页面处于后台或不可见状态时rAF会自动暂停回调不再触发这就等于是浏览器帮你做了后台节流可以省下大量性能开销。对于做游戏和特效的人来说这是好事但也带来一个副作用——页面从后台恢复时时间轴会出现一段真空期如果处理不好就是后面要说的deltaTime爆炸问题。2.2 deltaTime让速度跟时间走不跟帧走deltaTime指的是这一帧离上一帧过去了多少时间。最简单的帧率归一化写法是这样let lastTime 0; const PLAYER_SPEED 300; // 帧率无关像素/秒 function loop(timestamp) { // timestamp是rAF回调传入的当前时间戳单位毫秒 const delta lastTime ? (timestamp - lastTime) / 1000 : 0; lastTime timestamp; // 防止切后台后delta过大导致瞬移 const dt Math.min(delta, 0.1); // 位移只跟时间相关 player.x PLAYER_SPEED * dt; update(dt); render(); requestAnimationFrame(loop); } requestAnimationFrame(loop);这里所有速度参数都以秒为单位位移就是速度乘以时间间隔。60Hz屏幕上一帧delta约0.0167秒玩家运动约5像素165Hz屏幕上一帧delta约0.006秒玩家运动约1.8像素。两者每秒总位移都是300像素速度表现完全一致。这个写法直接解决了开篇那个加速Bug。注意其中的Math.min(delta, 0.1)这是对delta的最大值钳制防止页面从后台切回来时一帧的时间跨度过大导致角色瞬间穿过整个屏幕。2.3 逻辑更新与渲染分离帧率控制做久了你会发现把代码拆成update(dt)和render()两个独立函数非常有必要。逻辑更新负责计算位置、碰撞、状态变化渲染负责把当前状态画到Canvas上。拆开之后你可以自由决定逻辑更新每帧都跑但渲染每2帧才跑一次或者逻辑更新固定60次/秒渲染跟显示器刷新率走。这种灵活性是后面几种帧率控制技巧能落地的前提。如果不拆所有代码揉在一起想限制FPS就只能整段跳过物理和绘制一起卡顿。function frame(timestamp) { requestAnimationFrame(frame); const dt getDelta(timestamp); update(dt); // 物理和游戏逻辑一般每帧都跑 render(); // 绘制逻辑可按需跳过 }3. 技巧一时间戳跳帧法把最大FPS限定在目标值第一种实用的帧率控制技巧是时间戳跳帧法思路非常直接渲染前先检查距上次渲染过了多久如果没到目标帧间隔就直接跳过渲染只更新逻辑。这样能把实际渲染频率限制在一个上限内。3.1 核心思路和代码实现假设目标FPS是30那么理论上每帧间隔约33.3ms。代码上维护一个累计时间戳当累计时间小于目标间隔时不渲染大于等于目标间隔时才执行一次渲染const TARGET_FPS 30; const FRAME_INTERVAL 1000 / TARGET_FPS; // 约33.3ms let lastTime 0; let accumulated 0; function loop(timestamp) { requestAnimationFrame(loop); const delta lastTime ? timestamp - lastTime : 0; lastTime timestamp; // 逻辑更新每帧都做保证游戏速度稳定 update(delta); // 累计流逝的时间 accumulated delta; // 还没到目标帧间隔跳过渲染 if (accumulated FRAME_INTERVAL) { return; } // 到达渲染时机消耗掉这段时间 accumulated 0; render(); } requestAnimationFrame(loop);这段代码的精髓在于update每帧都跑render按需跑。物体移动和碰撞计算完全不受跳帧影响只是画面刷新频率降低了。30FPS的渲染频率下人眼感知到的流畅度通常会明显低于60FPS但对于一些非游戏场景比如图表动画、海报特效、粒子背景已经完全够用。3.2 为什么跳帧不跳逻辑这么重要我见过很多人实现帧率限制时直接把整个requestAnimationFrame回调都跳过了也就是帧间隔不到就不执行任何代码。这样做的副作用是逻辑更新也被一起降频了。举个例子目标30FPS帧间隔33.3ms。正常逻辑下角色每秒移动300像素。如果逻辑更新也跟着渲染一起被跳过那么渲染的频率确实是30FPS了但角色每帧移动距离如果还是按固定值算就会变成每秒只移动150像素。游戏速度直接减半。正确做法就是上面代码里的结构update永远以真实时间delta运行render才受帧间隔限制。这样才能做到画面降帧率但速度不变。3.3 时间戳跳帧法适合什么场景它节省的主要是渲染开销包括Canvas绘制指令、重绘造成的GPU负载、复杂滤镜和阴影的计算。如果页面里跑的是粒子系统、数据可视化动画这类渲染成本高但逻辑简单的场景用这个方法把最大FPS压在30或45功耗和发热改善非常明显。实测过一个Canvas粒子背景页面在60Hz屏幕上原本稳定60FPSCPU占用接近20%。用时间戳跳帧法把渲染频率限制到30FPS后CPU占用降到8%肉眼几乎察觉不到动画变卡。这类场景没什么物理模拟需求跳帧让update和render一起分组也没问题但为了统一习惯还是建议保持update独立。4. 技巧二固定时间步长与渲染插值物理稳定优先的方案时间戳跳帧法适合逻辑简单的场景但一旦涉及到物理模拟、碰撞检测、平台跳跃这类需要精确帧步长的游戏它就不够用了。原因在于delta是实时变化的这会导致物理模拟的计算步长忽长忽短进而出现弹跳高度不稳定、穿透碰撞体等问题。4.1 可变deltaTime为什么会破坏物理模拟简单说物理模拟方程的稳定性和步长强相关。固定步长下重力加速度、碰撞响应、积分计算都能保持统一的精度。步长一变同样的物理参数跑出来的轨迹就可能不一样。比如一个跳跃动作在60Hz屏幕上如果一帧delta是16ms在低端机上可能变成35ms物理积分精度不同角色跳起的高度就不一样了。这个差异用肉眼能直接看出来。固定时间步长的思路是不管真实帧间隔是多少物理引擎一律按固定的步长更新比如1/60秒。真实时间没走够一个步长就等一等走过了就追几帧直到追上为止。4.2 accumulator累加器的实现细节实现时需要一个累加器把每帧多出来的时间存起来一次一次消耗const FIXED_TIMESTEP 1000 / 60; // 固定逻辑步长16.67ms const MAX_FRAME_SKIP 5; let previousTime 0; let accumulator 0; let alpha 0; function loop(timestamp) { requestAnimationFrame(loop); let frameTime timestamp - previousTime; previousTime timestamp; // 限制单帧时间防止切后台回来进入死亡循环 if (frameTime 250) { frameTime 250; } accumulator frameTime; let stepCount 0; while (accumulator FIXED_TIMESTEP stepCount MAX_FRAME_SKIP) { // 固定步长更新逻辑dt是固定的0.0167 update(FIXED_TIMESTEP / 1000); accumulator - FIXED_TIMESTEP; stepCount; } // 供渲染插值使用表示当前时刻在两个逻辑帧之间的进度 alpha accumulator / FIXED_TIMESTEP; render(alpha); } requestAnimationFrame(loop);update里的delta永远是1/60秒。即使真实帧间隔是35ms累加器也会把35ms拆成2次16.67ms更新 剩余1.66ms存起来下一帧继续消耗。物理引擎每次计算的步长完全一致输出稳定。4.3 alpha插值让渲染平滑固定时间步长有个副作用物理逻辑更新的频率是60Hz但屏幕刷新可能是60Hz、120Hz或其他频率渲染出来的画面时间点不一定跟逻辑更新完全对齐会出现微小的位置跳变。解决方法是渲染时根据alpha做一次位置插值。要理解插值先明确上次逻辑更新时玩家在位置A下次逻辑更新时在位置B。渲染时真实的逻辑进度不一定是0或1可能处在0.3、0.5这样的中间位置。插值就是根据alpha把位置修正到AB之间的合适位置function render(alpha) { // 清理画布 ctx.clearRect(0, 0, canvas.width, canvas.height); // 用上一状态和当前状态插值渲染 const x player.prevX (player.x - player.prevX) * alpha; const y player.prevY (player.y - player.prevY) * alpha; ctx.fillRect(x, y, 40, 40); }没有插值时画面上的物体看起来会有一点点微抖尤其在120Hz屏幕上跑60Hz逻辑更新时抖动会比较明显。加插值后渲染位置平滑过渡观感立刻顺滑。4.4 螺旋死亡保护固定时间步长方案里最容易翻车的是螺旋死亡某一帧实际耗时特别长比如GC停顿、资源加载frameTime异常大while循环里要追很多次逻辑更新才能把累加器消耗完结果这一帧本身就更卡累加器积压更严重恶性循环。所以代码里必须有MAX_FRAME_SKIP上限比如单帧最多执行5次逻辑更新剩下的时间直接丢弃。再有就是frameTime的上限钳制我习惯钳到250ms。两者的目的相同不管卡顿多严重都不能让逻辑追帧把性能拖垮。游戏世界里的时间可以迟到但不能崩溃。5. 技巧三动态降级——设备性能不足时的自动调速前面几种方案解决的是帧率太高怎么限制和帧率波动怎么稳定实际项目里还会遇到第三种情况设备性能不足目标FPS跑不满。这时候硬撑60FPS只会让画面持续卡顿不如主动降低目标帧率或者降低渲染质量让动画流畅起来。5.1 用EMA平滑值判断真实FPS要判断设备性能是否不足需要实时监控FPS。直接看单帧时间不准因为偶尔的GC或网络抖动会带来假性掉帧所以通常对FPS做平滑处理。EMA指数移动平均是比较轻量且好用的方案let emaFPS 60; let lastTime performance.now(); const SMOOTHING 0.1; function getSmoothFPS(timestamp) { const delta Math.max(timestamp - lastTime, 1); lastTime timestamp; const instantFPS 1000 / delta; // 一阶低通滤波新值只占10%权重历史值占90% emaFPS emaFPS * (1 - SMOOTHING) instantFPS * SMOOTHING; return emaFPS; }SMOOTHING取0.1时FPS跟踪不会太激进能过滤掉偶发卡顿。太低会反应迟钝设备已经持续低帧了还拿不到反馈建议在0.05到0.2之间调整。5.2 分档降负载的设计得到平滑FPS后就可以按档位调整渲染质量了。我习惯把质量和帧率绑成一套配置质量档位目标FPS粒子数量阴影/模糊绘制缩放高60200开启1.0中45120关闭0.8低3060关闭0.6切换逻辑可以这样组织const QUALITY_LEVELS [ { maxFPS: 60, particles: 200, shadow: true, scale: 1.0 }, { maxFPS: 45, particles: 120, shadow: false, scale: 0.8 }, { maxFPS: 30, particles: 60, shadow: false, scale: 0.6 } ]; let currentLevel 0; function applyQuality() { const level QUALITY_LEVELS[currentLevel]; targetFPS level.maxFPS; particleCount level.particles; ctx.shadowBlur level.shadow ? 10 : 0; canvas.style.transform scale(${level.scale}); }降级后动画的流畅度感受是明显提升的。宁可用30FPS稳定顺畅也不要60FPS一路卡顿这是所有实时图形项目的基本原则。5.3 迟滞切换避免频繁抖动降级逻辑里很容易犯的错是FPS稍微掉下来就降档稍微恢复就升档结果在边界来回横跳画面一会儿清晰一会儿模糊体验反而很差。需要引入迟滞判断下降时连续一段时间低于阈值的80%才降档上升时要持续更长时间稳定在阈值的125%以上才升档let lowStart 0; let highStart 0; function checkQuality(emaFPS) { const level QUALITY_LEVELS[currentLevel]; const threshold level.maxFPS; if (emaFPS threshold * 0.8) { lowStart lowStart 0 ? performance.now() : lowStart; if (performance.now() - lowStart 2000 currentLevel QUALITY_LEVELS.length - 1) { currentLevel; applyQuality(); lowStart 0; highStart 0; } } else { lowStart 0; } if (emaFPS threshold * 1.25) { highStart highStart 0 ? performance.now() : highStart; if (performance.now() - highStart 10000 currentLevel 0) { currentLevel--; applyQuality(); highStart 0; lowStart 0; } } else { highStart 0; } }降档判断2秒升档判断10秒这是一个比较保守的配置。游戏场景可以更快视觉展示类可以更保守。6. 帧率监控与开发期诊断帧率控制做得好不好不能靠猜必须靠数据。开发期我会在页面上挂一个实时的FPS监控器主要看两个指标瞬时FPS和长任务耗时。6.1 轻量级FPS监控器一个简单的Canvas上屏监控器用一组环形数组记录最近120帧的时间戳每帧统计平均帧率const FPS_BUFFER_SIZE 120; const frameTimes []; function trackFPS(timestamp) { frameTimes.push(timestamp); if (frameTimes.length FPS_BUFFER_SIZE) { frameTimes.shift(); } if (frameTimes.length 2) { return 0; } const totalTime frameTimes[frameTimes.length - 1] - frameTimes[0]; const averageFPS ((frameTimes.length - 1) / totalTime) * 1000; return averageFPS; }把它输出到页面左上角或控制台每次跑起来先观察几秒钟。如果平均FPS始终低于目标帧率就需要用动态降级方案降档运行如果FPS峰值远高于目标帧率就用时间戳跳帧法限制上限避免资源浪费。6.2 长任务与掉帧的排查手段单纯看FPS数字不够还要知道卡顿发生在哪里。PerformanceObserver可以监听主线程的长任务最直接的反应就是界面卡了一下const observer new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (entry.duration 50) { console.warn(检测到长任务耗时, entry.duration, ms); console.log(开始时间, entry.startTime); } } }); observer.observe({ entryTypes: [longtask] });通常我在对比帧率波动时会把长任务日志和帧率时间线放在一起看。比如降帧的瞬间大概率对应一个几百毫秒的长任务那问题多半出在某个同步计算或资源解析上可以考虑拆成异步或者用Web Worker处理。6.3 dev tools性能面板不能只看平均值Chrome Performance面板的FPS图也需要跟代码对应着看。很多新手喜欢只看平均FPS这不合理因为一帧卡顿100ms对平均FPS的影响很容易被其他流畅帧稀释。看FPS面板要看红色区块那代表发生了长时间的主线程阻塞再结合上面的长任务日志定位到具体函数。7. 实战踩坑记录高刷屏、切后台和定时器漂移最后这部分内容大部分来自实际项目里的惨痛教训比前面的理论知识更值得记一下。7.1 120Hz屏幕上的加速问题上面提到过如果不做deltaTime归一化高刷屏上游戏会加速。反过来如果做了deltaTime归一化还得注意另一个问题requestAnimationFrame在高刷屏上的回调频率是120Hz甚至更高如果你用固定时间步长方案限制逻辑60Hz渲染仍然会跑到120Hz此时渲染插值的alpha就有意义了。实测144Hz屏幕上跑固定时间步长插值的Canvas游戏玩家移动平滑度跟60Hz屏差异很小。但如果没有插值物体运动会出现规律的抖动。所以只要目标平台存在高刷屏插值这一步不要省。7.2 visibilitychange切后台回来瞬间的位置瞬移页面切到后台后rAF暂停切回来时rAF恢复但performance.now()仍在继续走导致恢复后的第一帧timestamp - lastTime非常大可能是一秒甚至几分钟。如果不处理deltaTime直接爆炸角色直接瞬移、粒子直接飞散。我的处理方案是监听visibilitychange页面隐藏时记录一个标记重新可见时重置lastTime和累加器并把这一帧的delta按0处理document.addEventListener(visibilitychange, () { if (document.hidden) { isPageHidden true; } else { isPageHidden false; lastTime 0; // 重置时间戳 accumulator 0; // 重置累加器 } });再加上前面代码里Math.min(delta, 0.1)的双保险。这两个措施同时做切换后台后回来基本不会出现位置突变。7.3 性能计时以performance.now()为准很多做动画的开发者习惯用Date.now()来算时间差这在帧率控制场景下是不太严谨的。Date.now()基于系统时钟最小分辨率也不是毫秒级而且可能被系统校时等操作调整。performance.now()是基于页面加载时间的高精度时钟不会被系统时间调整影响语义上更适合测量两帧之间的精确时间差。requestAnimationFrame回调里的timestamp参数本身就是从performance.now()来的所以直接用这个参数就行完全没必要自己再去调Date.now()或额外调一次performance.now()。还有一个容易被忽略的点计时器漂移。rAF的timestamp虽然精确但长时间运行后累计的帧间隔误差可能让游戏时间跟真实时间产生偏移。比如你做了一个30秒倒计时靠累加每帧delta来递减跑了10分钟后倒计时可能偏出去几百毫秒。对游戏时间敏感的场景建议用独立的performance.now()快照跟起始时间做差值而不是累加delta。const gameStartTime performance.now(); function getGameTime() { // 用绝对时间差计算避免逐帧累加的漂移 return (performance.now() - gameStartTime) / 1000; }累加delta适合做物理模拟的步长控制绝对时间差值适合做计时器。搞清楚两者分工帧率控制方案才不会把自己绕晕。8. 一个拿来就能用的综合示例把前面的方案整合成一个较完整的Canvas动画骨架覆盖了deltaTime归一化、固定时间步长、渲染插值和基础的FPS监控可以直接作为新项目的起点const canvas document.getElementById(gameCanvas); const ctx canvas.getContext(2d); const FIXED_TIMESTEP 1000 / 60; const MAX_FRAME_SKIP 5; const MAX_DELTA_MS 250; let previousTime 0; let accumulator 0; let alpha 0; const ball { x: 50, y: 200, prevX: 50, prevY: 200, vx: 200, // 像素/秒 vy: 0, radius: 20 }; const GRAVITY 500; // 像素/秒² function update(dt) { ball.prevX ball.x; ball.prevY ball.y; ball.vy GRAVITY * dt; ball.x ball.vx * dt; ball.y ball.vy * dt; // 简单地面碰撞 if (ball.y ball.radius canvas.height) { ball.y canvas.height - ball.radius; ball.vy * -0.8; } // 左右边界反弹 if (ball.x - ball.radius 0 || ball.x ball.radius canvas.width) { ball.vx * -1; } } function render(interpolationAlpha) { ctx.clearRect(0, 0, canvas.width, canvas.height); // 坐标插值让渲染位置跟随真实渲染时机 const renderX ball.prevX (ball.x - ball.prevX) * interpolationAlpha; const renderY ball.prevY (ball.y - ball.prevY) * interpolationAlpha; ctx.beginPath(); ctx.arc(renderX, renderY, ball.radius, 0, Math.PI * 2); ctx.fillStyle #4a90d9; ctx.fill(); } function loop(timestamp) { requestAnimationFrame(loop); let frameTime timestamp - previousTime; previousTime timestamp; if (frameTime MAX_DELTA_MS) { frameTime MAX_DELTA_MS; } accumulator frameTime; let stepCount 0; while (accumulator FIXED_TIMESTEP stepCount MAX_FRAME_SKIP) { update(FIXED_TIMESTEP / 1000); accumulator - FIXED_TIMESTEP; stepCount; } alpha accumulator / FIXED_TIMESTEP; render(alpha); } requestAnimationFrame(loop);这个示例里update永远按60Hz步长推进渲染时用alpha平滑插值地面反弹逻辑稳定crash后也不会因为峰值delta导致球直接飞到屏幕外。想要限制最大渲染帧率在render外面套一层时间戳跳帧判断即可。做Canvas动画这些年最大的体会是渲染可以省逻辑不能乱。帧率控制不是简单的每秒会跑多少次而是逻辑用固定节奏推进渲染按设备能力自适应。时间戳跳帧适合轻量降频固定时间步长适合物理稳定动态降级适合性能兜底三者按需组合使用就好。如果只记一条实践经验的话那就是开发时永远开着FPS监控别等用户反馈卡顿了你才去复现。
