来自内部 黄树炫 同学的分享
背景
响应式设计指的是根据屏幕视口尺寸的不同，对 Web 页面的布局、外观进行调整，以便更加有效地进行信息的展示。我们日常生活中接触的很多应用都遵循响应式的设计。
响应式设计如今也成为 web 应用的基本需求，而现在很多 web 应用都已经组件化，这意味着我们如果想要实现响应式的应用，那么我们也需要有某种方式监听 「组件/元素」 大小的变化，以便让 「组件/元素」 也做到响应式。
在 ResizeObserver 出现之前，我们也有一些实现响应式布局的方案，包括：
JS 方案—— window.onresize/window.matchMedia；CSS 方案——媒体查询；
但它们都各自有一些问题。
media query 媒体查询 - CSS 方案
在 CSS 中可以通过媒体查询实现响应式，但 CSS 的媒体查询只能监听全局属性，比如 viewport 的大小、screen 的大小等，并不能监听元素级别的尺寸变化。
而即使 CSS 能够对元素级别进行监听，也会遇到循环引用问题，举个例子，假设我们能够对某个具体元素的宽度进行监听，并写出了以下代码: （注意现在并不支持 :min-width 这样的伪类写法，下面只是伪代码）
.father {
float: left;
}
.child {
width: 500px;
}
.father:min-width(450px) > .child {
width: 400px;
}
因为 .father设置了float: left，所以它的宽度由 子元素 child 的宽度来决定，即一开始时为 500px；如果 .father的宽度为 500px （大于 450px ），那么按照最后一个选择器的写法，子元素宽度应该变为 400px；但当子元素宽度为 400px 时，也会使得外层 father 的宽度变为 400px；因此子元素宽度又会变为 500px，此时循环引用便开始了....
window.resize - JS 方案
resize 事件只有当 viewport 的大小发生变化时会被触发，元素大小的变化不会触发 resize 事件；并且也只有注册在 window 对象上的回调会在 resize 事件发生时被调用，其他元素上的回调不会被调用。
当 「resize」 事件发生后，我们往往需要通过调用 getBoundingClientRect 或者 getComputedStyle 来获取此时我们关心的元素大小，以此判断元素是否发生了变化。频繁调用 getBoundingClientRect 、 getComputedStyle等 API 会导致 「浏览器重排（reflow）」，导致页面性能变差，举个例子：https://codesandbox.io/s/resize-event-5qn3q0?file=/index.html。
调用 getBoundingClientRect 等函数时，浏览器为了保证我们拿到的元素参数是准确的，会触发一次 reflow 来重新布局。频繁地调用以上函数就会导致浏览器频繁重排、重绘，进而导致性能问题的出现。
虽然我们可以通过合并读/写操作，或是采用节流防抖，来减少重绘的次数，但不可避免的，我们至少需要额外调用至少一次 getBoundingClientRect 操作。
而且当 viewport 大小不变，元素大小变化时，此时我们不能通过监听 resize 事件来得知这一变化。比如在元素下 append 了一个新的 children，或者将元素的 display 设为 none，亦或是改变该元素父级节点或是相邻节点的大小，以上这些都有可能在 viewport 大小不发生变化的情况下，导致元素大小改变，而此时通过监听 「resize」 事件我们就没办法感知到这些变化。
window.matchMedia - JS 方案
可以把 matchMedia 理解为 CSS 中媒体查询的JS方案。
和 window.resize 类似，window.matchMedia 也只能监听 viewport 大小的变化；但和 window.resize 会在每次 viewport 大小变化时都触发事件不同，matchMedia 关心的是某些特殊的断点，这往往更符合我们实现响应式网页的实际场景。
举个例子，我们想实现在屏幕宽度小于 1080px 时将三列布局改为两列布局，我们并不希望每次 window 大小变化时通知我们 ，而只希望屏幕在大于或小于某个特定的大小时通知我们即可。这种场景下使用 matchMedia 会比监听 window.resize 要性能更高。
const m = matchMedia('(max-width: 600px)')
m.addEventListener('change',(event)=>{console.log('macth onChange', event)})
小结
方案 | 相同问题 | 特殊问题 |
Media query-CSS | 只能监听viewport变化，不能监听某个 「组件/元素」 大小变化 | 循环引用问题 |
window.resize-JS | 需要在 viewport 大小变化时手动获取元素的大小，可能导致性能问题 | |
window-matchMedia-JS |
以上提到的三种浏览器原生方案都存在着只能监听 viewport 大小变化，而不能监听 「组件/元素」 大小变化的问题。此外，CSS 的媒体查询存在着循环引用的问题，window.onresize 和 window.matchMedia 则都需要在 viewport 大小变化时手动获取元素的大小，一旦操作过于频繁则可能导致浏览器多次 reflow。
ResizeObserver 就是为了解决以上问题而出现的，可以将其理解为 window.onresize 的「组件/元素级别」 的替代方案。使用 ResizeObserver 可以让我们监听到元素大小的变化，无需再手动调用 getBoundingClientRect 来获取元素的尺寸大小，同时也解决了无限回调和循环依赖的问题。
ResizeObserver的使用
API
ResizeObserver.disconnect：取消和结束目标对象上所有对 Element 或 SVGElement 观察； ResizeObserver.observe：开始观察指定的 Element 或 SVGElement； 第一个参数为观察的元素； 第二个参数为可选参数 BoxOptions，用来指定将以哪种盒子模型来观察变动，如 content-box(默认值)，border-box和device-pixel-content-box；ResizeObserver.unobserve：结束观察指定的 Element 或 SVGElement
const ro = new ResizeObserver(entries => {
for (let entry of entries) {
const cr = entry.contentRect;
console.log('Element:', entry.target);
console.log(`Element size: ${cr.width}px x ${cr.height}px`);
console.log(`Element padding: ${cr.top}px ; ${cr.left}px`);
}
});
// Observe one or multiple elements
ro.observe(someElement);
附上 MDN 的两个demo:
Resize observer border-radius test - CodeSandbox：https://codesandbox.io/s/resize-observer-border-radius-test-ztwuyg； Resize observer text test - CodeSandbox：https://codesandbox.io/s/resize-observer-text-test-dktwk1
什么时候触发通知
与我们关注的盒模型有关，ResizeObserver 会根据调用 observe 函数时传递的第二个可选参数 BoxOptions 传入的盒模型参数进行监听，当元素该盒模型变化时触发通知。默认监听 content-box变化以触发监听。
通知内容包括什么
通知的内容包含了足够的信息，以便开发者能够根据当前元素的具体大小信息来作出变化，而不是要开发者重新调用 getComputedStyle、 getBoundingClientRect 来获取。
监听元素：target contentRect contentBoxSize borderBoxSize devicePixelContentBoxSize
需要注意的是，虽然只有当 BoxOptions 关心的盒模型变化时才会触发通知，但实际上通知时会将三种不同盒模型下的具体大小都返回给回调函数，用户无需再次手动获取。
在 React 中使用
为了避免在 React render中多次声明 ResizeObserver 实例，我们可以把实例化过程放在 useLayoutEffect 或 useEffect 中。并且在非 SSR 场景中，我们应该尽量使用 useLayoutEffect 而不是 useEffect。
useLayoutEffect 和 useEffect 的最大差别在于执行时机的不同，useEffect 会在浏览器绘制完成之后调用，而 useLayoutEffect 则会在 React 更新 dom 之后，浏览器绘制之前执行，并且会阻塞后面的绘制过程，因此适合在 useLayoutEffect 中进行更改布局、及时获取最新布局信息等操作。
ResizeObserver 原理
执行时机
先从浏览器渲染流程开始说起，网页渲染会经历以下几个主要过程：
解析 HTML，构建 DOM 树 解析 CSS，生成 CSS 规则树 布局 Layout——合并 DOM 树和 CSS 规则，生成 Render 树 绘制 Paint——绘制 Render 树（paint），绘制页面像素信息
「如果是由我们来设计，我们应该在以上渲染流程中的哪个环境来执行 ResizeObserver 的监听通知会比较合理？」
因为我们在 ResizeObserver 的回调函数中可以（也经常会）根据当前元素的大小来改变 style 或者 dom 树，而这些操作往往都会触发 layout/reflow；因此，应该是在 「布局Layout 和 绘制Paint 之间」来执行回调函数会更加合理。
而如果有多个 ResizeObserver 实例都在回调中进行了改变布局的操作，那么最好的方式就是在所有回调都执行完重新布局，确保得到一个最终准确的布局之后，再来进行绘制 Paint，避免绘制的内容是无效内容。
因此如上图所示，ResizeObserver 的通知会在 Layout 和 Paint 之间进行（图中的 4 Notify），当回调中改变了 Layout 时，则会重新 loop 执行 Animate、RAF、Layout、Notify，直到所有需要被通知的元素都通知完（也可以理解为 loop循环 会在 layout 不再被改变时结束）。
如何判断是否需要通知
每个 ResizeObserver 实例内都有一个 ResizeObservation 对象，ResizeObservation 对象表达了一种订阅监听的关系，并在其中记录了监听的元素（target）、监听的盒模型（即observe函数的第二个参数）、上次通知的值（lastReportedSizes，即上次通知时元素的大小尺寸）
每次 layout 过后，对于监听的每个元素，都会重新计算元素的大小，并与上次通知的大小（lastReportedSizes）进行比较，一旦大小发生变化才会被设置为 active，意味着 「可能」 会被通知。为什么这里提的是 「可能」 ，下面会进行解释。
需要注意的是，内部获取元素的大小是通过调用 getComputedStyle 实现的，那么多次调用 getComputedStyle 会不会导致浏览器频繁 layout/reflow ？
在浏览器触发 reflow 后，所有已有元素位置都会记录快照，只要不再触发位置等变化导致快照失效，那么第二次开始访问位置就不会触发 reflow 当前面的通知回调改变了 Layout 时，下一个 ResizeObserver 实例调用 getComputedStyle 时就有可能导致浏览器 reflow 但此时为了获取准确的元素信息， reflow 是无法避免的；因为不涉及到 绘制paint，所以开销还是可接受的
无限循环
结合上图，我们假设这样的场景，在监听到 「节点1」 宽度变化时，设置 「子孙节点2」 的宽度；而在 「节点2」 宽度改变时，我们对 「节点1」 的宽度进行改变，此时可能又会触发 「节点1」 的监听回调，从而出现无限循环的监关系。
在 ResizeObserver 的回调中对 dom 进行操作，比如改变另外一个元素的大小，或是隐藏/展示某个元素，这些操作可能会导致新的回调调用，引发无限循环，最终导致界面 UI 卡死。上面我们只举三个层级节点的例子作为说明，如果节点监听关系的数量越多、层级越深，那么情况就会更糟。
还有另外一种场景是，在监听函数中创建新的 ResizeObserver 实例，导致循环的每一次迭代都有新的元素需要通知，那么最终循环就会因为内存溢出而终止，这里不作过多讨论。
如果避免无限循环
无限循环的场景是真实存在的，想要避免无限循环的出现，我们需要给循环过程加上一些限制，以此来解除循环。有三种限制策略可以考虑：
执行次数限制 允许执行最多次数 N 次循环，当超过次数 N 时，循环终止 优点是实现简单，并且具有一致性，当这个算法在不同的机器上运行时都能有相同的表现 缺点是 N 的定义太过随意，缺乏比较可靠的结论定义 执行时间限制 循环最多执行 N ms 时长，当超过这个时间时循环终止 虽然听起来实现很简单，但我们无法保证具体会执行多少次调度，在不同性能的机器上，每次执行的时间是不同的，意味着不同的机器执行次数会不同，也可能因此导致不同机器上最终展示的内容不一致 执行深度限制
执行深度限制
设定一次渲染流程中需要通知的元素（指的是和上次通知时的大小 lastReportedSize 相比发生了变化）为集合 N，设定上次迭代的元素最小深度 Depth 为 ∞
当 N 不为空时，开始循环
在一次迭代中，对集合 N 中的所有元素进行通知（并在通知中可能触发重新布局流程），并将 Depth 更新为本次迭代中元素的最小深度 d 将所有小于等于深度 d 的元素移除，更新集合 N——即下次迭代只会对比上次迭代的最浅元素更深的元素进行通知
直到 N 为空时，循环终止，通知结束，开始浏览器绘制 Paint。
通过以上说明，我们也可以意识到在一次循环中，只有满足以下两个条件的元素才会被通知：
上次迭代/Layout过后，元素的大小被改变了 元素的深度比上次迭代的最浅深度更低
「那么深度限制就不存在问题了吗？」
深度限制可能会使得页面展示不是完全准确的，但是相比于页面UI卡死，这个问题对于用户而言是更好接受的。
