• 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