浏览器渲染原理

浏览器结构

主要组件包括：

1. 用户界面 － 包括地址栏、后退/前进按钮、书签目录等，也就是所看到的除了用来显示所请求页面的主窗口之外的其他部分。
2. 浏览器引擎 － 用于在用户界面和渲染引擎之间传递数据。
3. 渲染引擎 － 负责渲染用户请求的页面内容，例如，如果请求内容为html，它负责解析html及css，并将解析后的结果渲染出来。
4. 网络 － 负责网络请求的网络模块。
5. UI后端 － 一些底层操作系统的接口。
6. JS解释器 － 用于解析和执行js的js解析器。
7. 数据存储持久层 － 帮助浏览器保存各种数据，比如cookie等等。（HTML5定义了web database技术，这是一种轻量级完整的客户端存储技术）

渲染引擎可以说是一个浏览器的核心与灵魂。我们往往会把渲染引擎称为浏览器内核。不同浏览器使用的内核也不大一样，其中IE使用的Trident,Firefox是Gecko，Sarafi使用的webkit, 并将其开源，Chrome是使用的基于webkit改造优化的Blink渲染引擎，也将其开源，Opera和Edge也是使用的Blink。

##进程（Process）、 线程(Thread)

进程是操作系统进行资源分配和调度的基本单元，可以申请和拥有计算机资源，进程是程序的基本执行实体。
线程是操作系统能够进行运算调度的最小单位，一个进程中可以并发多个线程，每条线程并行执行不同的任务。

当我们启动某个程序时，就会创建一个进程来执行任务代码，同时会为该进程分配内存空间，该应用程序的状态都保存在该内存空间里。当应用关闭时，该内存空间就会被回收。进程可以启动更多的进程来执行任务，由于每个进程分配的内存空间是独立的，如果两个进程间需要传递某些数据，则需要通过进程间通信管道IPC来传递。很多应用程序都是多进程的结构，由于进程间相互独立，这样避免某一个进程卡死，这样不会影响到整个应用程序。

但早期的浏览器并不是多进程的结构，而是个单进程结构。现在浏览器是一个多进程结构。

一个进程中大概有页面线程负责页面渲染和展示等，JavaScript线程执行js代码，还有其他各种线程。单进程的结构引发了很多的问题。一是不稳定，其中一个线程的卡死可能会导致整个进程出问题，比如你打开多个标签页，有一个标签页卡死，可能会导致整个浏览器无法正常运行，二是不安全，线程之间是可以共享数据，js线程就可以随意访问进程内的数据，三是不流畅，一个进程需要负责太多事情，会导致运行效率的问题。

所以为了去解决以上这些问题，现在采用了多进程浏览器结构。根据进程功能不同来拆解浏览器，我们可以将它们分解为这样的结构。

浏览器进程负责与浏览器的其他进程协调工作，用来协调各个进程。

网络进程负责发起接受网络请求

GPU进程负责图形渲染

插件进程负责控制网站使用的所有插件，例如Flash。（这里插件并不是指的是Chrome市场里安装的扩展。）

Extension 进程、渲染器进程用来控制显示tab标签内的所有内容

Chrome在默认情况下会为每个标签页都创建一个进程。

在Chromium的官方文档（文档地址：https://www.chromium.org/developers/design-documents/process-models ）上，说明了Chrome一共有四种进程模型

分别是默认的Process-per-site-instance，默认情况下，Chromium为用户访问的网站的每个实例创建一个渲染器进程。这样可以确保来自不同站点的页面是独立呈现的，并且对同一站点的单独访问也是彼此隔离的。简单来说就是访问不同站点和同一站点的不同页面都会创建新进程。

Process-per-site同一站点使用同一进程。

Process-per-tab一个tab里的所有站点使用一个进程。

Single process则会让浏览器引擎和渲染器引擎共用一个进程。

该文档还说明了各个进程模型的好处和坏处。

显而易见，Process-per-site-instance模型会创建更多的进程占用更多的内存空间，但确实最安全，每个tab，以及tab内的每个站点都是相互隔离互不影响的。当其中一个标签页里渲染器进程卡死，并不会影响其他标签。

浏览器当前的所有进程我们都可以通过点击右上角的菜单按钮，然后点击选择更多工具的任务管理器，从任务管理器我们看到当前浏览器启动了哪些进程，并且每个进程的ID号，从里面我们还可以发现，我们安装的每个扩展程序，Chrome都为他们启动了一个单独的进程来运行。如果网页中嵌入了iframe，chrome会为每个iframe都创建了一个进程！那为什么为iframe也要创建单独的进程，主要还是出于安全考虑，通过多进程让当前的主站点和iframe里的站点之间隔离。

