4、布局抖动（Layout Thrashing）：强制同步布局的罪与罚

说实话，在界面移植的坑里，布局抖动是我栽过最多次的一个。它不像内存泄漏那样慢慢蚕食性能，也不像死循环那样直接卡死——它更像一个幽灵，在你觉得动画已经很流畅的时候，突然给你来一下肉眼可见的「顿挫」。

我最早意识到这个问题，是在一次把 Web 端的卡片列表移植到 Flutter 的时候。Web 端跑得挺顺，一上移动端就掉帧。我盯着 Profile 工具看了半天，发现每一帧的 Layout 阶段都在 8ms 以上，而绘制只有 2ms。嗯，问题出在布局上。

什么是布局抖动？

布局抖动，英文叫 Layout Thrashing。说白了就是：你在同一帧里反复触发强制同步布局。

正常情况下，浏览器或渲染引擎会把布局计算推迟到下一帧统一处理。但如果你在 JavaScript 里先读了一个布局属性（比如 offsetHeight），然后又写了一个样式（比如 element.style.height = '100px'），引擎就不得不立即重新计算布局——因为它怕你接下来又要读。

一次两次还好，要是循环里这么搞，那每一帧的布局计算就会被拆成几十次小计算，每次都要重新走一遍样式解析、布局树构建、盒模型计算。帧率不崩才怪。

罪魁祸首：强制同步布局

强制同步布局（Forced Synchronous Layout）是布局抖动的直接原因。我习惯把它比作「排队插队」：本来大家都排好队等下一帧统一处理，你非要插队问一句「我现在多高？」，那队伍就乱了。

来看一个典型的反面例子：

// ❌ 布局抖动：读-写-读-写 交替
const items = document.querySelectorAll('.item');
for (let i = 0; i < items.length; i++) {
  const height = items[i].offsetHeight;  // 读
  items[i].style.height = (height + 10) + 'px';  // 写
  const width = items[i].offsetWidth;   // 读（再次触发布局）
  items[i].style.width = (width + 10) + 'px';   // 写
}

这个循环里，每次迭代都触发了两次强制同步布局。如果列表有 100 个元素，那就是 200 次布局计算。你想想看，一帧只有 16ms，光布局就吃掉大半，动画怎么可能不卡？

为什么移植场景更容易触发？

我在做界面移植时发现，布局抖动在移植项目中尤其常见。原因有三：

1. 框架差异：从 Web 到 Flutter，或者从 React Native 到原生，布局模型不同。Web 的流式布局和 Flutter 的约束布局，对「读布局属性」的时机要求完全不一样。
2. 代码搬运：很多开发者直接把 Web 端的 DOM 操作逻辑搬到新平台，忘了新平台的布局计算机制可能更敏感。
3. 动画叠加：移植时经常要同时跑多个动画，每个动画都可能触发布局读取，叠加起来就是灾难。

如何检测布局抖动？

检测布局抖动，我一般用两个工具：

工具	方法	关键指标
Chrome DevTools Performance	录制一段操作，看 Layout 事件是否密集出现	Layout 事件数量 > 元素数量 × 2
Flutter DevTools Timeline	查看每一帧的 Build 和 Layout 耗时	Layout 耗时 > 5ms 且频繁出现
React Native Profiler	查看 Native 线程的布局计算时间	布局时间占比 > 30%

我个人习惯在 Performance 面板里勾选「Layout Shift Records」，它能直接标出哪些操作触发了强制同步布局。嗯，这个功能救过我很多次。

解决方案：读写分离

解决布局抖动，最核心的思路就四个字：读写分离。把所有「读布局属性」的操作集中到一块，所有「写样式属性」的操作集中到另一块，中间不要交替。

还是刚才的例子，改一下就好了：

// ✅ 读写分离：先读后写
const items = document.querySelectorAll('.item');
const heights = [];
const widths = [];

// 第一阶段：只读
for (let i = 0; i < items.length; i++) {
  heights.push(items[i].offsetHeight);
  widths.push(items[i].offsetWidth);
}

// 第二阶段：只写
for (let i = 0; i < items.length; i++) {
  items[i].style.height = (heights[i] + 10) + 'px';
  items[i].style.width = (widths[i] + 10) + 'px';
}

这样改完之后，整个循环只触发一次布局计算。性能差距有多大？我实测过，100 个元素的情况下，从 200 次布局降到了 1 次，帧率从 25fps 直接回到 60fps。

布局抖动的知识体系

下面这张图是我自己总结的布局抖动知识结构，你可以对照着梳理一下：

移植场景的实战建议

如果你正在做界面移植，我给你三个具体的建议：

• 先梳理布局依赖：在移植前，把原代码里所有读取布局属性的地方列出来。比如 offsetWidth、scrollHeight、getBoundingClientRect() 这些。然后看看能不能用 ResizeObserver 或 IntersectionObserver 替代。
• 用 CSS 动画代替 JS 动画：CSS 动画天然不会触发布局抖动，因为浏览器知道你在动画，会提前优化。我在移植时，只要能用 CSS 实现的动画，绝不用 JS 去算位置。
• 善用 will-change：给动画元素加上 will-change: transform 或 will-change: opacity，告诉浏览器提前准备合成层。这样动画过程中就不会触发布局计算了。

总结

布局抖动说白了就是「读写打架」。你读一下布局属性，引擎就得算一次；你写一下样式，引擎又得算一次。如果在一帧里反复这么搞，帧率不崩才怪。

解决它也不难：先读后写，批量操作。把所有的读集中到一块，所有的写集中到另一块。就这么简单，但效果立竿见影。

我记得有一次帮一个团队优化移植项目，他们一个列表滚动动画卡得不行。我一看代码，循环里读了 5 次布局属性，写了 3 次样式。改成读写分离后，帧率从 18fps 直接跳到 58fps。那个开发小哥当场就愣住了——他没想到问题出在这么「低级」的地方。

嗯，有时候性能优化就是这样，不是多高深的技术，而是把基础的事情做对。