渲染管线：CPU处理阶段、GPU渲染阶段、显示刷新阶段
掉帧的本质，说白了就是每一帧的生产速度赶不上显示器的消费速度。但「生产」和「消费」到底是谁在干活？这就要聊到渲染管线了。
我习惯把渲染管线拆成三段来看：CPU 处理、GPU 渲染、显示刷新。这三段就像一条流水线，任何一段卡住，整条线就得等。而掉帧，就是等出来的结果。
核心认知：掉帧不是单一环节的问题，而是管线中某个阶段耗时超过 16.67ms（60fps 下）导致的连锁反应。
CPU 处理阶段：指挥官的活
CPU 是渲染管线的起点。它负责跑 JavaScript、处理事件、计算布局、生成绘制指令。说白了，CPU 不直接画图，它只负责「告诉 GPU 该画什么」。
这个阶段我踩过最大的坑是什么？JS 执行时间过长。有一次做 H5 游戏，角色移动时频繁触发重排，CPU 单帧耗时飙到 12ms。你想想看，留给 GPU 的时间只剩 4ms，怎么可能不卡？
避坑指南：我曾经在项目中用 requestAnimationFrame 做循环，结果里面塞了个 O(n²) 的碰撞检测。单帧 CPU 耗时直接 20ms+。后来改成空间哈希，降到 2ms。记住：CPU 阶段超过 10ms，掉帧几乎是必然的。
CPU 阶段具体干了三件事：
- JavaScript 执行：事件回调、动画循环、数据更新。这里最容易出问题的是频繁的 DOM 操作和重排。
- 样式计算：浏览器根据 CSS 规则计算每个元素的最终样式。选择器越复杂，耗时越长。
- 布局（Layout）：计算元素的位置和尺寸。触发重排的操作（如读写 offsetTop）会强制同步布局，这是性能杀手。
注意：强制同步布局（Forced Synchronous Layout）是 CPU 阶段最常见的掉帧元凶。比如你在 JS 里先读 offsetHeight，再改 style.height，浏览器会被迫立即执行一次布局。我见过一个页面因为这个操作，单帧 CPU 耗时从 3ms 暴涨到 18ms。
GPU 渲染阶段：画师的活
CPU 干完活，把绘制指令打包发给 GPU。GPU 接过活，开始真正地「画」。
GPU 是并行计算的大杀器。它擅长同时处理成千上万个顶点和像素。但 GPU 也有短板——它怕「太碎」的活。
我记得有一次做粒子系统，每帧要绘制 5000 个独立的小方块。CPU 阶段只用了 2ms，但 GPU 阶段硬是跑了 15ms。为什么？因为每个小方块都是一个独立的绘制调用（draw call），GPU 频繁切换状态，并行优势根本发挥不出来。
GPU 阶段的核心步骤：
- 顶点处理：把 3D 模型的顶点坐标变换到屏幕空间。2D 场景这一步相对轻量。
- 光栅化：把矢量图形转换成像素点阵。这一步决定了最终画面上有多少像素要填色。
- 片段着色：计算每个像素的颜色、纹理、光照。复杂的着色器会显著增加耗时。
- 合成（Compositing）：把多个图层合并成最终画面。图层越多，合成越重。
| GPU 瓶颈类型 | 典型表现 | 常见原因 |
|---|---|---|
| Draw Call 过多 | CPU→GPU 提交指令耗时高 | 大量独立小对象、未合并纹理 |
| Overdraw 严重 | 同一像素被反复绘制 | 透明叠加层过多、未裁剪不可见区域 |
| 纹理过大 | 显存带宽吃满 | 单张纹理 4096×4096 以上、未压缩 |
| 着色器复杂 | 像素填充率下降 | 逐像素光照、后处理特效 |
经验之谈：我个人习惯在 Chrome DevTools 的 Performance 面板里看 GPU 帧耗时。如果 GPU 阶段超过 8ms，我就会检查 Draw Call 数量和 Overdraw 情况。很多时候，合并几个图层就能把 GPU 耗时砍掉一半。
显示刷新阶段：显示器的节奏
CPU 和 GPU 忙活完，画面数据已经躺在显存里了。但显示器不会随时去取——它有自己的节奏。
显示器的刷新率是固定的。60Hz 的显示器每 16.67ms 扫描一次屏幕。这个扫描动作由 VSync（垂直同步） 信号控制。
为什么会掉帧？因为 CPU+GPU 的总耗时超过了 16.67ms。比如这一帧花了 20ms，显示器在 16.67ms 时来取数据，发现上一帧还没画完，就只能把上一帧再显示一遍。这就是掉帧。
更糟糕的情况是 画面撕裂（Tearing）。如果关闭 VSync，显示器可能在 GPU 还没画完一帧时就开始扫描，结果屏幕上同时出现两帧的画面，中间有一条撕裂线。
小知识：我曾经调试一个 120Hz 屏幕上的掉帧问题，发现 GPU 耗时只有 6ms，但帧率死活上不去。后来查出来是 VSync 机制导致 CPU 在等待 GPU 完成时被阻塞了。解决办法是用 requestAnimationFrame 替代 setInterval，让浏览器自己协调帧节奏。
显示刷新阶段的关键点：
- VSync 开启：画面不撕裂，但帧率被锁定在刷新率倍数（60/30/20fps）。如果渲染耗时波动大，会出现明显的卡顿感。
- VSync 关闭：帧率不受限，但画面可能撕裂。适合竞技类游戏，但动画场景一般不推荐。
- Adaptive Sync（FreeSync/G-Sync）：显示器动态匹配帧率，既防撕裂又减少卡顿。这是目前最好的方案。
注意：不要以为帧率超过 60fps 就万事大吉。如果帧率在 55~60fps 之间反复跳动，人眼感知到的卡顿比稳定 30fps 还明显。这叫「帧率抖动」，比稳定低帧更影响体验。
三段管线的协同与瓶颈
三段管线不是串行执行的。现代浏览器和游戏引擎会用 双缓冲 或 三缓冲 来让 CPU 和 GPU 并行工作。
双缓冲的工作方式：
- GPU 在「后缓冲」里画当前帧。
- 显示器从「前缓冲」里读取上一帧。
- VSync 信号到来时，前后缓冲交换。
这样 CPU 和 GPU 可以同时干活。但问题来了——如果 GPU 画得太慢，CPU 提交下一帧时发现后缓冲还被占着，只能干等。这就是 CPU 饥饿。
反过来，如果 CPU 太慢，GPU 画完一帧后没活干，出现 GPU 饥饿。帧率就被 CPU 拖死了。
诊断方法：我常用的办法是在 Chrome DevTools 里录制一段性能数据，看 Frames 时间轴。如果 CPU 和 GPU 之间出现大段空白，说明有一方在等另一方。这时候就要针对性地优化瓶颈端。
总结一下三段管线的核心关系：
| 阶段 | 主要工作 | 常见瓶颈 | 优化方向 |
|---|---|---|---|
| CPU 处理 | JS、布局、绘制指令 | 重排、强制同步布局、JS 计算 | 减少 DOM 操作、使用 transform、批处理 |
| GPU 渲染 | 顶点、光栅、合成 | Draw Call、Overdraw、纹理 | 合并图层、纹理压缩、减少透明层 |
| 显示刷新 | VSync、扫描输出 | 帧率抖动、撕裂 | 启用 Adaptive Sync、稳定帧率 |
理解了三段管线，你就能精准定位掉帧的根源。下一帧卡了？先看是 CPU 慢了，GPU 慢了，还是显示节奏没对上。对症下药，比盲目优化有效得多。