1.浏览器的发展史
1992年，托尼哟翰逊(Tony Johnson)发布了Midas，它允许用户浏览UNIX和VMS网页上的文档。
1993年，NCSA发布了Mosaic浏览器。Mosaic问世，这是一种可以同时显示文本和图像的浏览器，一经推出就受到全球用户的欢迎。
1994年：网景浏览器发布，它是由曾经参与开发Mosaic的人共同创建，虽然网景的功能也十分有限，只能显示简单的静态html，没有js，css，但依然大受欢迎，获得世界范围内的成功，并占领了绝大多数市场份额。同年也出现了Opera。
1995年微软发布了万恶的IE1.0,IE2.0，自此第一次浏览器大战正式打响。
1996年发布的IE3.0和windows操作系统集成在了一起，而此时网景的市场份额已经达到了86%。IE发行后的4年内，在windows操作系统的帮助下，逐渐取代了网景浏览器的领导地位，达到了市场份额的75％。
1999年，它已经占据了浏览器市场的99％，前端工程师的噩梦来临了。然而网景公司并没有一蹶不振，网景在1998年成立了Mozilla基金会，在该基金会的推动下，网景公司开发了著名的开源项目火狐浏览器Firefox来迎击IE，并在2004年发布了1.0版本，拉开了第二次浏览器大战。
2003年，苹果发布了Safari浏览器，而且该浏览器被包含在所有苹果操作系统中，更重要的是，在2005年苹果开源了Safari浏览器的内核webkit。
2008年，谷歌以苹果开源项目WebKit作为内核，创建了一个新的项目Chromium，在该项目的基础上发布了自己的浏览器产品Chrome，Chrome发展十分迅速，现在已经成为全球最受欢迎的浏览器。由于IE的性能和体验问题，IE逐渐掉队。-
2015年，微软也放弃了IE，推出了基于webkit内核的Edge浏览器作为IE的替代品
根据statscounter统计，截止2020年5月份，各个浏览器的市场份额下。Chrome已经占据百分之60多的市场份额。再看看国内的浏览器。我记得小时候身边的人的浏览器都是被360或者qq浏览器统治了，后来才知道，长大后才知道你们都是披着马甲的IE！！不过近几年国内浏览器的都是IE和chromium双内核。
2.常见浏览器的内核
浏览器最重要或者说核心的部分是“Rendering Engine”，可大概译为“渲染引擎”，不过我们一般习惯将之称为“浏览器内核”。负责对网页语法的解释并渲染（显示）网页。 所以，通常所谓的浏览器内核也就是浏览器所采用的[渲染引擎]，渲染引擎决定了浏览器如何显示网页的内容以及页面的格式信息。
基于safari浏览器的WebKit的开源项目
- 苹果的safari浏览器：WebKit
- 谷歌的chrome浏览器：Blink
- 微软的Edge浏览器： Blink
- opera浏览器：Blink
其他浏览器的内核
- IE ：Trident
- FireFox: Gecko
3.浏览器的结构
这里有一个简化的浏览器结z构图。我们大致可以简单的分为用户界面、浏览器引擎、渲染引擎。用户界面用于展示除标签页窗口之外的其他用户界面内容。渲染引擎负责渲染用户请求的页面内容。在用户界面和渲染引擎之间有个浏览器引擎，用于在用户界面和渲染引擎之间传递数据。渲染引擎下面还有很多小的功能模块，比如负责网络请求的网络模块，用于解析和执行js的js解释器。还有数据存储持久层，帮助浏览器保存各种数据，比如cookie等等。
1.进程与线程
- 进程就是程序的一次执行过程，计算机的内存会为进程分配独立的内存空间，当程序执行结束后，所占的内存空间就会被回收。每个进程所分配的内存空间都是独立的，进程间要相互通信，需要用到IPC通信管道。现在的应用大多都是都进程的，避免了因一个进程的卡死导致整个应用崩溃。
- 线程是cpu可调度的最小单元，进程将任务分成更小的任务分配给线程处理，同一个进程内的线程可以进行数据共享。
那今天的主角浏览器也是一个多进程结构。但早期的浏览器并不是多进程的结构，而是个单进程结构。一个进程中大概有页面线程负责页面渲染和展示等，JavaScript线程执行js代码，还有其他各种线程。单进程的结构引发了很多的问题。一是不稳定，其中一个线程的卡死可能会导致整个进程出问题，比如你打开多个标签页，有一个标签页卡死，可能会导致整个浏览器无法正常运行，二是不安全，线程之间是可以共享数据，那js线程岂不是可以随意访问进程内的数据，三是不流畅，一个进程需要负责太多事情，会导致运行效率的问题。所以为了去解决以上这些问题，现在采用了多进程浏览器结构。根据进程功能不同来拆解浏览器，我们可以将它们分解为这样的结构。
其中，浏览器进程负责与浏览器的其他进程协调工作。你可以把他想成一个工厂里的主管，用来协调各个进程部门。网络进程负责发起接受网络请求，GPU进程负责图形渲染，插件进程负责控制网站使用的所有插件，例如Flash。这里插件并不是指的是Chrome市场里安装的扩展。Extension 进程渲染器进程用来控制显示tab标签内的所有内容，浏览器在默认情况下会为每个标签页都创建一个进程。
4.浏览器的渲染原理
1 当你在地址栏输入地址时，浏览器进程的UI线程会捕捉你的输入内容，如果访问的是网址，则UI线程会启动一个网络线程来请求DNS进行域名解析接着开始连接服务器获取数据。如果你的输入不是网址而是一串关键词，浏览器就会知道你是要搜索，于是就会使用你默认配置的搜索引擎来查询。当网络线程获取到数据后，会通过SafeBrowsing来检查该站点的是否是恶意站点。如果是则会展示个警告页面，告诉你这个站点有安全问题，浏览器会阻止你的访问。当然你也可以强行继续访问。SafeBrowsing是谷歌内部的一套站点安全系统，通过检测该站点的数据来判断是否安全。比如通过查看该站点的ip是否在他们的黑名单内。当返回数据准备完毕并且安全校验通过，网络线程会通知UI线程，我这准备好了，该你拉。然后UI线程会创建一个渲染器进程来渲染页面。浏览器进程通过IPC管道将数据传递给渲染器进程，正式进入渲染流程。
2 此时地址栏的状态更新，比如histroy更新，现在可以点击导航栏的后退。渲染器进程收到的数据，也就是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的解析就没有任何意义了。这也就是为什么我们一直说要把script标签要放在合适的位置，或者使用async 或defer属性来异步加载执行js。
3 在html解析完成后，我们就获得一个dom tree，但我们还不知道dom tree上每个节点应该长什么样。主线程需要解析css并确定每个DOM节点的即使你没有提供自定义的css样式，浏览器也有自己的默认的样式表，比如h2的字体要比h3的大，具体默认的样式表可以在这里查看。
4 在知道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创建一个绘制记录表，该表记录了绘制的顺序。
5 现在知道了文档的绘制顺序，终于到了该把这些信息转化成像素点显示在屏幕的时候了。那这种行为，被称为rasterizing,栅格化。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。再次渲染到屏幕上。
6.总结： 浏览器进程的网络线程请求获取到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运行任务分成一些小块，在时间用完前，归还主线程。还有第二个优化方法。刚才我们知道栅格化整个流程是不占用主线程的，只在合成器和栅格线程中运行，这就意味着它无需和js抢夺的主线程。刚才提到，如果我们反复重绘和重排，可能会导致掉帧，因为有可能会有js的执行阻塞了主线程。css中有个动画属性叫transform，通过该属性实现的动画，不会经过布局和绘制，而是直接运行在Compositor和rasterizing线程中，所以不会受到主线程中js执行的影响。更重要的是transform的动画，由于不需要经过布局绘制样式计算，所以节省了很多运算时间。可以让复杂的动画更加流畅。我们常常会哪些属性来实现动画效果呢，位置变化，宽高变化，那这些都可以使用transform来代替。所以说一个页面的动画好坏，可以说是十分影响用户的体验。