Web 可视化卡顿的归因方法论：以"流畅一段、停顿一下"为例的代码级根治
引言
在toTacview系统的实时和回放两种模式下，场景对象移动总是很奇怪：平滑跑一会儿，突然停一下，然后又接着平滑。事件密集的时候------比如导弹接连发射------这种"顿挫"感尤其明显，而且在两种模式下都能稳定复现。
一开始我觉得这是渲染性能问题，模型太多、GPU 扛不住嘛，三维场景卡顿不是家常便饭？但真去查才发现，跟单帧算力一点关系都没有，问题出在调度层。本文完整记录本次问题的排查链路与代码级修复方案，方便后续遇到同类问题快速定位。
一、先怀疑渲染，结果被数据打脸
周期卡顿，第一反应肯定是渲染成本高------模型面数太多、帧率上不去、GPU 饱和。这个直觉非常自然，几乎所有人上来都会往这想。
我当时也这么干，先盯着单帧渲染耗时看。结果对不上：被遮挡那段时间，场景活跃区单帧渲染成本大概 19ms，离浏览器渲染天花板还远得很；setTimeout 心跳也一直很稳。如果真的是算力瓶颈，帧间隔应该整体被拉长、而且是持续恶化才对；但实际看到的形态是"大部分正常，隔一阵子跳一次"，完全不是资源透支的样子。
这里踩了个小教训：性能问题别一上来就假设"渲染太贵"，先把调度证据------帧间隔、心跳时序------采下来再说。预设立场很容易带着整个排查方向跑偏。
二、真正的线索：浏览器把 rAF 掐到了 1Hz
光看单帧不够，我用 CDP 把 requestAnimationFrame（rAF）和 setTimeout 两条定时路径的触发间隔分别录下来对比。结果一出来，问题就藏不住了：
-
requestAnimationFrame回调每隔约 1000ms 才空转一次（被压到 ~1Hz），其余时间还是正常的约 16ms； -
setTimeout从头到尾稳在约 16ms，纹丝不动。
这两条路径在遮挡场景下的节流行为是不对称的。Chrome（以及大部分 Blink/Gecko 内核）对"被遮挡或切到后台"的标签页，会把 rAF 从屏幕刷新率直接降到 ~1Hz 省电；但同场景下的普通定时器路径还活着。
而我这套系统，偏偏有两处关键推进都挂在 rAF 上：
- 仿真时间推进 ：引擎 tick 由 rAF 驱动，每 tick 用
wallDelta = min(now - lastWall, 0.1)去推 simTime。rAF 被钳到 1Hz 后，一秒才 tick 一次，wallDelta又被 0.1s 上限卡着 → simTime 每秒只往前走 0.1s，等于仿真时间基本停了。 - 场景出帧：Cesium 默认渲染循环就是 rAF 驱动的。不管引擎发了多少次渲染请求，只要窗口被挡住，画布出帧就被浏览器锁死在 ~1Hz。
这两件事叠在一起------时间轴冻住、画面定格------合成出来的就是用户看到的"平滑一段、停顿一下"。
三、为什么不直接改浏览器启动参数
定位到根因之后，最快的解法其实是给 Chrome 加启动参数 --disable-backgrounding-occluded-windows，实测加上之后卡顿立刻消失，肉眼上完全正常。
但这条路不能走。这是用户运行环境的事，你没办法要求所有使用者都改浏览器配置、加启动参数------交付给客户的系统总不能让人家先改注册表吧？判断一个修复能不能落地，标准很简单：代码里能不能无条件成立。答案是否定的，就得回头找代码级方案，别指望用户替你适配。
四、修复：把推进和渲染都从 rAF 上解下来
既然知道了遮挡下 rAF 掉到 1Hz、而 setTimeout 还稳在 16ms，那就顺着这个不对称来------把两条链路都迁到 setTimeout 上。
4.1 仿真时间推进：tick 从 rAF 换成 setTimeout
引擎基类里的 _scheduleTick，改用 setTimeout(fn, 1000/60) 排下一次 tick，周期取 60Hz（约 16.67ms）。这个频率足够撑住平滑插值，也远高于遮挡场景下被钳到的 1Hz，不会跟着浏览器的节流策略一起飘。句柄还是存在原来的字段里，取消逻辑也不用动。
wallDelta 继续用 performance.now() 实测算，原来那套时间推进的不变量------followLive 下界 floor、上界 clamp、每帧必达------都没有破坏。
4.2 场景出帧：Cesium rAF 循环换成定时渲染泵
新增了一个 ManualRenderPump：
-
viewer.useDefaultRenderLoop = false：先把 Cesium 默认的（rAF 驱动）渲染循环关掉； - 用一个
setTimeout泵（默认 16ms）每周期调一次 viewer.render()； - 跟
requestRenderMode的按需出帧配合：有没消费的渲染请求才真出帧，没请求就空转（零 GPU 开销），出帧频率和渲染调速器的请求频率完全对齐； - 这里有个坑 ：本来想拿
scene.renderRequested当门控判断要不要出帧，结果发现这个属性在不同 Cesium 版本里并不是统一公开的布尔 getter------实测部分版本读出来是 undefined，泵会直接傻住完全不渲染。所以最后干脆无条件调 render，让 Cesium 内部自己判断该不该真出帧。
4.3 接线
bash
const scene = new CesiumScene()
scene.initialize({ Cesium, viewer, requestRenderMode: true })
const renderPacingGovernor = new RenderPacingGovernor(viewer.scene)
renderPacingGovernor.start()
// 定时渲染泵：关闭 Cesium 默认 rAF 渲染循环，改由 setTimeout 泵按需出帧
const renderPump = new ManualRenderPump(viewer, { intervalMs: 16 })
renderPump.start()五、验证
改完不能拍脑袋说好了，先写契约测试复现问题，再验证修复。我把"rAF 被钳到 1Hz"这个模拟环境当成测试笛卡尔：
| 契约 | 旧实现（rAF 驱动） | 修复后 |
|---|---|---|
| 遮挡下 simTime 按墙钟推进 | 每 1s 推进 0.1s（< 0.5 判失败） | sim≈wall（1.29s/1.30s），PASS |
| 遮挡下渲染泵按需出帧 | 渲染约 1 次 | 渲染 ≥20/s（实测 38.4），PASS |
跑 npm run verify 零 error，全量测试通过，没有回归。真机上模拟遮挡场景复测，simTime 按实时推进、画面跟着延续，周期性停顿确实没了。
六、边界与收尾
边界要说清楚。 如果窗口被完全藏到"连定时器都被节流到 1Hz"的程度------比如最小化到系统托盘------那推进和渲染照样会掉到 ~1Hz，这是所有 Web 应用都躲不开的浏览器硬上限，不在这个方案的覆盖范围里。本文修的是更常见的一种：窗口被别的窗口盖住了，但定时器还活着。
回头看整个排查过程，有三条经验值得记一下：
- 调度类异常先把帧间隔、心跳时序采清楚再归因，别急着扣"渲染慢"的帽子；
- 靠用户环境的修复没法交付，代码里能自洽解决的就别甩给使用者；
- rAF 和 setTimeout 的节流路径在遮挡下不对称------凡是需要持续推进的循环，优先押 setTimeout。