浏览器运行机制详解
前言
你们确定都据说过不少浏览器优化原则吧，例如说减小DOM操做，使用transformX（0）进行硬件优化，避免js文件执行时间过长使得页面卡顿等等。大部分人可能都知道，但也仅限于知道，即知其然，不知其因此然。css
学习要造成本身的知识体系，不然的话，每每是东一榔头西一榔头地学习知识，这样致使学习到的知识松散，没法造成内在的联系，也就致使了学习地不够深刻，只是浮于表面，只是“记住”了知识。html
因此，接下来，我想来为你们梳理一下浏览器运行过程当中须要理解的知识，以下：前端
- 前言
- 进程与线程
- 浏览器进程
- 浏览器都有哪些进程
- 浏览器内核（renderer进程）
- html解析
- css解析
- render树
- 回流与重绘
- 何时会发生回流与重绘
- 具体什么操做会引发回流
- 如何减小回流
- 硬件加速
- 如何才能使用硬件加速
- 硬件加速使用z-index
- 浏览器页面的渲染流程
- DOMContentLoaded和load事件
- css堵塞状况
- js堵塞状况
- css和js文件应当放在html哪一个位置
- 事件循环机制
- 宏任务和微任务
- 致使页面没法响应的缘由
- html文件解析过程
- 参考连接
进程与线程
能够这样理解：
web
- 进程是一个工厂，每一个工厂有其独立的资源。
- 线程是工厂中的工人，可能只有一个，可能有好多个。多个工人协同完成工做。工人共享工做资源。
回到硬件上来理解：segmentfault
- 工厂的资源 -> 系统分配的内存。
- 工厂之间相互独立 -> 进程之间相互独立，也即进程分配到的内存相互独立，没法读到对方内存中的数据。
- 一个工厂有一个或多个工人 -> 一个线程中有一个或多个线程。
- 多个工人协同完成工做 -> 进程中多个线程协同完成工做。即线程之间能互相发送请求与接收结果。
- 工人共享工做资源 -> 进程中全部线程都能访问到相同一块内存，即信息是互通的。
不过在这里要强调一点：一个软件不等于一个进程，一个软件可能包含有多个互相独立的进程。浏览器
最后，再用官方的术语描述下进程与线程的差异网络
- 进程是系统资源分配的最小单位（即系统以进程为最小单位分配内存空间，同时进程是能独立运行的最小单位）
- 线程是系统调度的最小单位（即系统以线程为单位分配cpu中的核。）
tips：多线程
- 进程之间也能互相通讯，不过代价比较大。
浏览器进程
首先，明确的是：浏览器是多线程的。并发
以Chrome浏览器为例：框架
你们有兴趣的话，也能够打开Chrome的任务管理器测试。由图可知，Chrome中有多个进程（每一个tab页面对应一个进程，以及Browser进程，GPU进程和插件进程）。
浏览器都有哪些进程
浏览器中的进程分别是：
- Browser进程 : 是浏览器的主进程，负责主控，协调，只有一个，能够看作是浏览器的大脑。
- 负责下载页面的网络文件
- 负责将renderer进程获得的存在内存中的位图渲染（显示）到页面上
- 负责建立和销毁tab进程（renderer进程）
- 负责与用户的交互
- GPU进程 ： 只有一个。
- 负责3D绘制，只有当该页面使用了硬件加速才会使用它，来渲染（显示）页面。不然的话，不使用这个进程，而是用Browser进程来渲染（显示）页面
- renderer进程：又名浏览器内核，每一个tab页面对应一个独立的renderer进程，内部有多个线程。
- 负责脚本执行，位图绘制，事件触发，任务队列轮询等
- 第三方插件进程：每种类型的插件对应一个进程。
浏览器是多进程的好处很是明显，若是浏览器是单线程的话，则一个页面，一个插件的崩溃会致使整个浏览器崩溃，用户体验感会很是差。
浏览器内核（renderer进程）
，弄懂了这一部分的知识，那么你对一个网页的运行机制也就能有个框架了。
renderer进程是多线程的，如下是各个线程的名称及做用（仅列举常驻线程）：
- js引擎线程：
- 也称js内核，解析js脚本，执行代码
- 与GUI线程互斥，即当js引擎线程运行时，GUI线程会被挂起，当js引擎线程结束运行时，才会继续运行GUI线程
- 由一个主线程和多个web worker线程组成，因为web worker是附属于主线程，没法操做dom等，因此js仍是单线程语言（在主线程运行js代码）
- GUI渲染线程：
- 用于解析html为DOM树，解析css为CSSOM树，布局layout，绘制paint
- 当页面须要重排reflow，重绘repaint时，使用该线程
- 与js引擎线程互斥
- 事件触发线程
- 当对应事件触发（不管是WebAPIs完成事件触发，仍是页面交互事件触发）时，该线程会将事件对应的回调函数放入callback queue（任务队列）中，等待js引擎线程的处理
- 定时触发线程
- 对应于setTimeout，setInterval API，由该线程来计时，当计时结束，将事件对应的回调函数放入任务队列中
- 当setTimeout的定时的时间小于4ms，一概按4ms来算
- http请求线程
- 每有一个http请求就开一个该线程
- 当检测到状态变动的话，就会产生一个状态变动事件，若是该状态变动事件对应有回调函数的话，则放入任务队列中
- 任务队列轮询线程
- 用于轮询监放任务队列，以知道任务队列是否为空
想必你们对renderer进程里的组成及职能有个大概的认知了，接下来，咱们会着重于细节来进行研究。
html解析
html解析包含有一系列的步骤，过程为Bytes -> Characters -> Tokens -> Nodes -> DOM。最终将html解析为DOM树。
假设有一html页面，代码以下：
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1">
<link href="style.css" rel="stylesheet">
<title>Critical Path</title>
</head>
<body>
<p>Hello <span>web performance</span> students!</p>
<div><img src="awesome-photo.jpg"></div>
</body>
</html>
处理过程以下：
最终生成的DOM树：
css解析
与html解析相似，他解析最终造成CSSOM树，过程为Bytes -> Characters -> Tokens -> Nodes -> CSSOM。
假设css代码以下：
body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }
获得的CSSOM为：
render树
由DOM树与CSS树结合造成的渲染树（其中没法显示的元素，如script，head元素或diplay：none的元素，不会在渲染树中，也就最终不会被渲染出来），页面的布局，绘制都是以render树为依据。
由以上的DOM树与CSSOM树，最终获得的渲染树以下：
回流与重绘
在此以前，咱们先明确另外两个概念：布局与绘制。
- 布局是页面首次加载时进行的操做，从新布局即为回流。
- 绘制是页面首次加载时进行的操做，从新绘制即为重绘。
何时会发生回流和重绘呢：
- 当页面的某部分元素发生了尺寸、位置、隐藏发生了改变，页面进行回流。得对整个页面从新进行布局计算，将全部尺寸，位置受到影响的元素回流。
- 当页面的某部分元素的外观发生了改变，但尺寸、位置、隐藏没有改变，页面进行重绘。（一样，只重绘部分元素，而不是整个页面重绘）
回流的同时每每会伴随着重绘，重绘不必定致使回流。因此回流致使的代价是大于重绘的。
若是你们对这二者的差异还不是很清楚的话，我引用这两张图给你们：
回流
重绘
那么具体什么操做会引发回流呢：
- 页面初始化渲染
- 窗口的尺寸变化
- 元素的尺寸、位置、隐藏变化
- DOM结构发生变化，如删除节点
- 获取某些属性，引起回流
- 不少浏览器会对回流进行优化，必定时间段后或数量达到阕值时，作一次批处理回流。
- 当获取一些属性时，浏览器为了返回正确的值也会触发回流，致使浏览器优化无效，有：
- offset（top/bottom/left/right）
- client (top/bottom/left/right)
- scroll (top/bottom/left/right)
- getComputedStyle()
- width,height
- 其次，字体大小修改及内容更新也会致使回流
频繁的回流与重绘会致使频繁的页面渲染，致使cpu或gpu过量使用，使得页面卡顿。
那么如何减小回流呢：
- 减小逐项更改样式，最好一次性更改style，或是将更改的样式定义在class中并一次性更新
- 避免循环操做DOM，而是新建一个节点，在他上面应用全部DOM操做，而后再将他接入到DOM中
- 当要频繁获得如offset属性时，只读取一次而后赋值给变量，而不是每次都获取一次
- 将复杂的元素绝对定位或固定定位，使他脱离文档流，不然回流代价很高
- 使用硬件加速建立一个新的复合图层，当其须要回流时不会影响原始复合图层回流
硬件加速
咱们在未开启硬件加速的时候是使用cpu来渲染页面，只有开启了硬件加速了，才会使用到GPU渲染页面。
在详细讲解硬件加速前，咱们先来说解一下简单图层和复合图层
- DOM中的每一个结点对应一个简单图层
- 复合图层是各个简单图层的合并，一个页面通常来讲只有一个复合图层，不管你建立了多少个元素，都是在这个复合图层中
- 其次，absolute、fixed布局，可使该元素脱离文档流，但仍是在这个复合图层中，因此他仍是会影响复合图层的绘制，但不会影响重排
当一个元素使用硬件加速后，会生成一个新的复合图层，这样无论其如何变化，都不会影响原复合图层。不过不要大量使用硬件加速，会致使资源消耗过分，致使页面也卡。
因此，使用了硬件加速后，会有多个复合图层，而后多个复合图层互相独立，单独布局、绘制。
如何才能使用硬件加速；
- translate3d,translateZ
- opacity属性
硬件加速时请使用z-index
具体原理是这样的：
当一个元素使用了硬件加速，在其后的元素，若z-index比他大或者相同，且absolute或fixed的属性相同，则默认为这些元素也建立各自的复合图层。
因此咱们人为地为这个元素添加z-index值，从而避免这种状况
浏览器页面的渲染流程
通过以上的学习，咱们能够清楚浏览器的渲染过程了：
1. 解析html获得DOM树
2. 解析css获得CSS树
3. 合并获得render树
4. 布局，当页面有元素的尺寸、大小、隐藏有变化或增长、删除元素时，从新布局计算，并修改页面中全部受影响的部分
5. 绘制，当页面有元素的外观发生变化时，从新绘制
6. GUI线程将获得的各层的位图（每一个元素对应一个普通图层）发送给Browser进程，由Browser进程将各层合并，渲染在页面上
DOMContentLoaded和load事件
这二者的差异，由其定义就可知：
- DOMContentLoaded：当DOM加载完成触发
- load：当DOM，样式表，脚本都加载完时触发
因此能够知道，DOMContentLoaded在load以前触发
css的堵塞状况
首先，是在Browser进程中下载css文件，当下载完成后，发送给GUI线程。
其次，是在GUI线程中解析html及css，不过这二者是并行的。
因为css的下载和解析不会影响DOM树，因此不会堵塞html文件的解析，但会堵塞页面渲染。
这样的设计是很是合理的，若是css文件的下载和解析不会堵塞页面渲染，那么在页面渲染的途中或结束后发现元素样式有变化，则又须要回流和重绘。
js的堵塞状况
明确的是，js文件的下载和解析执行都会堵塞html文件的解析及页面渲染。
由于js脚本可能会改变DOM结构，如果其不堵塞html文件的解析及页面渲染的话，那么当js脚本改变DOM结构或元素样式时，会引起回流和重绘，会形成没必要要的性能浪费，不如等待js执行完，在进行html解析和页面渲染。
若是你不想js堵塞的话，则使用async属性，这样就能够异步加载js文件，加载完成后当即执行。
css和js文件应当放在html哪一个位置
js：
当须要在DOM树完成以前用js进行初始化操做的话，在head中使用js。
若是是须要在DOM树造成以后，即要操做DOM，则在body元素的末尾。不过也可使用load事件。
若是js的内容比较小，则推荐使用内部js而不是引用js，这样能够减小http请求。
css：
通常放在head中，由于css的解析不影响html的解析，因此越早引入，越早同时解析。
事件循环机制
事件循环机制在个人这篇文章有详细的说明：http://www.javashuo.com/article/p-wjqgadlf-n.html
总结一句话：
事件循环机制的核心是事件触发线程，因为执行栈产生异步任务，异步任务完成后事件触发线程将其回调函数传入到任务队列中，当执行栈为空，任务队列将队列头的回调函数入执行栈，从而新的一轮循环开始。这就是称为循环的缘由。
宏任务和微任务
宏任务（macrotask）：
- 主代码块和任务队列中的回调函数就是宏任务。
- 为了使js内部宏任务和DOM任务可以有序的执行，每次执行完宏任务后，会在下一个宏任务执行以前，对页面从新进行渲染。（宏任务 -> 渲染 -> 宏任务）
微任务（microtask）：
- 在宏任务执行过程当中，执行到微任务时，将微任务放入微任务队列中。
- 在宏任务执行完后，在从新渲染以前执行。
- 当一个宏任务执行完后，他会将产生的全部微任务执行完。
分别在什么场景下会产生宏任务或微任务呢：
- 宏任务：主代码块，setTimeout，setInterval（任务队列中的全部回调函数都是宏任务）
- 微任务：Promise
致使页面没法当即响应的缘由
致使页面没法响应的缘由是执行栈中还有任务未执行完，或者是js引擎线程被GUI线程堵塞。
html文件解析过程
这个过程是在下载html文件以后，不包括网络请求过程
1. Browser进程下载html文件并将文件发送给renderer进程
2. renderer进程的GUI进程开始解析html文件来构建出DOM
3. 当遇到外源css时，Browser进程下载该css文件并发送回来，GUI线程再解析该文件，在这同时，html的解析也同时进行，但不会渲染（还未造成渲染树）
4. 当遇到内部css时，html的解析和css的解析同时进行
5. 继续解析html文件，当遇到外源js时，Browser进程下载该js文件并发送回来，此时，js引擎线程解析并执行js，由于GUI线程和js引擎线程互斥，因此GUI线程被挂起，中止继续解析html。直到js引擎线程空闲，GUI线程继续解析html。
6. 遇到内部js也是同理
7. 解析完html文件，造成了完整的DOM树，也解析完了css，造成了完整的CSSOM树，二者结合造成了render树
8. 根据render树来进行布局，若在布局的过程当中发生了元素尺寸、位置、隐藏的变化或增长、删除元素时，则进行回流，修改
9. 根据render树进行绘制，若在布局的过程当中元素的外观发生变换，则进行重绘
10. 将布局、绘制获得的各个简单图层的位图发送给Browser进程，由它来合并简单图层为复合图层，从而显示到页面上
11. 以上步骤就是html文件解析全过程，完成以后，如若当页面有元素的尺寸、大小、隐藏有变化时，从新布局计算回流，并修改页面中全部受影响的部分，如若当页面有元素的外观发生变化时，重绘
(完)
参考连接
1.CSS3硬件加速也有坑http://web.jobbole.com/83575/
2.浏览器渲染过程、回流、重绘简介https://blog.csdn.net/cxl444905143/article/details/42005333
3.页面优化，谈谈重绘(repaint)和回流(reflow)http://www.javashuo.com/article/p-zlayxuan-bo.html
4.你真的了解回流和重绘吗http://www.javashuo.com/article/p-wnorqsqz-cb.html
5.css加载会形成阻塞吗？http://www.javashuo.com/article/p-dcjijisn-da.html
6.从浏览器多进程到JS单线程，JS运行机制最全面的一次梳理http://www.javashuo.com/article/p-apnenkgt-db.html
7.从输入URL到页面加载的过程？如何由一道题完善本身的前端知识体系！http://www.javashuo.com/article/p-ruyhecrz-do.html
- 1. 浏览器运行机制
- 2. 浏览器与JS运行机制
- 3. 浏览器底层运行机制
- 4. JS运行机制、浏览器缓存
- 5. 浏览器缓存机制详解
- 6. 浏览器的渲染机制以及JS运行机制
- 7. 解锁浏览器背后的运行机制
- 8. 对浏览器端javaScript运行机制的理解
- 9. 浏览器详解
- 10. 浏览器运行原理
- 更多相关文章...
- • XSLT 浏览器 - XSLT 教程
- • Opera 浏览器 - 浏览器信息
- • 漫谈MySQL的锁机制
- • Docker容器实战(六) - 容器的隔离与限制
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 浏览器运行机制
- 2. 浏览器与JS运行机制
- 3. 浏览器底层运行机制
- 4. JS运行机制、浏览器缓存
- 5. 浏览器缓存机制详解
- 6. 浏览器的渲染机制以及JS运行机制
- 7. 解锁浏览器背后的运行机制
- 8. 对浏览器端javaScript运行机制的理解
- 9. 浏览器详解
- 10. 浏览器运行原理