浏览器渲染原理

当你在地址栏输入地址时，浏览器进程的UI线程会捕捉你的输入内容，如果访问的是网址，则UI线程会启动一个网络线程来请求DNS进行域名解析。接着开始连接服务器获取数据。如果你的输入不是网址而是一串关键词，浏览器就会知道你是要搜索，于是就会使用默认配置的搜索引擎来查询。

当请求响应返回的时候，网络thread 会依据 Content-Type 及 MIME Type 判断响应内容的格式

如果响应内容的格式是 HTML ，下一步将会把这些数据传递给渲染进程，如果是 zip 文件或者其它文件，会把相关数据传输给下载管理器。

当网络线程获取到数据后，会通过SafeBrowsing来检查该站点的是否是恶意站点。如果是则会展示个警告页面，告诉你这个站点有安全问题，浏览器会阻止你的访问。当然你也可以强行继续访问。SafeBrowsing是谷歌内部的一套站点安全系统，通过检测该站点的数据来判断是否安全。比如通过查看该站点的ip是否在他们的黑名单内。

当返回数据准备完毕并且安全校验通过，网络线程会通知UI线程，我这准备好了，该你拉。然后UI线程会创建一个渲染器进程来渲染页面。浏览器进程通过IPC管道将数据传递给渲染器进程，正式进入渲染流程。

渲染器进程收到的数据，也就是html。渲染器进程的核心任务就是把html、js、css、img等资源渲染成用户可交互的web页面。

渲染器进程的主线程将html进行解析，构造DOM数据结构。DOM文档对象模型是浏览器对页面在其内部表示形式，是Web程序员可以通过JavaScript与之交互的数据结构和API。HTML首先经过Tokeniser标记化，通过词法分析，将输入html内容解析成多个标记，根据识别后的标记进行DOM树构造, 在 DOM树构造过程中会创建Document对象，然后以Document为根节点的DOM树不断进行修改，向其中添加各种元素。

HTML代码中往往会引入一些额外的资源，比如图片，css和js脚本等。图片和css这些资源需要通过网络下载或者从缓存中直接加载。这些资源不会阻塞html的解析，因为他们不会影响DOM的生成，但当html解析过程中遇到script标签，将停止html解析流程，转而去加载解析并且执行js。为什么不直接跳过js的加载和执行这一过程，等html解析完后再加载运行js呢？这是因为，浏览器不知道js的执行是否会改变当前页面的html的结构，如果js代码了调用document.write方法来修改html，那之前的html的解析就没有任何意义了。

在html解析完成后，我们就获得一个dom tree，但我们还不知道dom tree上每个节点应该长什么样。主线程需要解析css并确定每个DOM节点的计算样式，即使没有提供自定义的css样式，浏览器也有自己的默认的样式表，比如h2的字体要比h3的大。

在知道dom结构和每个节点的样式后，我们接下来需要知道每个节点需要放在页面上的哪个位置，也就是节点的坐标，以及该节点需要占用多大的区域。

这个阶段被称为layout布局，主线程通过遍历DOM和计算好的样式来生成layout tree，layout tree上的每个节点都记录x,y坐标和边框尺寸。这里需要注意的一点是DOM Tree和layout tree并不是一一对应的，设置了display:none的节点不会出现在layout tree上，而在before伪类中添加了content值的元素，content的内容会出现在layout tree,不会出现在DOM树里。这是因为DOM 是通过html解析获得，并不关心样式。而layout tree是根据dom tree和计算好的样式来生成，layout tree是和最后展示在屏幕上的的节点是对应的。

现在已经知道元素的大小，形状和位置，还需要知道以什么样的顺序绘制各个节点。举例来说，z-index这个属性会影响节点绘制的层级关系。如果我们按照dom的层级结构来绘制页面，则会导致错误的渲染。所以为了保证在屏幕上展示正确的层级，在绘制阶段，主线程遍历layout tree创建一个绘制记录表，该表记录了绘制的顺序。

