分层和合成机制：为什么css动画比JavaScript高效|浏览器篇
# 分层和合成机制：为什么css动画比JavaScript高效
30 秒速记
- 讨论动画效率之前，需要先理解浏览器渲染引擎的分层与合成机制，因为它们构成了相关性能优化的底层背景。
- 分层和合成是
Chrome团队重点优化的渲染技术，用来理解浏览器如何组织并生成最终画面。 - 分析
CSS动画和JavaScript动画，不能只比较语法或调用方式，还要追踪它们在底层渲染流程中的差异。 - 标题提出
CSS动画通常更高效，但当前片段只交代了分析入口，没有提供可用于断言具体触发阶段或性能边界的细节。
CSS 动画并非天然比 JavaScript 高效，真正决定成本的是动画属性会触发布局、绘制，还是主要停留在合成阶段。 例如修改 left 往往会影响布局，而使用 transform 更有机会复用已绘制的图层纹理。JavaScript 配合 requestAnimationFrame() 更新 transform，每帧逻辑足够轻时也可能很流畅。工程上应通过性能面板观察 Layout、Paint 和长任务，不能只凭动画写法下结论。
本文我们主要讲解渲染引擎的分层和合成机制，因为分层和合成机制代表了浏览器最为先进的合成技术，Chrome 团队为了做到这一点，做了大量的优化工作。了解其工作原理，有助于拓宽你的视野，而且也有助于你更加深刻地理解 CSS 动画和 JavaScript 底层工作机制。
原理拆解： 页面生成画面通常会经历样式计算、布局、绘制、分层以及合成等环节。渲染引擎会根据滚动、变换、透明度等需求，把部分内容组织成可独立处理的合成层；层内容被栅格化后，合成器可以调整层的位置或透明度并组合最终画面。某项属性变化要走多长的链路，才是判断动画成本的关键：修改几何尺寸可能使布局失效，修改背景可能要求重绘，而某些 transform、opacity 动画在满足条件时主要由合成阶段处理。
具体例子： 让元素水平移动时，持续改变 left 往往会影响布局位置，并可能连带后续节点；使用 transform: translateX() 不改变正常布局中的几何占位，更有机会复用已经绘制的层纹理。声明为 CSS transition 或 @keyframes 后，浏览器还可能在主线程繁忙时由合成相关线程推进可合成动画。JavaScript 也能用 requestAnimationFrame() 修改 transform，因此性能差异并不由“使用 CSS 还是 JavaScript”单独决定，而由属性、执行线程、每帧工作量和失效范围共同决定。
边界与反例： CSS 动画若驱动 width、height、top 或复杂绘制属性，仍可能反复触发布局或绘制；JavaScript 若只更新可合成属性且每帧逻辑很轻，也可能保持流畅。will-change 只是优化提示，滥用会增加图层、显存和管理成本。元素是否独立成层属于浏览器实现决策，不能仅凭样式规则作绝对判断，不同浏览器和版本也可能采用不同启发式策略。
工程验证： 可在开发者工具的性能记录中观察动画期间是否持续出现 Layout、Paint 和长任务，并开启绘制闪烁或图层视图确认失效区域。对比实验应保持元素数量、持续时间和运动轨迹一致，分别测试 left、transform、CSS 动画与 requestAnimationFrame()。若帧率下降，还应检查主线程脚本、图片栅格化、阴影滤镜和层面积，而不是只替换动画语法。
面试官追问
追问 1代码评审中，动画负责人说把 left 动画改写成 CSS @keyframes 后就一定比 JavaScript 流畅，你会如何反驳？
不能只按语法或语言判断性能，持续修改 left 仍可能让布局失效，并连带后续绘制与合成。真正关键的是属性变化经过多长的渲染链路；JavaScript 配合 requestAnimationFrame() 更新可合成属性，也可能保持流畅。
追问 2一个横向滑动组件包含数百个子节点，目前每帧修改 left，主线程持续出现布局任务，你会怎样改造并验证？
可优先尝试用 transform: translateX() 表达位移，因为它不改变正常布局中的几何占位，更有机会复用已绘制的层纹理。改造后应录制相同轨迹和时长，对比 Layout、Paint 与帧时间；是否进入独立合成仍由浏览器决定。
追问 3动画从修改 transform 改成动态调整 width，同时设备刷新率提高，原先流畅的方案还能沿用吗？
不能假定原方案仍然成立，width 变化可能反复触发布局及后续阶段，而更高刷新率还会缩短每帧可用时间。应重新检查失效范围和每帧工作量；即使改用 CSS transition，布局属性的成本也不会自动消失。
追问 4线上弹窗只做 opacity 动画却仍掉帧，开发者工具还显示主线程长任务和大面积图层，你会按什么顺序排查？
先确认动画期间是否持续发生 Layout、Paint 或脚本长任务，再检查元素是否具备可合成条件以及图层面积。还要关注图片栅格化、阴影滤镜和合成成本；opacity 更有机会走合成阶段，但并不保证整个页面没有其他瓶颈。
追问 5为修复卡顿，团队准备给页面上所有动画元素添加 will-change，另一方坚持完全不用，你会选择哪种策略？
应只对确有合成收益且经过验证的热点元素谨慎使用 will-change，而不是全量添加或一概拒绝。它只是优化提示，浏览器仍决定是否分层；滥用会增加图层数量、显存占用和管理成本，反而可能恶化性能。
追问 6面试官让你把样式计算、布局、绘制、分层和合成串到一个移动动画案例里，你会如何解释 transform 的优势边界？
修改几何位置可能让布局失效，随后还可能发生绘制、栅格化与合成；已绘制内容若能独立成层，transform 则更有机会只调整层的位置并完成合成。优势取决于分层和失效范围，不能据此断言所有 transform 动画都不会重绘。
# 显示器是怎么显示图像的
30 秒速记
- 显示器按固定刷新频率读取前缓冲区中的图像；常见示例是
60 Hz，即每秒读取约60次。 - 显卡负责合成新画面，并先把结果写入后缓冲区，而不是直接修改显示器正在读取的前缓冲区。
- 一帧合成完成后，系统交换前、后缓冲区，使显示器在下一次读取时获得更新后的画面。
- 通常显卡更新节奏会与显示器刷新节奏配合；若复杂场景导致单张图像处理变慢，新画面无法及时供应，用户就可能看到卡顿。
60 Hz是原文采用的常见设备示例，不代表所有显示器都固定为该刷新率。
显示器按固定刷新频率扫描前缓冲区，显示系统则在后缓冲区准备新画面，完成后再交换两者。 这样可以让画面的生产和显示并行进行，并尽量避免一次扫描混入两帧内容。以 60 Hz 为例，每帧预算约为 16.7 ms；若新帧没赶上刷新点，屏幕只能继续显示上一帧，用户就会感到卡顿。刷新率不等于应用帧率，主线程长任务、布局和绘制过慢同样可能让画面无法及时提交。
每个显示器都有固定的刷新频率，通常是 60HZ，也就是每秒更新 60 张图片，更新的图片都来自于显卡中一个叫前缓冲区的地方，显示器所做的任务很简单，就是每秒固定读取 60 次前缓冲区中的图像，并将读取的图像显示到显示器上。
那么这里显卡做什么呢？
显卡的职责就是合成新的图像，并将图像保存到后缓冲区中，一旦显卡把合成的图像写到后缓冲区，系统就会让后缓冲区和前缓冲区互换，这样就能保证显示器能读取到最新显卡合成的图像。通常情况下，显卡的更新频率和显示器的刷新频率是一致的。但有时候，在一些复杂的场景中，显卡处理一张图片的速度会变慢，这样就会造成视觉上的卡顿。
原理拆解： 一帧画面可以理解为“生产”和“消费”并行进行：显示器按照自身刷新周期扫描当前可显示的前缓冲区，GPU 或显示系统则在后缓冲区准备下一帧。新帧完成后，缓冲区通常在垂直同步时机切换，避免显示器一次扫描混入两帧内容。以 60 Hz 为例，每帧预算约为 16.7 ms；120 Hz 的预算则约为 8.3 ms，刷新率越高，留给浏览器和显卡生成一帧的时间越短。
具体例子： 页面滚动或动画开始后，浏览器先完成样式计算、布局、绘制等工作，再把可合成的图层交给合成线程与 GPU 形成最终画面。如果某一帧在刷新点前准备完成，它可以在下一周期显示；如果计算耗时超过帧预算，显示器只能继续展示上一帧，动画就会出现停顿。若未采用同步交换，缓冲区在扫描过程中发生变化，还可能产生同一屏幕上下部分属于不同帧的“画面撕裂”。
边界与排查： 显示器刷新率不等于应用帧率，60 Hz 屏幕也可能只获得 30 FPS 的新内容；高刷新率屏幕同样不能让耗时任务自动变快。卡顿也不一定是显卡算力不足，主线程中的长任务、布局和绘制都可能让画面迟迟无法提交。可在浏览器性能面板录制交互，检查帧时间、主线程长任务、绘制与合成耗时；再切换不同刷新率或降低页面复杂度，对比是否仍持续错过刷新周期。
面试官追问
追问 1线上大屏标称 60 Hz，开发者因此断言应用必然能稳定输出 60 FPS，但复杂图表滚动时明显停顿，你怎么解释？
60 Hz 只表示显示器通常每秒扫描约六十次前缓冲区，不保证应用每次都能及时生产新帧。若主线程、绘制、合成或显卡处理超过约 16.7 ms 的帧预算，显示器只能继续展示旧画面，因此刷新率与应用帧率不能画等号。
追问 2代码评审中有人说显卡会边生成新图像边覆盖显示器正在读取的内容，面对动画撕裂现象，你会怎样纠正这段描述？
正常的双缓冲路径是显示器读取前缓冲区，显卡或显示系统在后缓冲区准备下一帧，完成后再交换两者。交换通常选择垂直同步时机以避免一次扫描混入两帧；若缺少同步交换，才可能出现上下区域属于不同帧的撕裂。
追问 3同一页面从 60 Hz 显示器迁移到 120 Hz 设备，产品认为刷新率翻倍后动画自然更流畅，你会提醒什么约束？
120 Hz 的单帧预算约为 8.3 ms，比 60 Hz 的约 16.7 ms 更紧，页面必须更快准备好新画面。高刷新率只提高显示机会，不会让主线程任务、布局、绘制或显卡计算自动加速；持续超时仍会丢帧。
追问 4一个数据大屏动画掉到约 30 FPS，运维直接归因于显卡性能不足，你会用浏览器工具先排除哪些路径？
应先录制交互并检查帧时间、主线程长任务、布局、绘制和合成耗时，确认新帧究竟卡在提交前还是合成阶段。再降低页面复杂度或切换刷新率做对比；只有证据指向栅格化或合成瓶颈时，才适合进一步怀疑显卡压力。
追问 5视频墙方案在关闭同步交换以降低等待和保留垂直同步之间发生选型冲突，你如何说明两者的代价？
保留同步交换能让缓冲区在合适的刷新时机切换，降低一次扫描读取到两帧内容的风险。放松同步可能减少部分等待，却可能产生画面撕裂；具体延迟收益和设备行为需要实测，现有材料不足以保证关闭同步一定更快。
追问 6面试官要求你把浏览器渲染流水线和前后缓冲区串起来解释一次页面滚动，怎样描述才不会把责任都推给 GPU？
滚动开始后，浏览器可能先执行样式计算、布局和绘制，再将可合成图层交给合成线程与 GPU 形成后缓冲区的新画面。若任一前置阶段错过刷新点，显示器都会继续扫描前缓冲区中的旧帧；因此卡顿可能来自主线程，也可能来自栅格化或合成。
