How Javascript works (Javascript工做原理) (十一) 渲染引擎及性能优化小技巧

我的总结:读完这篇文章须要20分钟,这篇文章主要讲解了浏览器中引擎的渲染机制。javascript

DOMtree       ----|css

         |---->  RenderTreehtml

CSSOMtree  ----|html5

 

这是 JavaScript 工做原理的第十一章。java

迄今为止,以前的 JavaScript 工做原理系列文章集中于关注 JavaScript 语言自己的功能,在浏览器中的执行状况,如何优化等等。node

然而,当在构建网络应用的时候,不只仅只是编写本身运行的 JavaScript 代码。所编写的 JavaScript 代码与运行环境息息相关。理解 JavaScript 运行环境,它的运行原理以及其组成会让你构建出更好的应用而且一旦让应用程序运行于各类环境下的时候,让你更加成竹在胸地应对潜在的问题。git

 

 

那么,让咱们一探浏览器主要组件吧:github

  • 用户界面: 包括地址栏,后退和前进按钮,书签菜单等等。本质上,这里包含了除显示用户所看到的网页自己的窗口之外的浏览器的每一个部分。
  • 浏览器引擎: 处理用户界面和渲染引擎的交互
  • 渲染引擎: 负责显示网页。渲染引擎解析 HTML 和 CSS 并在屏幕上显示解析的内容。
  • 网络: 使用各个平台的不一样实现所发起的诸如 XHR 请求的网络调用,这些网络调用是基于跨平台的接口实现的。
  • UI 后端: 负责绘制诸如复选框和窗口的核心部件。它暴露出一个平台无关的泛型接口。它底层使用操做系统 UI 方法。
  • JavaScript 引擎: 咱们在以前的系列文章中有详细介绍过。基本上,这是 JavaScript 代码执行的地方。
  • 数据存储: 网络应用可能须要本地存储全部数据。支持的存储机制类型包括 localStorageindexDBWebSQL 以及 FileSystem

本文将专一介绍渲染引擎,由于它是用来处理 HTML 和 CSS 的解析和可视化的,而这些是大多数的 JavaScript 应用须要持续进行交互的方面。web

渲染引擎概述

渲染引擎的主要职责即在浏览器屏幕上显示请求的页面。后端

渲染引擎能够显示 HTML,XML 文档以及图片。若是使用额外的插件,就能够显示诸如 PDF 的不一样类型的文档。

渲染引擎

与 JavaScript 引擎相似,不一样浏览器也使用不一样的渲染引擎。如下为比较流行的引擎:

  • Gecko-Firefox
  • WebKit-Safari
  • Blink-Chrome, Opera(从版本 15 开始)

渲染过程

渲染引擎从网络层获取到请求的文档内容。

构建 DOM 树

渲染引擎的第一步即解析 HTML 文档和转化解析的元素为 DOM 树 上的实际 DOM 节点。

假设有以下的文本输入框:

<html>
  <head>
    <meta charset="UTF-8">
    <link rel="stylesheet" type="text/css" href="theme.css">
  </head>
  <body>
    <p> Hello, <span> friend! </span> </p>
    <div> 
      <img src="smiley.gif" alt="Smiley face" height="42" width="42">
    </div>
  </body>
</html>

HTML 的 DOM 树相似这样:

 

基本上,每一个元素是直接包含于其内的元素的父节点。而后依次类推。

构建 CSSOM 树

CSSOM 即 CSS Object Model。当浏览器构建页面的 DOM 树的时候,它在 head 标签部分遇到一个引用外部 theme.css 样式表的 link 标签。表示它可能须要样式表来渲染页面,因而便立刻分派一个请求来获取样式表。假设如下为 theme.css 文件内容:



与 HTML 同样,渲染引擎须要把 CSS 转化为浏览器能够操做的东西-即 CSSOM。如下为 CSSOM 的大概模样:body { font-size: 16px; } p { font-weight: bold; } span { color: red; } p span { display: none; } img { float: right; }

 

想知道为何 CSSOM 是树状结构的吗?当为页面上的任意对象计算其最终的样式集的时候,浏览器先把最为通用的样式规则应用于该节点(好比,它是 body 的子节点,会先应用 body 的全部样式)而后经过应用更为具体的样式规则来递归重定义计算的样式。

让咱们看下具体的例子吧。body 中的 span 标签中的任何文字样式为字体大小 16 像素且字体颜色为红色。这些样式继承自 body 元素。p 元素的子元素 span 因为应用了更为具体的样式从而不会显示其内容(display:none)。

还有,请注意以上 CSSOM 树并不完整并且只显示了样式表中指定的重写样式。每一个浏览器提供了一份默认的样式集即 『用户代理样式』- 这即当没有提供任何样式的时候的默认显示样式。咱们的样式只是简单地重写了这些默认样式。

 

构建渲染树

HTML 中的可视化指令和 CSSOM 树的样式数据结合起来建立渲染树。

