浏览器工作原理
一、浏览器发展史
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标签内的所有内容。浏览器在默认情况下会为每个标签页都创建一个进程
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代替。
