重绘和重排和回流（重排和重绘的区别）



早在五年前，Google 就提出了 1s 完成终端页面的首屏渲染的标准。

常见的优化网络请求的方法有：DNS Lookup，减少重定向，避免 JS、CSS 阻塞，并行请求，代码压缩，缓存，按需加载，前端模块化…

虽然相较于网络方面的优化，前端渲染的优化显得杯水车薪，而且随着浏览器和硬件性能的增长，再加上主流前端框架（react、vue、angular）的已经帮我们解决了大多数的性能问题，但是前端渲染性能优化依然值得学习，除去网络方面的消耗，留给前端渲染的时间已经不多了。本文主要学习前端渲染相关的问题。

总结为下图：

图片来自

在此过程中，前端工程师主要的敌人为：

重绘与回流

在回流的时候，浏览器会使 render tree 中受到影响的部分失效，并重新构造这部分渲染树，完成回流后，浏览器会重新绘制受影响的部分到屏幕中，该过程成为重绘。因此回流必将引起重绘，而重绘不一定会引起回流。

Reflow 的成本比 Repaint 高得多的多。DOM Tree 里的每个结点都会有 reflow 方法，一个结点的 reflow 很有可能导致子结点，甚至父点以及同级结点的 reflow。

在 chrome 中查看 repaint

F12 打开控制台 -> DevTools -> Show console drawer -> Rendering -> 勾选 Paint flashing。

重绘何时发生

当一个元素的外观的可见性 visibility 发生改变的时候，但是不影响布局。类似的例子包括：outline, visibility, background color。

回流何时发生

浏览器

如果向上述代码中那样，浏览器不停地回流+重绘，很可能性能开销非常大，实际上浏览器会优化这些操作，将所有引起回流和重绘的操作放入一个队列中，等待队列达到一定的数量或者时间间隔，就 flush 这个队列，一次性处理所有的回流和重绘。

虽然有浏览器优化，但是当我们向浏览器请求一些 style 信息的时候，浏览器为了确保我们能拿到精确的值，就会提前 flush 队列。

减少回流重绘

className 只要赋值，就一定出现一次 rendering 计算；classList 的 add 和 remove，浏览器会进行样式名是否存在的判断，以减少重复的 rendering。

假如需要在下面的 html 中添加两个 li 节点：

使用 JavaScript：

上述代码会发生两次回流，假如使用 的方案，虽然能够减少回流次数，但是会发生一次闪烁，这时候使用 DocumentFragment 的优势就体现出来了。

DocumentFragment 有两大特点：

可见 DocumentFragment 是一个孤儿节点，没爹就能出生，但是在需要它的时候，它又无私地把孩子奉献给文档树，然后自己默默离开。是不是有点像《银翼杀手2049》？

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/bcyy/37393.html