你可能为问渲染树是什么?它是按顺序构建可视化元素并显示在屏幕上的树。它是带有相应的样式的 HTML 的视觉表现。该树旨在按正确的顺序绘制内容。

在 Webkit 中渲染树中的每一个节点便是一个渲染器或者渲染器对象。

如下为以上的 DOM 和 CSSOM 树合成的渲染器树的大概模样:

为了建立渲染树,浏览器大概作了几下几件事:

  • 从 DOM 树的根节点开始,遍历每一个可见节点。一些节点是不可见的(好比,script 标签,meta 标签等等),而后会被忽略,由于它们并不会在渲染的输出中显示。一些节点经过样式隐藏而后也会被忽略。好比以上例子中的 span 节点,由于为其显式设置了 display: none 的样式。
  • 浏览器为每一个可见节点应用相对应的 CSSOM 规则并应用这些样式规则。
  • 释放出包含内容及其通过计算的样式的可见节点。

能够浏览下 RenderObject 的源码(Webkit 中):https://github.com/WebKit/webkit/blob/fde57e46b1f8d7dde4b2006aaf7ebe5a09a6984b/Source/WebCore/rendering/RenderObject.h

看一下这个类的一些核心构件吧:

class RenderObject : public CachedImageClient {
  // 重绘整个对象。当边框颜色改变或者边框样式更改的时候调用。
  
  Node* node() const { ... }
  
  RenderStyle* style;  // 计算的样式
  const RenderStyle& style() const;
  
  ...
}

每一个渲染器对象表明一个矩形区域一般是和一个节点的 CSS 盒模型相对应。它包括诸如宽度,高度以及定位的几何信息。

渲染树布局

当建立了渲染器而且添加到渲染树的时候,它并无定位和大小的信息。计算这些值即称为布局。

HTML 使用了流式布局模型,意即大多数状况下能够一次性计算出渲染器的几何信息。坐标系统是相对于根渲染器的。这里使用 Top 和 left 坐标。

布局是一个递归的过程-它从根渲染器开始进行渲染,根渲染器即 HTML 文档的 html 元素。布局继续经过一部分或者整个渲染器层级结构递归进行,为每一个须要计算几何信息的渲染器计算其信息。

根渲染器的定位为 0,0 和大小即为浏览器窗口的可视化部分(好比 viewport)。

进行布局的过程即计算出每一个节点在屏幕上显示的准确位置。

绘制渲染树

该阶段,遍历渲染器树而后调用渲染器的 paint() 方法来在屏幕上显示其内容。

绘制能够是全局或增量式的(相似于布局):

  • 全局-重绘整个树。
  • 增量-以某种方式只更改部分渲染器而不会影响到整颗树。渲染器做废其在屏幕上的矩形区域。这会致使操做系统把它当作是一个须要重绘的区域并生成一个 paint 事件。操做系统会智能地把几个区域合并成一个以提高渲染性能。

总之,理解绘制是个渐进式的过程是很重要的。为了更好的交互体验,渲染引擎会试图尽快在屏幕上显示内容。它不会等待全部的 HTML 结构解析完成才开始构建和布局渲染树。会优先解析和显示部份内容,与此同时持续处理从网络接收的剩下的内容项。

脚本和样式的处理顺序

当解析器遇到 <script> 标签的时候会当即解析和执行该标签里面的代码。整个文档的解析会中止直到脚本执行完毕。意即该过程是同步的。

当 script 引用的是一个外部资源,必须首先获取该资源(也是同步的)。全部的解析会中止直到获取该脚本资源。

HTML5 添加了一个选项来异步加载该资源,这样就可使用另外的线程来解析和执行该资源。IE 可使用 defer属性,其它可使用 async 属性。IE10 如下使用 defer 属性,IE10 以上也可使用 async 属性。

这里有一个须要注意的地方即 IE10 如下对于 defer 的支持,打开 https://caniuse.com 查找便可发现对于 IE10 如下的支持是一些须要注意的地方即 defer 的脚本有可能会在 DOMContentLoaded 事件以后才开始运行,参见这里,这里就不作试验了,有兴趣能够点击这里测试下 IE 下的表现。

这里稍微作一下引伸,在 jQuery 源码中,ready.js 有一段以下的代码:

// Catch cases where $(document).ready() is called
// after the browser event has already occurred.
// Support: IE <=9 - 10 only
// Older IE sometimes signals "interactive" too soon
if ( document.readyState === "complete" ||
	( document.readyState !== "loading" && !document.documentElement.doScroll ) ) {

	// Handle it asynchronously to allow scripts the opportunity to delay ready
	window.setTimeout( jQuery.ready );

} else {

	// Use the handy event callback
	document.addEventListener( "DOMContentLoaded", completed );

	// A fallback to window.onload, that will always work
	window.addEventListener( "load", completed );
}

里面的 window.setTimeout( jQuery.ready ); 是容许脚本有机会延迟执行 ready 事件。大概是为 IE script 标签的 defer 属性准备的吧?

 

