阅读器解析渲染HTML文档的历程详解（图文）
本篇文章给大家带来的内容是关于阅读器解析渲染HTML文档的历程详解（图文），有必然的参照 价值，有需要的伴侣可以参照 一下，但愿对你有所帮忙。
阅读器的工作道理
一、阅读器的高层构造
阅读器的主要组件为：
1、会员界面 - 包罗地址栏、前进/后退按钮、书签菜单等。除了阅读器主窗口显示的您恳求的页面外，其他显示的各个部分都属于会员界面。2、阅读器引擎 - 在会员界面和显现引擎之间传送指令。
3、显现引擎 - 负责显示恳求的内容。假如恳求的内容是 HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。
4、网络 - 用于网络调取，比方 HTTP 恳求。其接口与平台无关，并为所有平台供给底层实现。
5、会员界面后端 - 用于绘制根本的窗口小部件，比方组合框和窗口。其公示了与平台无关的通用接口，而在底层使用操纵系统的会员界面办法。
6、JavaScript 说明器。用于解析和施行 JavaScript 代码。
7、数据储备。这是耐久层。阅读器需要在硬盘上留存各种数据，例如 Cookie。新的 HTML 标准 (HTML5) 定义了“网络数据库”，这是一个完全（但是轻便）的阅读器内数据库。
值得留意的是，和大多数阅读器不一样，Chrome 阅读器的每个标签页都离别对应一个显现引擎实例。每个标签页都是一个独立的进程。
二、主流程
显现引擎一开端会从网络层猎取恳求文档的内容，内容的大小一样限制在 8000 个块之内。
然后停止如下所示的根本流程：
显现引擎将开端解析 HTML 文档，并将各标志逐个转化成“内容树”上的 DOM 节点。同时也会解析外部 CSS 文件乃至样式元素中的样式数据。HTML 中这些带有视觉指令的样式信息将用于创立另一个树构造：显现树。
显现树包括多个带有视觉属性（如色彩和尺寸）的矩形。这些矩形的摆列次序就是它们将在屏幕上显示的次序。
显现树构建完毕之后，进入“规划”处置阶段，也就是为每个节点分配一个应显现在屏幕上确实切坐标。下一个阶段是绘制 - 显现引擎会遍历显现树，由会员界面后端层将每个节点绘制出来。
需要着重指出的是，这是一个渐进的历程。为到达更好的会员体验，显现引擎会力求尽快将内容显示在屏幕上。它不必比及整个 HTML 文档解析完毕之后，就会开端构建显现树和设定规划。在不竭接收和处置来自网络的其余内容的同时，显现引擎会将部分内容解析并显示出来。
主流程示例：
三、处置足本和样式表的次序
1、足本
网络的模型是同步的。网页作者但愿解析器碰到 <script> 标志时马上解析并施行足本。文档的解析将休止，直到足本施行完毕。假如足本是外部的，那么解析历程会休止，直到从网络同步抓取资源完成后再连续。此模型已经使用了多年，也在 HTML4 和 HTML5 标准中停止了指定。作者也可以将足本标注为“defer”，这样它就不会休止文档解析，而是比及解析完毕才施行。HTML5 增添了一个选项，可将足本标志为异步，以便由其他线程解析和施行。
2、预解析
WebKit 和 Firefox 都停止了这项优化。在施行足本时，其他线程会解析文档的其余部分，寻出并加载需要通过网络加载的其他资源。通过这种方式，资源可以在并行连接上加载，从而提高总体速度。请留意，预解析器不会修改 DOM 树，而是将这项工作交由主解析器处置；预解析器只会解析外部资源（例如外部足本、样式表和图片）的援用。3、样式表
另一方面，样式表有着不一样的模型。理论上来说，利用样式表不会更换 DOM 树，因此好像没有必要等候样式表并休止文档解析。但这触及到一个问题，就是足本在文档解析阶段会恳求样式信息。假如当时还没有加载和解析样式，足本就会获得错误的回复，这样明显会发生许多问题。这看上去是一个非典型案例，但事实上非常遍及。Firefox 在样式表加载和解析的历程中，会制止所有足本。而关于 WebKit 而言，仅当足本尝试拜访的样式属性大概受尚未加载的样式表影响时，它才会制止该足本。4、显现树构建
在 DOM 树构建的同时，阅读器还会构建另一个树构造：显现树。这是由可视化元素依照其显示次序而组成的树，也是文档的可视化表示。它的作用是让您依照准确的次序绘制内容。Firefox 将显现树中的元素称为“框架”。WebKit 使用的术语是显现器或显现对象。
显现器知道怎样规划并将本身及其子元素绘制出来。
四、规划
显现器在创立完成并增加到显现树时，并不包括位置和大小信息。运算这些值的历程称为规划或重排。
HTML 采纳基于流的规划模型，这意味着大多数状况下只要一次遍历就能运算出几何信息。处于流中靠后位置元素平常不会影响靠前位置元素的几何特点，因此规划可以按从左至右、从上至下的次序遍历文档。但是也有例外状况，比方 HTML 表格的运算就需要不止一次的遍历。
坐标系是相关于根框架而创立的，使用的是上坐标和左坐标。
规划是一个递归的历程。它从根显现器（对应于 HTML 文档的 <html> 元素）开端，然后递归遍历部分或所有的框架层次构造，为每一个需要运算的显现器运算几何信息。
根显现器的位置左边是 0,0，其尺寸为视口（也就是阅读器窗口的可见区域）。
所有的显现器都有一个“layout”或者“reflow”办法，每一个显现器都会调取其需要停止规划的子代的 layout 办法。
五、绘制
在绘制阶段，系统会遍历显现树，并调取显现器的“paint”办法，将显现器的内容显示在屏幕上。绘制工作是使用会员界面根基组件完成的。
个人懂得总结
一、解析器与预解析机制
显现引擎从网络层猎取恳求文档的内容，然后开端解析 HTML 文档，并将各标志逐个转化为 DOM树（内容树）上的 DOM 节点，同时也会解析外部 CSS 文件乃至样式元素中的样式数据。HTML 中这些带有视觉指令的样式信息将用于创立另一个树构造：渲染树（显现树）。显现树构建完毕之后，显现引擎将对显现树停止规划和绘制。
显现引擎 的解析包罗 HTML 解析和 CSS 解析，HTML 解析器的输出“解析树”是由 DOM 元素和属性节点构成的树构造，DOM 是文档对象模型 (Document Object Model) 的缩写。它是 HTML 文档的对象表示，同时也是外部内容（例如 JavaScript）与 HTML 元素之间的接口。解析树的根节点是“Document”对象。CSS 解析器会将 CSS 样式文件和样式元素中的样式数据解析为 CSS 规则树，阅读器结合 CSS 规则树和 DOM 树生成渲染树。
JavaScript 说明器 用于解析和施行 JavaScript 代码。
一样来讲，我们认为阅读器从网络层接收到 HTML 文档内容，然后开端解析文档生成 DOM 树，碰到 CSS 样式表标签或 JS 足本标签就起新线程去下载它们，并连续构建 DOM 树，阅读器按照 DOM 树构建渲染树，最后阅读器将渲染书绘制到会员界面。
在上述描写中，需要着重指出的是，HTML 文档的解析和渲染是一个渐进的历程。为到达更好的会员体验，显现引擎会力求尽快将内容显示在屏幕上。它不必比及整个 HTML 文档解析完毕，就会开端构建显现树和设定规划。在不竭接收和处置来自网络的其余内容的同时，显现引擎会将部分内容解析并显示出来。
阅读器的预解析。WebKit 和 Firefox 都停止了这项优化。在施行足本时，其他线程会解析 HTML 文档的其余部分，寻出并加载需要通过网络加载的其他资源。通过这种方式，资源可以在并行连接上加载，从而提高总体速度。请留意，预解析器不会修改 DOM 树，而是将这项工作交由主解析器处置；预解析器只会解析外部资源（例如外部足本、样式表和图片）的援用。
阅读器的预解析可以减缓渲染被堵塞的状况，例如文档解析历程中预加载器发明了 <script src="last.js"></script> 标签，会对 last.js 文件停止加载并放在阅读器缓存中，这样当解析器碰到这个 <script> 标志时，由于预加载器已经将 last.js 文件加载下来了，所以 last.js 会被马上施行，不需要等候从网络抓取资源，减缓了对渲染的堵塞。
二、CSS 和 JS 的处置次序和堵塞剖析
HTML 文档的解析和渲染历程中，外部样式表和足本 次序施行、并发加载。
JS 足本会堵塞 HTML 文档的解析，包罗 DOM 树的构建和渲染树的构建；CSS 样式表会堵塞渲染树的构建，但 DOM 树仍然连续构建（除非碰到 script 标签且 css 文件此时仍未加载完成），但不会渲染绘制到页面上。
在 HTML 文档的解析历程中，解析器碰到 <script> 标志时会马上解析并施行足本，HTML 文档的解析将被堵塞，直到足本施行完毕。假如足本是外部的，那么解析历程会休止，直到从网络抓取资源并解析和施行完成后，再连续解析后续内容。
理论上来说，利用样式表不会更换 DOM 树，因此好像没有必要等候样式表并休止文档解析。但这触及到一个问题，就是足本在文档解析阶段会恳求样式信息。假如当时还没有加载和解析样式，足本就会获得错误的回复，这样明显会发生许多问题。这看上去是一个非典型案例，但事实上非常遍及。Firefox 在样式表加载和解析的历程中，会制止所有足本。而关于 WebKit 而言，仅当足本尝试拜访的样式属性大概受尚未加载的样式表影响时，它才会制止该足本。
但不管是哪种状况致使的堵塞，该加载的外部资源还是会加载，例如外部足本、样式表和图片。HTML 文档的解析大概会被堵塞，但外部资源的加载不会被堵塞。
CSS 外部样式表的加载会堵塞外部足本的施行，但并不会堵塞外部足本的加载。这一点可以通过 chrome 调试工具中的 Network - Waterfall 停止验证，但是需要留意 chrome 的并发连接数（统一域名）上限为 6 个。
由上面两张截图可以看到，jquery.min.js 足本文件与 bootstrap.css 等样式文件并行加载，但是由于 chrome 的并发连接数上限为 6 个，因此 bootstrap.min.js 足本、xxx.css 样式等文件的加载会等候前面的文件加载完成，有可用连接数的时候才开端加载。
理解以上信息之后，我们可以对该页面停止响应优化，例如对CSS文件停止紧缩处置、使用 CDN，将资源分布在多个域名下、合并 CSS 文件，减少 HTTP 恳求数目等，来提高 CSS 的加载速度，减少 HTML 文档解析和渲染的堵塞时间。
browser only allows six TCP connections per origin on HTTP 1.
阅读器的并发恳求数目限制是针对统一域名的。因此可以使用 CDN 加快技术来提高会员拜访网站的响应速度，这样使用了 CDN 的资源加载不会占用当前域名下的并发连接数，从而减少堵塞的时间。
网页机能
理解 HTML 文档的解析和渲染的历程关于剖析网页机能有着重要意义，它可以帮忙我们寻到影响网页机能的关键因素。例如，我们知道 JS 外部足本的施行会堵塞文档的解析，那么重量级的第三方插件则会影响首页加载的速度，假如因此影响到了会员体验，我们就需要思考这个第三方插件的使用成本是不是太高了，能否使用其他轻量级的插件停止替换，或者只使用其中一部分模块。
以 Datatables 为例：
上图是一个项目页面的 Network 截图，红色框中的部分显现了约 700ms 摆布的空白，我们需要知道为什么页面的加载会显现这样的状况，这段空白时间阅读器在干什么？
我们剖析 Timeline 图，看看阅读器在这段时间的详细信息，如下：
通过 Timeline 图我们可以看到，在 250ms~900ms 时间区间内，阅读器在施行 datatables.min.js 足本代码，这个足本的施行堵塞了文档的解析，耗时约 700ms，对应了 Network 图中的空白。
我们连续查看页面总的耗不时间，评估 700ms 耗时的影响，如下：
可以看到，页面总的完成耗时为 1.66s，由此可知 datatables.min.js 的施行耗时占了很大比重，应当稳重思考可否必然要使用这个插件，能否使用其他轻量级的插件停止替换，或者能否精简插件的不必要模块，或者舍弃插件的使用。
参照 材料-1
阅读器接收到html代码，大概是一份完全的文档，也大概是一个chunk，即开端解析。解析历程是先构建dom树，再按照dom树构建渲染树，最后阅读器将渲染树绘制到页面上。
构建dom树的历程即按照html代码自上而下停止构建，当碰到script文件加载／施行会堵塞后面dom树的构建（javascript大概会改动dom树），而碰到css文件则会堵塞渲染树的构建，即dom树仍然连续构建（除非碰到script标签并且css文件照旧未加载完成），但不会渲染绘制到页面上。而不管哪个堵塞，该加载的文件还是会加载，例如html文档中的其他css／js／图片文件。
别的javascript被加载后就会被施行，施行的历程也堵塞树的构建。是施行完了才解析其他内容，而不是施行完了才加载其他内容。
作者：加冰
链接：https://www.zhihu.com/questio...
参照 材料-2
第一，开源阅读器一样以8k每块下载html页面。
然后解析页面生成DOM树，碰到css标签或JS足本标签就新起线程去下载他们，并连续构建DOM。
下载完后解析CSS为CSS规则树，阅读器结合CSS规则树和DOM树生成Render Tree。
留意：构建CSS Object Model（CSSOM)会堵塞JavaScript的施行。JavaScript的施行也会堵塞DOM的构建。
JavaScript下载后可以通过DOM API修改DOM，通过CSSOM API修改样式作用域Render Tree。
每次修改会造成Render Tree的从新规划和重绘。只要修改DOM或修改了元素的外形或大小，就会触发Reflow，天真修改元素的色彩只需Repaint一下（调取操纵系统Native GUI的API绘制）。
作者：陈金
链接：https://www.zhihu.com/questio...
本篇文章到这里就已经全部完毕了，更多其他出色内容可以关注PHP中文网的JavaScript视频教程栏目！
以上就是阅读器解析渲染HTML文档的历程详解（图文）的具体内容，更多请关注百分百源码网其它相关文章！
