笔记-浏览器框架及工作原理

1. 浏览器功能及组成结构

1.1. 功能

略

1.2. 浏览器组成结构

浏览器的主要组件包括：

用户界面 - 包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗口显示的你请求的页面外，其他显示的各个部分都属于用户界面。
浏览器引擎 - 在用户界面和渲染引擎之间传送指令。
渲染引擎 - 负责显示请求的内容。如果请求的内容是 HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。
网络 - 用于网络调用，比如 HTTP 请求。其接口与平台无关，并为所有平台提供底层实现。
用户界面后端 - 用于绘制基本的窗口小部件，比如组合框和窗口。其公开了与平台无关的通用接口，而在底层使用操作系统的用户界面方法。
JavaScript 解释器。用于解析和执行 JavaScript 代码，比如chrome的javascript解释器是V8。
数据存储。这是持久层。浏览器需要在硬盘上保存各种数据，例如 Cookie。新的 HTML 规范 (HTML5)定义了“网络数据库”，这是一个完整（但是轻便）的浏览器内数据库。

浏览器组织结构图(High Level Structure)

1.3. 浏览器打开网页的具体实现过程描述

1. 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；

2. 浏览器开始载入html代码，发现<head>标签内有一个<link>标签引用外部CSS文件；

扫描二维码关注公众号，回复： 5305303 查看本文章

3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件；

4. 浏览器继续载入html中<body>部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；

5. 浏览器在代码中发现一个<img>标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；

6. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；

7. 浏览器发现了一个包含一行Javascript代码的<script>标签，赶快运行它；

8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个（style.display=”none”）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；

9. 终于等到了</html>的到来，浏览器泪流满面……

10. 等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下<link>标签的CSS路径；

11. 浏览器召集了在座的各位

<span><ul><li>们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请

求了新的CSS文件，重新渲染页面。

1.4. 浏览器内核

浏览器内核又叫渲染引擎，主要负责 HTML、CSS 的解析，页面布局、渲染与复合层合成。浏览器内核的不同带来的主要问题是对 CSS 的支持度与属性表现差异。

现在主流的内核有：Blink、Webkit、Gecko、Trident：

一般浏览器采用的都是单内核，而随着浏览器的发展现在也出现了双内核，像360浏览器、QQ浏览器都是采用双内核。

Trident

元老级内核之一，由微软开发，并于1997年10月首次在ie 4.0中使用，凭借其windows垄断优势，Trident市场占有率一直很高。然而垄断并非，没有竞争就没有进步，长期以往，Trident内核一度停滞不前，更新缓慢，甚至一度与W3C标准脱节。2011年，从ie 9开始，Trident开始支持HTML5和CSS 3，因此我们也经常会看到有些网站在浏览时会提示用户（在Internet Explorer 9.0+以上浏览效果最佳）。前端程序员做浏览器兼容一般也不再会考虑ie 8之前的浏览器了。

由于该内核由微软开发出来供ie使用，因此这款内核一般也被称为“ie内核”。ie内核提供了开放的接口，可以供其他浏览器去包装该内核开发出自己的一套浏览器，如同包装Android原生系统开发出MIUI。国内很多浏览器厂商期初就是包装ie内核，如360安全浏览器，360极速浏览器，百度浏览器，猎豹浏览器等，后面经过不断地发展有的内核发生了变化，这个后面会提到。

Gecko

元老级内核之一，由Netscape公司Mozilla组织开发。1998年，Netscape在于IE浏览器竞争失利之后，成立了非正式组织Mozilla，由其开发新一代内核，后命名为“Gecko”。FireFox也是这班人开发出来了，因此这也就是FireFox一直使用的内核。

Gecko的特点是代码完全公开，因此其开发程度很高，全世界的程序员都可以为其编写代码，增加功能。

WebKit

这是苹果公司开发的内核，也是其旗下产品Ssfari浏览器使用的内核。Webkit引擎包含了WebCode排版引擎和JavaScriptCode解析引擎，分别是从KDE的KHTML和KJS衍生而来，它们都是自由软件，在GPL条约下授权，同时支持BSD系统开发。

Chrome、360极速浏览器以及搜狗高速浏览器也使用Webkit作为内核（在脚本理解方面，Chorome使用自己研发的V8引擎）。

Blink

这是由Google和Opera Software开发的浏览器排版引擎，Google计算将这个渲染引擎作为Chromium计划的一部分，并且在2013年4月公布了这一消息。这一渲染引擎是开源引擎Webkit中WebCore组件的一个分支，并且在Chrome（28及往后版本）、Opera（15及往后版本）和Yandex浏览器中使用。

1.5. 常用浏览器及其内核