优化渲染性能

若想要优化网络应用的性能,须要关注五个主要的方面。这些方面是你能够进行控制的:

  1. JavaScript-以前的文章中有介绍了编写不阻塞 UI ,高效的代码等等。谈到渲染时候,须要考虑 JavaScript 代码是如何和页面上的 DOM 元素进行交互的。JavaScript 会在界面上作不少的更改,特别是在单页应用中。
  2. 样式计算-这个过程即应用样式规则到匹配选择器的元素上。一旦定义了样式规则,它们会应用于对应的元素,而后计算每一个元素的最终样式。
  3. 布局-一旦浏览器了解元素应用的样式规则,它会开始计算元素所占用的空间和其在浏览器屏幕上的显示位置。根据网页的布局模型定义一个元素的布局会影响到其它的元素。好比,<body> 标签的宽度会影响到其子孙元素的宽度等等。这即意味着布局过程是至关耗时的。绘制是在多个图层完成的。
  4. 绘制-该阶段即开始填充实际像素。这一过程包括绘制文字,颜色,图片,边框,阴影等全部每一个元素的可见部分。
  5. 合成-由于页面部分被绘制成潜在的多层,它们必须在屏幕以正确的顺序进行绘制,这样页面渲染才会正常。这是相当重要的,特别是对于那些重叠元素。

优化 JavaScript 代码

JavaScript 常常会在浏览器端触发视觉改变。尤为是在构建 SPA 的过程当中会更多。

这里有一些优化 JavaScript 中部分代码来提高渲染效率的建议:

  • 避免使用 setTimeout 或者 setInterval 来进行视觉的更改。这些会在帧的某个时间点调用 callback,有多是在帧的末尾。这样就会形成卡顿。必须在帧的开始触发视觉更改。

  • 把耗时的 JavaScript 移入以前提到的网页工做线程

  • 使用微任务来处理跨多个帧的 DOM 更改。这是为了预防当任务须要访问 DOM,而网络工做线程没法办到的状况的。

    意即须要把一个大型的任务分割为多个小任务而后根据不一样的任务性质在 requestAnimationFrame ,setTimeout 或 setInterval 中执行。

优化样式

经过添加和移除元素及更改属性等等修改 DOM 会致使浏览器从新计算元素样式及大多数状况整个页面或者部分页面的布局。

使用如下方法来优化渲染:

  • 减小选择器的复杂度。选择器复杂度会占用超过计算所需元素样式的 50% 的时间,剩余时间即构建样式自己。
  • 减小必须产生样式计算的元素的个数。本质上,直接更改少数元素的样式而不是使整个页面的样式失效。

优化布局

布局是很耗费浏览器性能的。考虑如下优化方案:

  • 尽量减小布局的数量。当更改样式的时候,浏览器检查样式更改是否须要从新计算布局。通常而言更改诸如 width, height, left, top 等和几何学相关的属性会须要布局。因此,尽量避免修改它们。
  • 尽量使用 flexbox 来进行布局而不是老式的布局模型。它会渲染得更快而且会极大地提高网络应用的性能。
  • 避免强制同步布局。须要记住的是当运行 JavaScript的时候,上一帧的老的布局值是已知的且能够被查询获得。当访问 box.offsetHeight 这并不会形成性能问题。然而,若是在访问它以前更改它的样式(好比为元素动态添加样式类),浏览器将不得不首先应用样式更改而后运行布局计算样式。这将会很是耗时和耗资源,因此尽力避免这样作。

优化绘制

这常常会是全部任务中最耗时的,因此尽可能避免触发绘制。优化方案:

  • 更改除 transfroms 或者 opacity 外的属性会触发绘制。因此省着点用啊。
  • 当触发一个布局也会触发绘制,由于更改元素的几何信息会更改元素的展现效果。
  • 经过提高层和动画编排来减小绘制区域。

扩展

参考谷歌官方关于性能的文档,提高元素使用以下的代码:

.moving-element {
  will-change: transform;
}

使用 FASTDOM 来避免强制同步布局和抖动。

另外关于 JavaScript 代码的优化方面,避免去处理一些微优化,好比使用 offsetTop 比用 getBoundingClientRect 速度更快,但这得基于所建立的网络应用而言,假设建立一个游戏,对性能要求很是高并且调用这些方法的地方多,那么性能的提高将会很可观的。还记得之前常常会去使用诸如 jsperf 来测试某个方法的速度,千万别钻牛角尖,因地制宜,避免掉入去计较那些微小的优化而付出过大的精力。

关于渲染可使用一些骨架图来提高用户体验。

 

一些想法

  • 关于性能的体验,其实你能够想象成造房子吧,假如是整个翻修固然是会更加耗时,可是若是装修某个区域就会提高性能。
  • 而后有其中的某个属性会提高性能,这可能理解为『工欲善其事必先利其器』。
  • 关于任务的切分能够理解为,建设设计的哲学,小技巧。

参考资源

相关文章
相关标签/搜索