一、浏览器发展史
1991年：Berners-Lee建立了第一代网络浏览器：WorldWIdeWeb，它的功能十分简单，只支持显示文本、图片等
1993年：Mosaic问世，它可以同时显示文本和图像
1994年：网景浏览器发布，它是由曾经参与开发Mosaic的人共同创建，只能显示静态的html，没有css和js。同年出现了Opera浏览器
1995年：微软发布IE1.0和IE2.0。第一次浏览器大战开始
1996年：IE3.0和windows操作系统集成在一起，此时网景的市场份额达到了86%。IE发行后的4年里，在windows系统的帮助下，逐渐取代了网景浏览器的领导地位，达到了市场份额的75%
1998年：网景公司成立Mozilla基金会
1999年：IE占据市场的99%，第一次浏览器大战以IE胜出。前端开发的噩梦来了
2003年：苹果发布Safari浏览器，该浏览器被包含在所有苹果系统中
2004年：在网景公司的Mozilla基金会推动下，发布Firefox1.0，第二次浏览器大战开始
2005年：苹果开源了Safari浏览器的内核webkit
2008年：谷歌以苹果的webkit内核，创建了Chromium，发布Chrome浏览器
2015年：微软放弃IE，推出了基于webkit内核的Edge替代IE
2020年：5月，据Statcounter统计，Chrome浏览器占据市场百分之六十多
国产浏览器：都是披着马甲的IE，最近几年，国产浏览器拥有IE和chromium双内核。08年红芯科技为了融资宣称自主研发的浏览器是公司自己开发的内核，结果后来发布道歉信证实了使用的是chromium/blink内核。
研发内核是十分耗时耗力的，就拿chromium来说，据说Google最多时候召集1000个硅谷的程序员集中力量去开发chromium内核，花了至少十年。
二、浏览器结构
用户界面：展示除标签页窗口之外的其他用户界面
浏览器引擎：在用户界面和渲染引擎之间传递数据
渲染引擎：负责渲染用户请求的页面内容
渲染引擎可以说是一个浏览器的核心与灵魂，渲染引擎一般称为浏览器的内核。不同的浏览器使用的内核也不一样
| 浏览器 | 内核 |
| IE | Trident |
| Firefox | Gecko |
| Sarafi | webkit |
| Chrome、Opera、Edge | 基于webkit改造的Blink |
chromium早起的排版引擎是webkit，后面被Google改成了blink，虽然名字改了但是目前很多框架和原理还是webkit。不过随着浏览器内核的发展，blink和webkit将越走越远，最近的一个大改动就是使用最新的NG排版引擎。
Blink架构：
浏览器是运行在操作系统上的一个应用程序，每个应用程序必须至少启动一个进程来执行其功能。一个程序往往需要运行很多任务，进程会创建一些线程来帮助它执行这些细小的任务。
进程：操作系统进行资源分配和调度的基本单元，可以申请和拥有计算机资源，进程是程序的基本执行实体
线程：操作系统能够进行运算调度的最小单位，一个进程中可以并发多个线程，每条线程并行执行不同的任务
当启动某个程序时，就会创建一个进程来执行任务代码，同时会为该进程分配内存空间，该应用程序的状态都保存在该内存空间里。当应用关闭时，该内存空间就会被回收。进程可以启动更多的进程来执行任务，由于每个进程分配的内存空间是独立的，如果两个进程之间需要传递某些数据，需要通过进程间通信管道IPC来传递。很多应用程序都是多进程的结构，这样是为了避免某一个进程卡死，由于进程间相互独立，这样不会影响到整个应用程序。进程可以将任务分成多个更细小的任务，然后通过创建多个线程，并行执行不同的任务。同一进程下的线程之间是可以直接通向共享数据的。
早期的浏览器是一个单进程的结构。一个进程中大概有页面线程负责页面渲染和展示等，JavaScript线程执行js代码，还有其他各种线程。单进程的结构会引发很多的问题。一是不稳定，其中一个线程的卡死可能会导致整个进程出问题，比如打开多个标签页，其中一个卡死，可能会导致整个浏览器无法正常运行。二是不安全，线程之间可以共享数据，js线程随意访问进程内的数据。三是不流畅，一个进程需要负责太多事情，会导致运行效率的问题。
为了解决上述问题，现代浏览器采用多进程结构。根据进程功能不同来拆分浏览器
浏览器进程：负责与浏览器的其他进程协调工作
网络进程：发起接收网络请求
GPU进程：图形渲染
插件进程：控制网站使用的所有插件，如flash、Vue.js devtools
渲染器进程：控制显示tab标签内的所有内容。浏览器在默认情况下会为每个标签页都创建一个进程。核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
Chrome四种进程模型：
1、Process-per-site-instance（默认）：默认情况下，chromium为用户访问的网站的每个实例创建一个渲染器进程。这样可以确保来自不同站点的页面是独立呈现的，并且对同一站点的单独访问也是彼此隔离的。访问不同站点或访问同一站点的不同页面都会创建新进程
2、Process-per-site：同一站点使用同一进程
3、Process-per-tab：一个tab里的所有站点使用一个进程
4、Single process：浏览器引擎和渲染器引擎公用一个进程
显而易见，Process-per-site-instance模型会创建更多的进程占用更多的内存空间，但确实最安全。每个tab、以及tab内的每个站点都是相互隔离互不影响的。当其中一个标签页里渲染器进程卡死，不会影响到其他标签。
浏览器右上角菜单-更多工具-任务管理器查看进程
从中可以看到，安装的扩展程序，Chrome都为它们启动了一个进程来运行。如果网页中嵌入了iframe，Chrome会为每个iframe都创建一个进程，主要出于安全考虑，通过多进程将当前的主站点和iframe中的站点隔离。
三、浏览器渲染原理
当在地址栏输入地址时，浏览器进程的UI线程会捕捉输入内容，如果访问的是网址，UI线程会启动一个网络线程来请求DNS进行域名解析，接着开始连接服务器获取数据。如果输入的是一串关键词，浏览器就会知道是要搜索，于是会使用默认的搜索引擎来搜索。
网络线程获取到数据后会做什么事？
当网络进程获取到数据后，会通过SafeBrowsing来检查该站点是否是恶意站点。如果是则会展示个警告页面，告诉你这个站点有安全问题，浏览器会阻止你的访问。当然你也可以强行访问。SafeBrowsing是付个内部的一个站点安全系统，通过检查该站点的数据来判断是否安全。比如查看该站点的ip是否在他们的黑名单内。
当返回数据准备完毕，并且安全校验通过，网络线程会通知UI线程，我这准备好了，该你了。然后UI线程会创建一个渲染器线程来渲染页面。浏览器进程通过IPC管道将数据传递给渲染器进程，正式进入渲染进程。
此时地址栏的状态更新，比如history更新，现在可以点击导航栏的后退。渲染器进程收到的数据，也就是html。渲染器进程的核心任务就是把html、css、js、img等资源渲染成用户可交互的web页面。
渲染器进程的主线程将html解析，生成DOM数据结构。DOM文档对象模型是浏览器对页面在其内部的表示形式，是web程序员可以通过js与之交互的数据结构和api。html首先经过tokeniser标记化，通过词法分析，将输入html内容解析成多个标记，根据识别后的标记进行DOM树构造，在DOM树构造过程中会创建document对象，然后以document为根节点的DOM树不断进行修改，向其中添加各种元素。
html代码中往往会引入一些额外的资源，比如img、css、js等。img和css这些资源需要通过网络下载或从缓存中直接加载。这些资源不会阻塞html的解析，因为它们不会影响DOM的生成。但当DOM解析的过程中遇到script标签，将停止html解析流程，转而去加载解析并执行js。你可能就会问了？为什么不直接跳过js的加载和执行这一过程，等html解析完再加载运行js呢？这是因为，浏览器不知道js的执行是否会改变当前页面的html的结构，如果js调用了document.write方法来修改html，那之前的html解析就没有任何意义了。这就是为什么要将script标签放在body的底部，或者使用async defer来异步加载执行js。
在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创建一个绘制记录表，该表记录了绘制的顺序。
现在知道了文档的绘制顺序，终于到了该把这些信息转化成像素点显示在屏幕上的时候了，这种行为，称为resterizing，栅格化。Chrome最早使用了一种很简单的方式，只栅格化用户可视区域的内容，当用户滚动页面时，再栅格化更多的内容来填充确实的部分。这种方式带来的问题显而易见，会导致展示延迟。随着不断的优化升级，现在的Chrome使用了一种更复杂的栅格化流程，叫做compositing组合。compositing是一种将页面的各个部分分为多个图层，分别对其进行栅格化并在合成器线程compositor thread的单独线程中进行合成页面。简单来说就是，页面所有的元素按照某种规则进行分图层，并把图层都栅格化好了，然后只需要把可视区的内容组成一帧展示给用户即可。
主线程遍历layout tree生成layer tree。当layer tree生成完毕和确定绘制顺序后，主线程将这些信息传递给compositor线程。合成器线程将每个图层栅格化。一层可能像页面的整个长度一样大，因此合成器线程将它们切分为多个图块，然后将每个图块发送给栅格线程。
栅格线程栅格化每个图块并将它们存储在GPU内存中，对图块进行栅格化后，合成器线程可以给不同的栅格线程分配优先级，比如栅格化可视区域图块的栅格线程优先处理。
当图块栅格化完成后，合成器线程将收集称为“draw quads”的图块信息，这些信息里记录了包含诸如图块在内存中的位置和在页面的哪个位置绘制图块的信息。根据这些数据合成器线程生成了一个合成器Frame。然后这个合成器frame通过IPC传送给浏览器进程。接着浏览器进程将compositor frame传到GPU，然后GPU渲染展示到屏幕上。终于看到了页面内容，当滚动页面时，则会生成一个新的compositor frame，新的frame再传给GPU，再次渲染到屏幕上。
浏览器进程的网络线程请求获取到html数据和通过IPC将数据传给渲染器进程的主线程，主线程将html解析构造DOM树，然后计算样式，根据DOM树和样式生成layout tree，通过遍历layout tree生成绘制顺序表，然后主线程将layout tree和绘制顺序表一起传给合成器线程，合成器线程按规则进行分图层，并把图层分为更小的图块传给栅格线程进行栅格化，栅格化完成后，合成器线程会获取栅格线程传来的“draw quads”图块信息，根据这些信息，合成器合成了一个frame，然后将该合成frame通过IPC传回给浏览器进程，浏览器进程再传到GPU进行渲染，最后就展示到屏幕上。
当我们改变一个尺寸位置属性时，会重新进行样式计算、布局、绘制，以及后面的所有流程，这种行为称为重排。当改变某个元素的颜色属性时，不会重新触发布局，但还是会触发样式计算和绘制，这个就是重绘。可以发现重排和重绘都会占用主线程，js也会运行在主线程，既然都在主线程，就会出现抢占执行时间的问题。
如果写了个不断导致重排重绘的动画，浏览器则需要在每一帧都会运行样式计算、布局和绘制的操作，当页面以每秒大于60帧的刷新率，才不会让用户感觉到页面卡顿。
如果在运行动画时，还有大量的js任务需要执行，因为布局绘制和js的执行都在主线程上，当在一帧的时间内，布局和绘制结束后，还有剩余时间，js就会拿到主线程的使用权，如果js执行时间过长就会导致在下一帧开始时，js没有及时归还主线程，导致下一帧动画没有按时渲染，就会出现页面动画的卡顿。
那有什么优化的手段吗？
第一种通过requestAnimationFrame这个api来帮助解决这个问题。requestAnimationFrame会在每一帧被调用，通过这个api的回调参数，可以知道每一帧当前还有剩余的时间，可以把js运行任务分成一些小块，在时间用完前，归还主线程。react最新的渲染引擎react fiber就是用到了这个api来做了很多优化。
第二种，因为栅格化的整个流程是不占用主线程的，只在合成器和栅格线程中运行，这就意味着它无需和js抢夺主线程。如果反复的重排重绘会造成掉帧，因为有可能会有js的执行阻塞了主线程。css中有个动画属性transform，通过该属性实现的动画，不会进过布局和绘制，而是直接运行在compositor和rasterizing线程中，所以不会受到主线程中js执行的影响。更重要的是transform的动画，由于不需要经过布局和绘制，节省了很多计算的时间，可以让复杂的动画更加流畅。位置、宽高这些动画都可以使用transform代替。
四、浏览器工作流程
完整的HTTP服务过程
当我们在web浏览器输入www.baidu.com后
1. 根据www.baidu.com这个域名发起DNS请求返回对应的IP
当然浏览器还提供了 DNS 数据缓存服务，如果某个域名已经解析过了，那么浏览器会缓存解析的结果，以供下次查询时直接使用，这样也会减少一次网络请求。
拿到 IP 之后，接下来就需要获取端口号了。通常情况下，如果 URL 没有特别指明端口号，那么 HTTP 协议默认是 80 端口。
2. 拿到IP后找到对应的服务器建立TCP连接(三次握手)
3. 建立TCP连接后发起HTTP请求(这个请求是在TCP中的传输数据实现)
首先浏览器会向服务器发送请求行，它包括了请求方法、请求 URI（Uniform Resource Identifier）和 HTTP 版本协议。
在浏览器发送请求行命令之后，还要以请求头形式发送其他一些信息，把浏览器的一些基础信息告诉服务器。比如包含了浏览器所使用的操作系统、浏览器内核等信息，以及当前请求的域名信息、浏览器端的 Cookie 信息，等等。
首先服务器会返回响应行，包括协议版本和状态码。
4. 服务器响应后，浏览器首先得到html并解析它，然后会请求html中的资源(如js、css、图片等)
5. 浏览器解析html、css、js等并渲染呈现出页面给用户
由于渲染机制过于复杂，所以渲染模块在执行过程中会被划分为很多子阶段，输入的 HTML 经过这些子阶段，最后输出像素。我们把这样的一个处理流程叫做渲染流水线，其大致流程如下图所示：
按照渲染的时间顺序，流水线可分为如下几个子阶段：构建 DOM 树、样式计算、布局阶段、分层、绘制、分块、光栅化和合成。
解析HTML转换DOM树
因为浏览器无法直接理解和使用 HTML，所以需要将 HTML 转换为浏览器能够理解的结构——DOM 树。首先浏览器会解析HTML文件生成DOM树
可以打开浏览器的控制器，输入document来获得更直观的dom树结构
现在浏览器已经生成DOM树了，但是我们还不知道每个节点的样式是怎么样的，下面开始样式计算
解析CSS转换为styleSheets
渲染引擎会把获取到的 CSS 文本全部转换为 styleSheets 结构中的数据，并且该结构同时具备了查询和修改功能，这会为后面的样式操作提供基础。
紧接着会将属性值标准化
body { font-size: 2em }
p {color:blue;}
span {display: none}
div {font-weight: bold}
div p {color:green;}
div {color:red; }
将所有值转换为渲染引擎容易理解的、标准化的计算值，这个过程就是属性值标准化。
然后通过CSS的继承规则和层叠规则计算DOM 树中每个节点的样式属性
布局阶段
现在，我们有 DOM 树和 DOM 树中元素的样式，但这还不足以显示页面，因为我们还不知道 DOM 元素的几何位置信息。那么接下来就需要计算出 DOM 树中可见元素的几何位置，我们把这个计算过程叫做布局。
Chrome 在布局阶段需要完成两个任务：创建布局树和布局计算。
为了构建布局树(也可以理解为渲染树，不过有一点本质的区别)，浏览器大体上完成了下面这些工作：
遍历 DOM 树中的所有可见节点，并把这些节点加到布局树中；
而不可见的节点会被布局树忽略掉，如 head 标签下面的全部内容，再比如 body.p.span 这个元素，因为它的属性包含 dispaly:none，所以这个元素也没有被包进布局树。
布局计算在执行布局操作的时候，会把布局运算的结果重新写回布局树中，所以布局树既是输入内容也是输出内容，这是布局阶段一个不合理的地方，因为在布局阶段并没有清晰地将输入内容和输出内容区分开来。针对这个问题，Chrome 团队正在重构布局代码，下一代布局系统叫 LayoutNG，试图更清晰地分离输入和输出，从而让新设计的布局算法更加简单。
分层
页面中有很多复杂的效果，如一些复杂的 3D 变换、页面滚动，或者使用 z-indexing 做 z 轴排序等，为了更加方便地实现这些效果，渲染引擎还需要为特定的节点生成专用的图层，并生成一棵对应的图层树（LayerTree）
打开 Chrome 的“开发者工具”，选择“Layers”标签，就可以可视化页面的分层情况
浏览器的页面上实际分成了很多图层，这些图层叠加后形成了页面
通常情况下，并不是布局树的每个节点都包含一个图层，如果一个节点没有对应的层，那么这个节点就从属于父节点的图层。**如上图中的 span 标签没有专属图层，那么它们就从属于它们的父节点图层。
构建了图层树后执行会图层绘制操作，会把一个图层的绘制拆分成很多小的绘制指令(从最低层再到最上层)，然后再把这些指令按照顺序组成一个待绘制列表所以在图层绘制阶段，输出的内容就是这些待绘制列表。
栅格化（raster）操作
绘制列表只是用来记录绘制顺序和绘制指令的列表，而实际上绘制操作是由渲染引擎中的合成线程来完成的。
你可以结合下图来看下渲染主线程和合成线程之间的关系
其中栅格化的线程池有渲染进程来维护。
通常，栅格化过程都会使用 GPU 来加速生成，使用 GPU 生成位图的过程叫快速栅格化，或者 GPU 栅格化，生成的位图被保存在 GPU 内存中。
合成和显示
一旦所有图块都被光栅化，合成线程就会生成一个绘制图块的命令——“DrawQuad”，然后将该命令提交给浏览器进程。
浏览器进程里面有一个叫 viz 的组件，用来接收合成线程发过来的 DrawQuad 命令，然后根据 DrawQuad 命令，将其页面内容绘制到内存中，最后再将内存显示在屏幕上。
到这里，经过这一系列的阶段，编写好的 HTML、CSS、JavaScript 等文件，经过浏览器就会显示出漂亮的页面了。
6. 到了这一步，可以关闭TCP连接了(TCP的四次挥手)
渲染流水线总结
从 HTML 到 DOM、样式计算、布局、图层、绘制、光栅化、合成和显示。下面我用一张图来总结下这整个渲染流程：