1、IE浏览器内核：Trident内核，也是俗称的IE内核；

2、Chrome浏览器内核：统称为Chromium内核或Chrome内核，以前是Webkit内核，现在是Blink内核；

3、Firefox浏览器内核：Gecko内核，俗称Firefox内核；

4、Safari浏览器内核：Webkit内核；

5、Opera浏览器内核：最初是自己的Presto内核，后来加入谷歌大军，从Webkit又到了Blink内核；

6、360浏览器、猎豹浏览器内核：IE+Chrome双内核；

7、搜狗、遨游、QQ浏览器内核：Trident（兼容模式）+Webkit（高速模式）；

8、百度浏览器、世界之窗内核：IE内核；

9、2345浏览器内核：好像以前是IE内核，现在也是IE+Chrome双内核了；

10、UC浏览器内核：这个众口不一，UC说是他们自己研发的U3内核，但好像还是基于Webkit和Trident，还有说是基于火狐内核。

2. 浏览器渲染工作原理

2.1. 主流程描述

浏览器首先通过网络获得所请求文档的内容，然后进行下面的步骤:

即：解析文档构建DOM树 ==> 构建render树 ==> 绘制render树

引擎将解析 HTML 文档，并将各标记逐个转化成“DOM TREE”上的 DOM 节点。同时也会解析外部 CSS 文件以及样式元素中的样式数据生成css rule tree。两者结合生成rendering tree,也可以叫呈现树。

呈现树包含多个带有视觉属性（如颜色和尺寸）的矩形。这些矩形的排列顺序就是它们将在屏幕上显示的顺序。

呈现树构建完毕之后，进入“布局”处理阶段，也就是为每个节点分配一个应出现在屏幕上的确切坐标。下一个阶段是绘制 - 呈现引擎会遍历呈现树，由用户界面后端层将每个节点绘制出来。

需要着重指出的是，这是一个渐进的过程。为达到更好的用户体验，呈现引擎会力求尽快将内容显示在屏幕上。它不必等到整个 HTML 文档解析完毕之后，就会开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来。

其它事项：

浏览器刷新的频率大概是60次/秒，也就是说刷新一次大概时间为16ms

如果浏览器对每一帧的渲染工作超过了这个时间，页面的渲染就会出现卡顿的现象。

以上过程是渐进的，并不一定严格按照顺序执行的，为了更快将内容呈现在不屏幕中，不会等到HTML全部解析完成之后才开始构建渲染树和layout，它会在不断接收和处理其他网络资源的同时，就开始部分内容的解析和渲染

渲染完成之后会触发 ready事件

webkit主流程示例：

Gecko呈现引擎主流程

2.2. 其它技术名词

2.2.1. repaint/reflow

这两个概念使用在paint过程中，页面为什么会慢？那是因为浏览器要花时间、花精力去渲染，尤其是当它发现某个部分发生了点变化影响了布局，需要倒回去重新渲染，这个回退的过程叫reflow。

reflow几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。通常我们都无法预估浏览器到底会reflow哪一部分的代码，它们都彼此相互影响着。

reflow问题是可以优化的，我们可以尽量减少不必要的reflow。比如<img>图片载入问题，这其实就是一个可以避免的reflow——给图片设置宽度和高度就可以了。这样浏览器就知道了图片的占位面积，在载入图片前就预留好了位置。

另外，有个和reflow看上去差不多的术语：repaint，中文叫重绘。如果只是改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性，将只会引起浏览器repaint。repaint的速度明显快于 reflow（在IE下需要换一下说法，reflow要比repaint 更缓慢）。

Reflow的成本比Repaint的成本高得多的多。DOM Tree里的每个结点都会有reflow方法，一个结点的reflow很有可能导致子结点，甚至父点以及同级结点的reflow。在一些高性能的电脑上也许还没什么，但是如果reflow发生在手机上，那么这个过程是非常痛苦和耗电的。

所以，下面这些动作有很大可能会是成本比较高的。

增加、删除、修改DOM结点时，会导致Reflow或Repaint

移动DOM的位置，或是搞个动画的时候。

修改CSS样式的时候。

Resize窗口的时候（移动端没有这个问题），或是滚动的时候。

修改网页的默认字体时。

3. 总结

浏览器显示网页的过程可以做如下描述：

请求得到html文档，根据文档请求更多的img,css及其它资源文件；
解析文档得到两个东西，dom tree and cssom tree；
依据上面两个tree生成render tree；
根据render tree进行布局并在其中绘制相关元素。

4. reference

https://www.html5rocks.com/zh/tutorials/internals/howbrowserswork/#Rendering_engines
https://segmentfault.com/a/1190000009975744
https://blog.csdn.net/proswpualan/article/details/81813329