现在知道了文档的绘制顺序，终于到了该把这些信息转化成像素点显示在屏幕的时候了。那这种行为，被称为栅格化。Chrome最早使用了一种很简单的方式，只栅格化用户可视区域的内容，当用户滚动页面时，再栅格化更多的内容来填充缺失的部分。这种方式带来的问题就是会导致展示延迟。随着不断的优化升级，现在的Chrome使用了一种更复杂的栅格化流程，叫做合成(compositing)。Compositing是一种将页面的各个部分分成多个图层，分别对其进行栅格化并在合成器线程的单独线程中进行合成页面的技术。简单来说就是，页面所有的元素按照某种规则进行分图层，并把图层都栅格化好了，然后只需要把可视区的内容组合成一帧展示给用户即可。

主线程遍历layout tree生成layer tree。

当layer tree生成完毕和绘制顺序确定后，主线程将这些信息传递给合成器线程。合成器线程将每个图层栅格化。一层可能像页面的整个长度一样大，因此合成器线程将它们切分为多个图块，然后将每个图块发送给栅格线程。

栅格线程栅格化每个图块并将它们存储在GPU内存中。对图块进行栅格化后。合成器线程可以给不同的栅格线程分别优先级，比如栅格化可视区域图块的栅格线程优先处理。

当图块栅格化完成后，合成器线程将收集称为“draw quads”的图块信息，这些信息里记录了包含诸如图块在内存中的位置和在页面的哪个位置绘制图块的信息。根据这些数据合成器线程生成了一个合成器帧。然后这个合成器帧通过IPC传送给浏览器进程，

接着浏览器进程将合成器帧传到GPU，然后GPU渲染展示到屏幕上。就能看到了页面内容。当你的页面变化，比如你滚动了当前页面，则会生成一个新的合成器帧，新的帧再传给GPU。再次渲染到屏幕上。

总结：浏览器进程的网络线程请求获取到html数据后，通过IPC将数据传给渲染器进程的主线程，主线程将html解析构造DOM树，然后计算样式，根据DOM树和样式生成layout Tree，通过遍历layout tree生成绘制顺序表，然后主线程将layout Tree和绘制顺序信息一起传给合成器线程，合成器线程按规则进程分图层，并把图层分为更小的图块传给栅格线程进行栅格化，栅格化完成后，合成器线程会获得栅格线程传过来的"draw quads"图块信息，根据这些信息，合成器线程合成了一个合成器帧，然后将该合成器帧通过IPC传回给浏览器进程，浏览器进程在传到GPU进行渲染，最后就展示到屏幕上了。

当改变一个尺寸位置属性时，会重新进行样式计算，布局，绘制，以及后面的所有流程。这种行为我们称为重排。当我们改变某个元素的颜色属性时，不会重新触发布局，但还是触发会样式计算和绘制，这个就是重绘。我们可以发现重排和重绘会占用主线程，js的运行也是在主线程。既然他们都是在主线程就会出现抢占执行时间的问题。

如果写了个不断导致重绘重排的动画，浏览器则需要在每一帧都会运行样式计算、布局和绘制的操作，我们知道当页面以每秒大于60帧的刷新率，才不会让用户感觉到页面卡顿。

如果你在运行动画时，还有大量的js任务需要执行，因为布局绘制和js的执行都是在主线程运行的，当在一帧的时间内，布局和绘制结束后，还有剩余时间，js就会拿到主线程的使用权，如果js执行时间过长就会导致在下一帧开始时，js没有及时归还主线程，导致下一帧动画没有按时渲染，就会出现页面动画的卡顿。

优化：可以通过requestAnimationFrame这个api来帮助我们解决这个问题。requestAnimationFrame这个方法会在每一帧被调用，通过这个api的回调参数，我们可以知道每一帧当前还剩余的时间，我们可以把js运行任务分成一些小块，在时间用完前，归还主线程，

还有第二个优化方法。刚才我们知道栅格化整个流程是不占用主线程的，只在合成器和栅格线程中运行，这就意味着它无需和js抢夺的主线程。刚才提到，如果我们反复重绘和重排，可能会导致掉帧，因为有可能会有js的执行阻塞了主线程。css中有个动画属性叫transform，通过该属性实现的动画，不会经过布局和绘制，而是直接运行在合成器和栅格线程中，所以不会受到主线程中js执行的影响。更重要的是transform的动画，由于不需要经过布局绘制样式计算，所以节省了很多运算时间。可以让复杂的动画更加流畅。位置变化，宽高变化，那这些都可以使用transform来代替。

所以说一个页面的动画好坏，比较影响用户的体验。