• Home
  • home > webfront > browser > webkit >

    浏览器层面优化前端性能(2):Reader引擎线程与模块分析优化点

    Author：zhoulujun Date：

    优化JS的执行效率 降低样式选择器的复杂度 避免大规模、复杂的布局 尽可能避免触发布局 避免强制同步布局事件的发生 避免快速连续的布局 简化绘制的复杂度 减小绘制区域 优先使用渲染层合并属性 控制层数量 节流 抖动

    Reader 引擎线程与模块分析

    20200610161413331600560.pngcss解析流程


    首先是网页内容，加载完输入到HTML解释器，解释后构成DOM树，这期间如果遇到JavaScript代码就交给JavaScript引擎去处理，如果网页中包含CSS，就交给CSS解释器；DOM树简历的时候，渲染引擎接收来自CSS解释器的样式信息，构建一个新的你日不会吐模型，该模型由布局模块计算模型内部各个元素的位置和大小信息

    渲染流程有四个主要步骤：

    1. 解析HTML生成DOM树 - 渲染引擎首先解析HTML文档，生成DOM树

    2. 构建Render树 - 接下来不管是内联式，外联式还是嵌入式引入的CSS样式会被解析生成CSSOM树，根据DOM树与CSSOM树生成另外一棵用于渲染的树-渲染树(Render tree)，

    3. 布局Render树 - 然后对渲染树的每个节点进行布局处理，确定其在屏幕上的显示位置

    4. 绘制Render树 - 最后遍历渲染树并用UI后端层将每一个节点绘制出来

    DOM树与Render树

    DOM树与Render树

    renderer与DOM元素是相对应的，但并不是一一对应，有些DOM元素没有对应的renderer，而有些DOM元素却对应了好几个renderer，对应多个renderer的情况是普遍存在的，就是为了解决一个renderer描述不清楚如何显示出来的问题，譬如有下拉列表的select元素，我们就需要三个renderer：一个用于显示区域，一个用于下拉列表框，还有一个用于按钮。

    另外，renderer与DOM元素的位置也可能是不一样的。那些添加了float或者position:absolute的元素，因为它们脱离了正常的文档流，构造Render树的时候会针对它们实际的位置进行构造。

    布局与绘制

    上面确定了renderer的样式规则后，然后就是重要的显示元素布局了。当renderer构造出来并添加到Render树上之后，它并没有位置跟大小信息，为它确定这些信息的过程，接下来是布局(layout)。

    浏览器进行页面布局基本过程是以浏览器可见区域为画布，左上角为(0,0)基础坐标，从左到右，从上到下从DOM的根节点开始画，首先确定显示元素的大小跟位置，此过程是通过浏览器计算出来的，用户CSS中定义的量未必就是浏览器实际采用的量。如果显示元素有子元素得先去确定子元素的显示信息。

    布局阶段输出的结果称为box盒模型（width,height,margin,padding,border,left,top,…），盒模型精确表示了每一个元素的位置和大小，并且所有相对度量单位此时都转化为了绝对单位。

    在绘制(painting)阶段，渲染引擎会遍历Render树，并调用renderer的 paint() 方法，将renderer的内容显示在屏幕上。绘制工作是使用UI后端组件完成的。

    回流与重绘

    回流(reflow)：当浏览器发现某个部分发生了点变化影响了布局，需要倒回去重新渲染。reflow 会从<html>这个 root frame 开始递归往下，依次计算所有的结点几何尺寸和位置。reflow 几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。通常我们都无法预估浏览器到底会 reflow 哪一部分的代码，它们都彼此相互影响着。


    重绘(repaint)：改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性时，屏幕的一部分要重画，但是元素的几何尺寸没有变。


    关键渲染路径与阻塞渲染

    在浏览器拿到HTML、CSS、JS等外部资源到渲染出页面的过程，有一个重要的概念关键渲染路径（Critical Rendering Path）。

    例如为了保障首屏内容的最快速显示，通常会提到一个渐进式页面渲染，但是为了渐进式页面渲染，就需要做资源的拆分，那么以什么粒度拆分、要不要拆分，不同页面、不同场景策略不同。

    现代浏览器总是并行加载资源，例如，当 HTML 解析器（HTML Parser）被脚本阻塞时，解析器虽然会停止构建 DOM，但仍会识别该脚本后面的资源，并进行预加载。

    • CSS 被视为渲染阻塞资源(包括JS)，这意味着浏览器将不会渲染任何已处理的内容，直至 CSSOM 构建完毕，才会进行下一阶段。

      存在阻塞的 CSS 资源时，浏览器会延迟 JavaScript 的执行和 DOM 构建

      • css加载不会阻塞DOM树的解析

      • css加载会阻塞DOM树的渲染

      • css不会阻塞JS的加载

      • css加载会阻塞后面js语句的执行

    • JavaScript 被认为是解释器阻塞资源，HTML解析会被JS阻塞，它不仅可以读取和修改 DOM 属性，还可以读取和修改 CSSOM 属性。

      • 当浏览器遇到一个 script 标记时，DOM 构建将暂停，直至脚本完成执行(当浏览器遇到一个没有 async 或 defer 属性的 <script> 标签时，它不仅会暂停 DOM 的构建，也会暂停对后续 HTML 标记的解析)。

      • JavaScript 可以查询和修改 DOM 与 CSSOM。

      • CSSOM 构建时，JavaScript 执行将暂停，直至 CSSOM 就绪。

      • 没有js的理想情况下，html与css会并行解析，分别生成DOM与CSSOM，然后合并成Render Tree，进入Rendering Pipeline；但如果有js，css加载会阻塞后面js语句的执行，而（同步）js脚本执行会阻塞其后的DOM解析（所以通常会把css放在头部，js放在body尾）

    CSS 优先：引入顺序上，CSS 资源先于 JavaScript 资源。JavaScript 应尽量少影响 DOM 的构建。




    改变脚本加载次序defer/async/document.createElement

    defer

    defer 属性表示延迟执行引入 JavaScript，即 JavaScript 加载时 HTML 并未停止解析，这两个过程是并行的。整个 document 解析完毕且 defer-script 也加载完成之后（这两件事情的顺序无关），会执行所有由 defer-script 加载的 JavaScript 代码，再触发DOMContentLoaded(初始的 HTML 文档被完全加载和解析完成之后触发，无需等待样式表图像和子框架的完成加载) 事件。

    defer 不会改变 script 中代码的执行顺序，示例代码会按照 1、2、3 的顺序执行。所以，defer 与相比普通 script，有两点区别：载入 JavaScript 文件时不阻塞 HTML 的解析，执行阶段被放到 HTML 标签解析完成之后。

    async

    async 属性表示异步执行引入的 JavaScript，与 defer 的区别在于，如果已经加载好，就会开始执行，无论此刻是 HTML 解析阶段还是 DOMContentLoaded 触发(HTML解析完成事件)之后。需要注意的是，这种方式加载的 JavaScript 依然会阻塞 load 事件。换句话说，async-script 可能在 DOMContentLoaded 触发之前或之后执行，但一定在 load 触发之前执行。

    从上一段也能推出，多个 async-script 的执行顺序是不确定的，谁先加载完谁执行。值得注意的是，向 document 动态添加 script 标签时，async 属性默认是 true。

    document.createElement

    使用 document.createElement 创建的 script 默认是异步的

    通过动态添加 script 标签引入 JavaScript 文件默认是不会阻塞页面的。如果想同步执行，需要将 async 属性人为设置为 false。

    优化渲染性能

    chrome 官方文档：https://developers.google.com/web/fundamentals/performance/?hl=en

    翻译：https://x5.tencent.com/tbs/document/doc-chrome.html

    优化JS的执行效率

    动画实现使用requestAnimationFrame

    setTimeout(callback)和setInterval(callback)无法保证callback函数的执行时机，很可能在帧结束的时候执行，从而导致丢帧。

    requestAnimationFrame(callback)可以保证callback函数在每帧动画开始的时候执行。拓展阅读《频率史—从电源频率到音频采样频率与视频帧率:29.97/44.1》、《弄懂javascript的执行机制:事件轮询|微任务和宏任务》

    长耗时的JS代码放到Web Workers中执行

    JS代码运行在浏览器的主线程上，与此同时，浏览器的主线程还负责样式计算、布局、绘制的工作，如果JavaScript代码运行时间过长，就会阻塞其他渲染工作，很可能会导致丢帧。

    前面提到每帧的渲染应该在16ms内完成，但在动画过程中，由于已经被占用了不少时间，所以JavaScript代码运行耗时应该控制在3-4毫秒。

    如果真的有特别耗时且不操作DOM元素的纯计算工作，可以考虑放到Web Workers中执行。

    CSS渲染与布局优化

    添加或移除一个DOM元素、修改元素属性和样式类、应用动画效果等操作，都会引起DOM结构的改变，从而导致浏览器要repaint或者reflow。

    降低样式选择器的复杂度

    • 尽量保持class的简短，或者使用Web Components框架（如：Omi）。

    • 降低样式选择器的复杂度；使用基于class的方式，比如BEM（Block, Element, Modifier）。 

    • 减少css嵌套，如使用post-css 语法 &- 或 sass的@at-root 

    • 减少需要执行样式计算的元素的个数

      对于样式计算来说，范围越小、规则越简单的话，处理效率越高。

      • 在过去，如果你修改了body元素的class属性，那么页面里所有元素都要重新计算样式。现代的浏览器中不再这样做了，浏览器不会检查所有受到样式变化影响的元素。因为会对每个DOM元素维护一个独有的样式规则小集合，如果这个集合发生改变，才重新计算该元素的样式。所以，样式计算一般是直接对那些目标元素执行。因此我们应该尽可能减少需要执行样式计算的元素的个数。

      • 一般来说在最坏的情况下，样式计算量 = 元素个数 x 样式选择器个数。因为对每个元素最少需要检查一次所有的样式，以确认是否

      • Web Components中的样式计算不会跨越Shadow DOM范围，仅在单个的Web Component中进行，而不是在整个页面的DOM树上进行

    避免大规模、复杂的布局

    布局，就是浏览器计算DOM元素的几何信息的过程：元素大小和在页面中的位置。每个元素都有一个显式或隐式的大小信息，决定于其CSS属性的设置、或是元素本身内容的大小、抑或是其父元素的大小。在Blink/WebKit内核的浏览器和IE中，这个过程称为布局。在基于Gecko的浏览器（比如Firefox）中，这个过程称为Reflow。

    尽可能避免触发布局

    布局的时间消耗主要在于：

    • 需要布局的DOM元素的数量

    •  布局过程的复杂程度

    一份详细的能触发布局、绘制或渲染层合并的CSS属性清单：CSS Triggers

    使用flexbox替代老的布局模型

    新的Flexbox比旧的Flexbox和基于浮动的布局模型更高效。

    在任何情况下，不管是是否使用Flexbox，你都应该努力避免同时触发所有布局，特别在页面对性能敏感的时候（比如执行动画效果或页面滚动时）。

    避免强制同步布局事件的发生

    将一帧画面渲染到屏幕上的处理顺序如下所示： 

    浏览器渲染过程流程图

    • 在JavaScript脚本运行的时候，它能获取到的元素样式属性值都是上一帧画面的，都是旧的值。

    • 如果想在这一帧开始的时候，读取一个元素属性值，就需要修改当前元素的某个属性（可能触发重绘与回流）。

    • 为了避免触发不必要的布局过程，你应该首先批量读取元素样式属性，然后再对样式属性进行写操作。

    大多数情况下，都不需要先修改然后再读取元素的样式属性值，使用上一帧的值就足够了。过早地同步执行样式计算和布局是潜在的页面性能的瓶颈之一

    避免快速连续的布局

    比强制同步布局更糟：连续快速的多次执行它。如：

    for (var i = 0; i < paragraphs.length; i++) {
     paragraphs[i].style.width = box.offsetWidth + 'px';
}

    FastDom是一个轻量的库，它提供一个公共接口，能让DOM的读/写操作捆绑在一起。 

    https://github.com/wilsonpage/fastdom

    简化绘制的复杂度、减小绘制区域

    绘制并非总是在内存中的单层画面里完成的。实际上，浏览器在必要时将会把一帧画面绘制成多层画面，然后将这若干层画面合并成一张图片显示到屏幕上。

    这种绘制方式的好处是，使用tranforms来实现移动效果的元素将会被正常绘制，同时不会触发对其他元素的绘制。这种处理方式和思想跟图像处理软件（比如Sketch/GIMP/Photoshop）是一致的，它们都是可以在图像中的某个单个图层上做操作，最后合并所有图层得到最终的图像。

    提升移动或渐变元素的绘制层

    • 在页面中创建一个新的渲染层的最好方式就是使用CSS属性will-change，同时再与transform属性一起使用，就会创建一个新的组合层：will-change: transform;

    • 对于那些目前还不支持will-change属性、但支持创建渲染层的浏览器，以使用一个3D transform属性来强制浏览器创建一个新的渲染层：transform: translateZ(0);

    减少绘制区域

    有时候尽管把元素提升到了一个单独的渲染层，渲染工作依然是必须的。渲染过程中一个比较有挑战的问题是，浏览器会把两个相邻区域的渲染任务合并在一起进行，这将导致整个屏幕区域都会被绘制。比如，你的页面顶部有一个固定位置的header，而此时屏幕底部有某个区域正在发生绘制的话，整个屏幕都将会被绘制。 

    注意：在DPI较高的屏幕上，固定定位的元素会自动地被提升到一个它自有的渲染层中。但在DPI较低的设备上却并非如此，因为这个渲染层的提升会使得字体渲染方式由子像素变为灰阶（详细内容请参考：Text Rendering），我们需要手动实现渲染层的提升。

    减少绘制区域通常需要对动画效果进行精密设计，以保证各自的绘制区域之间不会有太多重叠，或者想办法避免对页面中某些区域执行动画效果。

    简化绘制的复杂度

    比如js 获取元素的offsetTop ffsetTop 比如getBoundingClientRect 消耗更少。

    在css里面，重绘 backgroun 比如 box-shadow 消耗更好。

    那些能性能更加耗资源，我也不知道，道友若知，请留言赐教，多谢。手工就 paint profiler 分析对比咯

    优先使用渲染层合并属性、控制层数量

    • 只使用transform/opacity来实现动画效果

      应用了transforms/opacity属性的元素必须独占一个渲染层。为了对这个元素创建一个自有的渲染层，你必须提升该元素。在合成层上面的元素，也会合并到此图层中。

    • 用will-change/translateZ属性把动画元素提升到单独的渲染层中

    • 避免滥用渲染层提升：更多的渲染层需要更多的内存和更复杂的管理

      过多的渲染层来带的开销而对页面渲染性能产生的影响，甚至远远超过了它在性能改善上带来的好处。由于每个渲染层的纹理都需要上传到GPU处理，因此我们还需要考虑CPU和GPU之间的带宽问题、以及有多大内存供GPU处理这些纹理的问题。

    从性能方面考虑，最理想的渲染流水线是没有布局和绘制环节的，只需要做渲染层的合并即可：

    之前也参看：《关于css3之transform一些坑的总结－transform对普通元素的N多渲染》

    对用户输入事件的处理去抖动

    • 避免使用运行时间过长的输入事件处理函数，它们会阻塞页面的滚动

    • 避免在输入事件处理函数中修改样式属性

    • 对输入事件处理函数去抖动，存储事件对象的值，然后在requestAnimationFrame 回调函数中修改样式属性

    具体参看《Debounce 和 Throttle 的原理及实现》


    参考文章：

    从浏览器多进程到JS单线程，JS运行机制最全面的一次梳理 https://www.cnblogs.com/cangqinglang/p/8963557.html

    Chrome源码剖析、上--多线程模型、进程通信、进程模型https://www.cnblogs.com/v-July-v/archive/2011/04/02/2036008.html

    Chrome源代码分析之进程和线程模型（三） https://blog.csdn.net/namelcx/article/details/6582730

    http://dev.chromium.org/developers/design-documents/multi-process-architecture

    chrome渲染机制浅析 https://www.jianshu.com/p/99e450fc04a5

    浅析浏览器渲染原理 https://segmentfault.com/a/1190000012960187

    javascript宏任务和微任务 https://www.cnblogs.com/fangdongdemao/p/10262209.html

    浏览器与Node的事件循环(Event Loop)有何区别? https://blog.csdn.net/Fundebug/article/details/86487117




    转载本站文章《浏览器层面优化前端性能(2):Reader引擎线程与模块分析优化点》,
    请注明出处：https://www.zhoulujun.cn/html/webfront/browser/webkit/2020_0615_8464.html

    收藏
    上一篇：浏览器层面优化前端性能(1):Chrom组件与进程/线程模型分析
    下一篇：JS引擎(2)：Java平台上JavaScript引擎—Rhino/Nashorn概述
    延伸阅读：