线程和进程

深入浏览器之浏览器中的进程与线程

进程和线程的概念可以这样理解：

进程是一个工厂，工厂有它的独立资源--工厂之间相互独立--线程是工厂中的工人，多个工人协作完成任务--工厂内有一个或多个工人--工人之间共享空间

工厂有多个工人，就相当于一个进程可以有多个线程，而且线程共享进程的空间。

进程是cpu资源分配的最小单位（是能拥有资源和独立运行的最小单位，系统会给它分配内存）线程是cpu调试的最小单位（线程是建立在进程的基础上的一次程序运行单位，一个进程中可以有多个线程。核心还是属于一个进程。）

浏览器是多进程的

浏览器是多进程的，每打开一个tab页，就相当于创建了一个独立的浏览器进程。

浏览器包含的进程：

Browser进程：浏览器的主进程（负责协调，主控），只有一个，作用有：
- 负责浏览器的界面显示，与用户交互，如前进，后退等
- 负责各个页面的管理，创建和销毁其它进程
- 将Rendered进程得到的内存中的Bitmap,绘制到用户界面上
- 网络资源的管理，下载
第三方插件进程：每种类型的插件对应一个进程，仅当使用该插件时才创建。
GPU进程：最多一个，用于3D绘制等。
浏览器渲染进程（浏览器内核）（Render进程，内部是多线程的）：默认每个Tab页面一个进程，互不影响。主要作用为：
- 页面渲染，脚本执行，事件处理等

在浏览器中打开一个网页相当于新起了一个进程（进程内有自己的多线程）

浏览器多进程的优势

避免单个page crash影响整个浏览器
避免第三方插件crash影响整个浏览器
多进程充分利用多核优势
方便使用沙盒模型隔离插件等进程，提高浏览器稳定性

简单理解就是：如果浏览器是单进程的，某个Tab页崩溃了，就影响了整个浏览器，体验就会很差。同理如果是单进程的，插件崩溃了也会影响整个浏览器; 当然，内存等资源消耗也会更大，像空间换时间一样。

重点是浏览器内核（渲染进程）

对于普通的前端操作来说，最重要的渲染进程：页面的渲染，js的执行，事件的循环等都在这个进程内执行;

浏览器是多进程的，浏览器的渲染进程是多线程的；

GUI渲染线程

负责渲染浏览器界面，解析HTML,CSS,构建DOM树和RenderObject树，布局和绘制等。
当界面需要重绘或由于某种操作引发回流时，该线程就会执行。
注意，GUI渲染线程与JS引擎线程是互斥的，当JS引擎执行时GUI线程会被挂起（相当于冻结了）,GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。

JS引擎线程

也称为JS内核，负责处理JavaScript脚本程序。（例如V8引擎）。
JS引擎线程负责解析JavaScript脚本，运行代码。
JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（render进程）中无论什么时候都只有一个JS线程在运行JS程序。
同样注意，GUI渲染线程与JS引擎线程是互斥的，所以如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞。

事件触发线程

归属于浏览器而不是JS引擎，用来控制事件循环（可以理解成JS引擎自己都忙不过来，需要浏览器另开线程协助）。
当JS引擎执行代码块如setTimeout时（也可来自浏览器内核的其它线程，如鼠标点击，AJAX异步请求等），会将对应任务添加到事件线程中。
当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理。
注意，由于JS的单线程关系，所以这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）。

定时触发器线程

传说中的setTimeout和setInterval所在的线程
浏览器定时计数器并不是由JavaScript引擎计数的，（因为JavaScript引擎是单线程的，如果处于阻塞线程状态就会影响计时的准确）
因此通过单独线程来计时并触发定时（计时完毕后，添加到事件队列中，等待JS引擎空闲后执行）
注意，W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms。

异步http请求线程

在XMLHttpRequest在连接后是通过浏览器新型一个线程请求
将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中，再由JavaScript引擎执行

GUI渲染线程与JS引擎线程互斥

由于JavaScript是可操作DOM的，如果在修改这些元素属性同时渲染界面（即JS线程和GUI线程同时运行），那么渲染线程前后获得的元素数据就可能不一致了。

因此，为了防止渲染出现不可预期的结果，浏览器就设置了互斥的关系，当JS引擎执行时GUI线程会被挂起。GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。

JS阻塞页面加载

从上述的互斥关系，可以推导出，JS如果执行时间过长就会阻塞页面。

譬如，假设JS引擎正在进行巨量的计算，此时就算GUI有更新，也会被保存在队列中，要等到JS引擎空闲后执行。然后由于巨量计算，所以JS引擎可能很久很久才能空闲，肯定就会感觉很卡。

所以，要尽量避免JS执行时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞的感觉。

css加载是否会阻塞dom树渲染

这里说的是头部引入css的情况首先，我们都知道：css是由单独的下载线程异步下载的。然后还有几个现象：

css加载不会阻塞DOM树解析（异步加载时dom照常构建）
但会阻塞render树渲染（渲染时需要等css加载完毕，因为render树需要css信息）

这可能也是浏览器的一种优化机制因为你加载css的时候，可能会修改下面DOM节点的样式，如果css加载不阻塞render树渲染的话，那么当css加载完之后，render树可能又得重新重绘或者回流了，这就造成了一些没有必要的损耗所以干脆把DOM树的结构先解析完，把可以做的工作做完，然后等css加载完之后，在根据最终的样式来渲染render树，这种做法确实对性能好一点。

WebWorker,JS的多线程？

前文中有提到JS引擎是单线程的，而且JS执行时间过长会阻塞页面，那么JS就真的对cpu密集型计算无能为力么？

所以，后来HTML5中支持了WebWorker。

这样理解下：

创建Worker时，JS引擎向浏览器申请开一个子线程（子线程是浏览器开的，完全受主线程控制，而且不能操作DOM） JS引擎线程与worker线程间通过特定的方式通信（postMessage API，需要通过序列化对象来与线程交互特定的数据）

所以，如果有非常耗时的工作，请单独开一个Worker线程，这样里面不管如何翻天覆地都不会影响JS引擎主线程，只待计算出结果后，将结果通信给主线程即可，perfect!

而且注意下，JS引擎是单线程的，这一点的本质仍然未改变，Worker可以理解是浏览器给JS引擎开的外挂，专门用来解决那些大量计算问题。

WebWorker与SharedWorker

既然都到了这里，就再提一下SharedWorker（避免后续将这两个概念搞混）

WebWorker只属于某个页面，不会和其他页面的Render进程（浏览器内核进程）共享所以Chrome在Render进程中（每一个Tab页就是一个render进程）创建一个新的线程来运行Worker中的JavaScript程序。

SharedWorker是浏览器所有页面共享的，不能采用与Worker同样的方式实现，因为它不隶属于某个Render进程，可以为多个Render进程共享使用所以Chrome浏览器为SharedWorker单独创建一个进程来运行JavaScript程序，在浏览器中每个相同的JavaScript只存在一个SharedWorker进程，不管它被创建多少次。

看到这里，应该就很容易明白了，本质上就是进程和线程的区别。SharedWorker由独立的进程管理，WebWorker只是属于render进程下的一个线程

Browser主进程和浏览器内核（渲染进程）的通信过程

打开一个浏览器，可以看到：任务管理器出现了2个进程（一个主进程，一个是打开Tab页的渲染进程）；

Browser主进程收到用户请求，首先需要获取页面内容（如通过网络下载资源）,随后将该任务通过RendererHost接口传递给Render渲染进程
Render渲染进程的Renderer接口收到消息，简单解释后，交给渲染线程GUI，然后开始渲染
GUI渲染线程接收请求，加载网页并渲染网页，这其中可能需要Browser主进程获取资源和需要GPU进程来帮助渲染
当然可能会有JS线程操作DOM（这可能会造成回流并重绘）
最后Render渲染进程将结果传递给Browser主进程
Browser主进程接收到结果并将结果绘制出来

V8：强大的JavaScript引擎

机器码
机器码(machine code)，机器语言指令，一种CPU的可读指令，是CPU可直接解读的0 1二进制序列。不同的CPU生产厂商，遵守的机器指令标准主体上是通用的，但也会有自己的一些比较特殊的指令。

字节码
字节码(Bytecode)，是一种包含执行程序、由一序列 op（操作码）代码/数据对组成的二进制文件，字节码是一种中间码，它比机器码更抽象，需要直译器转译后才能成为机器码的中间代码，是一种要解释的虚拟机的指令，并且仍然需要在执行之前转换为机器代码。

汇编语言
汇编代码是一种宏语言，是机器的本机语言（机器码）的人类可读形式。它经过转译最终也会成为机器码，所以抽象上来说，它和字节码是同一级别的。汇编语言可以简单理解为机器语言的助记符，便于人们理解和记忆。

编程语言的发展大概经历了以下几个阶段：汇编语言 => 面向过程编程 => 面向对象编程

编程语言的从执行原理上分为两类：解释型语言和编译型语言

计算机不能直接理解机器语言以外的语言，因此需要将我们写的代码编译成机器语言，然后再交给计算机去执行。

编译型语言

程序在执行之前需要一个专门的编译过程，把程序编译为机器语言的文件，运行时不需要重新翻译，直接使用编译的结果就行了。程序执行效率高，依赖编译器，跨平台性差些。如C、C++、Delphi等。

解释型语言

程序不需要编译，程序在运行时才翻译成机器语言，每执行一次都要翻译一次。因此效率比较低。如 Python、Shell、JavaScript 等。

我们写的JavaScript代码直接交给浏览器或者Node执行时，底层的CPU是不认识的，也没法执行。CPU只认识自己的指令集，指令集对应的是汇编代码。

JavaScirpt引擎可以将JS代码编译为不同CPU(Intel, ARM以及MIPS等)对应的汇编代码，这样我们才不要去翻阅每个CPU的指令集手册。当然，JavaScript引擎的工作也不只是编译代码，它还要负责执行代码、分配内存以及垃圾回收。

V8 是一个由 Google 开发的开源 JavaScript 引擎，目前用在 Chrome 浏览器和 Node.js 中，其核心功能是执行易于人类理解的 JavaScript 代码。

V8由许多子模块构成，其中这4个模块是最重要的：

Parser：负责将JavaScript源码转换为Abstract Syntax Tree (AST)
Ignition：interpreter，即解释器，负责将AST转换为Bytecode，解释执行Bytecode；同时收集TurboFan优化编译所需的信息，比如函数参数的类型；
TurboFan：compiler，即编译器，利用Ignitio所收集的类型信息，将Bytecode转换为优化的汇编代码；
Orinoco：garbage collector，垃圾回收模块，负责将程序不再需要的内存空间回收；

其中，Parser，Ignition以及TurboFan可以将JS源码编译为汇编代码，其流程图如下：

简单地说，Parser将JS源码转换为AST，然后Ignition将AST转换为Bytecode，最后TurboFan将Bytecode转换为经过优化的Machine Code(实际上是汇编代码)。

如果函数没有被调用，则V8不会去编译它。
如果函数只被调用1次，则Ignition将其编译Bytecode就直接解释执行了。TurboFan不会进行优化编译，因为它需要Ignition收集函数执行时的类型信息。这就要求函数至少需要执行1次，TurboFan才有可能进行优化编译。
如果函数被调用多次，则它有可能会被识别为热点函数，且Ignition收集的类型信息证明可以进行优化编译的话，这时TurboFan则会将Bytecode编译为Optimized Machine Code，以提高代码的执行性能。

图片中的红线是逆向的，这的确有点奇怪，Optimized Machine Code会被还原为Bytecode，这个过程叫做Deoptimization。这是因为Ignition收集的信息可能是错误的，比如add函数的参数之前是整数，后来又变成了字符串。生成的Optimized Machine Code已经假定add函数的参数是整数，那当然是错误的，于是需要进行Deoptimization。

在运行C、C++以及Java等程序之前，需要进行编译，不能直接执行源码；但对于JavaScript来说，我们可以直接执行源码(比如：node server.js)，它是在运行的时候先编译再执行，这种方式被称为即时编译(Just-in-time compilation)，简称为JIT。因此，V8也属于JIT编译器。

JIT

JIT，全称是 Just In Time，混合使用编译器和解释器的技术。而编译器启动速度慢，执行速度快。而解释器的启动速度快，执行速度慢。而JIT技术就是博两者之长。如图示：

垃圾回收

「硬核JS」你的程序中可能存在内存泄漏

一文带你了解如何排查内存泄漏导致的页面卡顿现象

对于在JavaScript中的字符串，对象，数组是没有固定大小的，只有当对他们进行动态分配存储时，解释器就会分配内存来存储这些数据，当JavaScript的解释器消耗完系统中所有可用的内存时，就会造成系统崩溃。
内存泄漏，在某些情况下，不再使用到的变量所占用内存没有及时释放，导致程序运行中，内存越占越大，极端情况下可以导致系统崩溃，服务器宕机。
JavaScript有自己的一套垃圾回收机制，JavaScript的解释器可以检测到什么时候程序不再使用这个对象了（数据），就会把它所占用的内存释放掉。
针对JavaScript的来及回收机制有以下两种方法（常用）：标记清除，引用计数
标记清除

v8 的垃圾回收机制基于分代回收机制，这个机制又基于世代假说，这个假说有两个特点，一是新生的对象容易早死，另一个是不死的对象会活得更久。基于这个假说，v8 引擎将内存分为了新生代和老生代。

新创建的对象或者只经历过一次的垃圾回收的对象被称为新生代。经历过多次垃圾回收的对象被称为老生代。
新生代被分为 From 和 To 两个空间，To 一般是闲置的。当 From 空间满了的时候会执行 Scavenge 算法进行垃圾回收。当我们执行垃圾回收算法的时候应用逻辑将会停止，等垃圾回收结束后再继续执行。

这个算法分为三步：

首先检查 From 空间的存活对象，如果对象存活则判断对象是否满足晋升到老生代的条件，如果满足条件则晋升到老生代。如果不满足条件则移动 To 空间。
如果对象不存活，则释放对象的空间。
最后将 From 空间和 To 空间角色进行交换。

新生代对象晋升到老生代有两个条件：

第一个是判断是对象否已经经过一次 Scavenge 回收。若经历过，则将对象从 From 空间复制到老��代中；若没有经历，则复制到 To 空间。
第二个是 To 空间的内存使用占比是否超过限制。当对象从 From 空间复制到 To 空间时，若 To 空间使用超过 25%，则对象直接晋升到老生代中。设置 25% 的原因主要是因为算法结束后，两个空间结束后会交换位置，如果 To 空间的内存太小，会影响后续的内存分配。

老生代采用了标记清除法和标记压缩法。标记清除法首先会对内存中存活的对象进行标记，标记结束后清除掉那些没有标记的对象。由于标记清除后会造成很多的内存碎片，不便于后面的内存分配。所以了解决内存碎片的问题引入了标记压缩法。

由于在进行垃圾回收的时候会暂停应用的逻辑，对于新生代方法由于内存小，每次停顿的时间不会太长，但对于老生代来说每次垃圾回收的时间长，停顿会造成很大的影响。为了解决这个问题 V8 引入了增量标记的方法，将一次停顿进行的过程分为了多步，每次执行完一小步就让运行逻辑执行一会，就这样交替运行

从`Event Loop`谈`JS`的运行机制

我们已经知道了JS引擎是单线程的，知道了JS引擎线程，事件触发线程，定时触发器线程。然后还需要知道：

JS分为同步任务和异步任务
同步任务都在主线程上执行，形成一个执行栈
主线程之外，事件触发线程管理着一个任务队列，只要异步任务有了运行结果，就在任务队列之中放置一个事件
一旦执行栈中的所有同步任务执行完毕（此时JS引擎空闲），系统就会读取任务队列，将可运行的异步任务添加到可执行栈，开始执行。

看到这里，应该就可以理解了：为什么有时候setTimeOut推入的事件不能准时执行？因为可能在它推入到事件列表时，主线程还不空闲，正在执行其它代码，所以就必须等待，自然有误差。

主线程在运行时会产生执行栈，栈中的代码调用某些api时，它们会在事件队列中添加各种事件（当满足触发条件后，如ajax请求完毕）。而当栈中的代码执行完毕，就会去读取事件队列中的事件，去执行那些回调，如此循环。

定时器

上面事件循环机制的核心是：JS引擎线程和事件触发线程

调用setTimeout后，是由定时器线程控制等到特定时间后添加到事件队列的，因为JS引擎是单线程的，如果处于阻塞线程状态就会影响计时准确，因此很有必要另开一个线程用来计时。

当使用setTimout或setInterval时，需要定时器线程计时，计时完成后就会将特定的事件推入事件队列中。

如：

setTimeout(()=>console.log('hello!),1000)
//等1000毫秒计时完毕后（由定时器线程计时），将回调函数推入事件队列中，等待主线程执行

setTimeout(()=>{
    console.log('hello')
},0)
console.log('begin')

这段代码的效果是最快的时间内将回调函数推入事件队列中，等待主线程执行。

注意：

执行结果是：先begin，后hello
虽然代码的本意是0毫秒就推入事件队列，但是W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms
就算不等待4ms，就算假设0毫秒就推入事件队列，也会先执行begin（因为只能可执行栈内空了后才会主动读取事件队列）

setInterval

用setTimeout模拟定期计时和直接用setInterval是有区别的：

每次setTimeout计时到后就会去执行，然后执行一段时间后才会继续setTimeout,中间就多了误差
而setInterval则是每次都精确的隔一段时间推入一个事件（但是，事件的实际执行时间不一定就准确，还有可能是这个事件还没执行完毕，下一个事件就来了）

而且setInterval有一些比较致命的问题：

累积效应，如果setInterval代码在setInterval再次添加到队列之前还没有完成执行，就会导致定时器代码连续运行好几次，而之间没有间隔，就算正常间隔执行，多个setInterval的代码执行时间可能会比预期小（因为代码执行需要一定时间）
比如你ios的webview，或者safari等浏览器中都有一人特点，在滚动的时候是不执行JS的，如果使用了setInterval，会发现在滚动结束后会执行多次由于滚动不执行JS积攒回调，如果回调执行时间过长，就会非常容易造成卡顿问题和一些不可知的错误（setInterval自带的优化，如果当前事件队列中有setInterval的回调，不会重复添加回调）
而且把浏览器最小化显示等操作时，setInterval并不是不执行程序，它会把setInterval的回调函数放在队列中，等浏览器窗口再次打开时，一瞬间全部执行

所以，至于这么问题，一般认为的最佳方案是：用setTimeout模拟setInterval或者特殊场合直接用requestAnimationFrame

`Promise`时代的`microtask`与`macrotask`

在es6盛行的现在，可以看下这题：

console.log('script start');

setTimeout(()=>{
    console.log('setTimeout')
},0);

Promise.resolve()
.then(()=>console.log('promise1'))
.then(()=>console.log('promise2'))

console.log('script end')

//执行结果：
script start
script end
promise1
promise2
setTimeout

因为promise有一个新的概念microtask.或者可以说JS中分为两种任务：macrotask和microtask; 理解如下：

macrotask(又叫宏任务),主代码块，setTimeout,setInterval等（可以看到，事件队列中的每一个事件都是一个macrotask）
可以理解是每次执行的代码就是一个宏任务（包括每次从事件队列中获取一个事件回调并放到执行栈中执行）
第一个macrotask会从头到尾将这个任务执行完毕，不会执行其它
浏览器为了能够使得JS内部macrotask与DOM任务能够有序的执行，会在一个macrotask执行结束后，在下一个macrotask执行开始前，对页面进行重新渲染（task->渲染->task->...）
microtask（又叫微任务），Promise,process.nextTick等。
可以理解是在当前macrotask执行结束后立即执行的任务
也就是说在当前macrotask任务后，下一个macrotask之前，在渲染之前
所以它的响应速度相比setTimeout(setTimeout是macrotask)会更快因为无需等待渲染
也就是说，在某一个macrotask执行完成后，就会将在它执行期间产生的所有microtask都执行完毕（在渲染前）

注意：在Node环境下，process.nextTick的优先级高于promise.也就是：在宏任务结束后会先执行微任务队列中的nextTick部分，然后才会执行微任务中的promise部分。

另外，setImmediate则是规定：在下一次Event Loop（宏任务）时触发（所以它是属于优先级较高的宏任务），（Node.js文档中称，setImmediate指定的回调函数，总是排在setTimeout前面），所以setImmediate如果嵌套的话，是需要经过多个Loop才能完成的，而不会像process.nextTick一样没完没了。

可以理解：

macrotask中的事件都是放在一个事件队列中的，而这个队列由事件触发线程维护.
microtask中的所有微任务都是添加到微任务队列中，等待当前macrotask执行完后执行，而这个队列由JS引擎线程维护。

所以：

执行一个宏任务（栈中没有就从事件队列中获取）
执行过程中如果遇到微任务，就将它添加到微任务的任务队列中
宏任务执行完毕后，立即执行当前微任务队列中的所有微任务（依次执行）
当前宏任务执行完毕，开始检查渲染，然后GUI线程接管渲染
渲染完毕后，JS线程继续接管，开始下一个宏任务（从事件队列中获取）

一次 Event loop 顺序是这样的

执行同步代码，这属于宏任务
执行栈为空，查询是否有微任务需要执行
执行所有微任务
必要的话渲染 UI
然后开始下一轮 Event loop，执行宏任务中的异步代码

new Promise里的函数是直接执行的算做主程序里，而且.then后面的才会放到微任务中。

另外，请注意下Promise的polyfill与官方版本的区别：

官方版本中，是标准的microtask形式 polyfill，一般都是通过setTimeout模拟的，所以是macrotask形式请特别注意这两点区别

注意，有一些浏览器执行结果不一样（因为它们可能把microtask当成macrotask来执行了），但是为了简单，这里不描述一些不标准的浏览器下的场景（但记住，有些浏览器可能并不标准）

Mutation Observer可以用来实现microtask（它属于microtask，优先级小于Promise，一般是Promise不支持时才会这样做）

它是HTML5中的新特性，作用是：监听一个DOM变动，当DOM对象树发生任何变动时，Mutation Observer会得到通知

像以前的Vue源码中就是利用它来模拟nextTick的，具体原理是，创建一个TextNode并监听内容变化，然后要nextTick的时候去改一下这个节点的文本内容，如下：（Vue的源码，未修改）

var counter=1
var observer=newMutationObserver(nextTickHandler)
var textNode=document.createTextNode(String(counter))
observer.observe(textNode,{characterData:true})
timerFunc=()=>{
    counter=(counter+1)%2
    textNode.data=String(counter)
}

不过，现在的Vue（2.5+）的nextTick实现移除了Mutation Observer的方式（据说是兼容性原因），取而代之的是使用MessageChannel（当然，默认情况仍然是Promise，不支持才兼容的）。

MessageChannel属于宏任务，优先级是：setImmediate->MessageChannel->setTimeout，所以Vue（2.5+）内部的nextTick与2.4及之前的实现是不一样的，需要注意下。

导航流程：从输入URL到页面展示这中间发生了什么

“在浏览器里，从输入URL到页面展示，这中间发生了什么？ ”这是一道经典的面试题，能比较全面地考察应聘者知识的掌握程度，其中涉及到了网络、操作系统、Web等一系列的知识。所以我在面试应聘者时也必问这道题，但遗憾的是大多数人只能回答其中部分零散的知识点，并不能将这些知识点串联成线，无法系统而又全面地回答这个问题。

那么今天我们就一起来探索下这个流程，下图是我梳理出的“从输入URL到页面展示完整流程示意图”：

从图中可以看出，整个过程需要各个进程之间的配合，所以在开始正式流程之前，我们还是先来快速回顾下浏览器进程、渲染进程和网络进程的主要职责。

浏览器进程主要负责用户交互、子进程管理和文件储存等功能。
网络进程是面向渲染进程和浏览器进程等提供网络下载功能。
渲染进程的主要职责是把从网络下载的HTML、JavaScript、CSS、图片等资源解析为可以显示和交互的页面。因为渲染进程所有的内容都是通过网络获取的，会存在一些恶意代码利用浏览器漏洞对系统进行攻击，所以运行在渲染进程里面的代码是不被信任的。这也是为什么Chrome会让渲染进程运行在安全沙箱里，就是为了保证系统的安全

回顾了浏览器的进程架构后，我们再结合上图来看下这个完整的流程，可以看出，整个流程包含了许多步骤，我把其中几个核心的节点用蓝色背景标记出来了。这个过程可以大致描述为如下：

首先，用户从浏览器进程里输入请求信息；
然后，网络进程发起URL请求；
服务器响应URL请求之后，浏览器进程就又要开始准备渲染进程了；
渲染进程准备好之后，需要先向渲染进程提交页面数据，我们称之为提交文档阶段；
渲染进程接收完文档信息之后，便开始解析页面和加载子资源，完成页面的渲染。

这其中，用户发出URL请求到页面开始解析的这个过程，就叫做导航。下面我们来详细分析下这些步骤，同时也就解答了开头所说的那道经典的面试题。

从输入URL到页面展示

知道了浏览器的几个主要进程的职责之后，那么接下来，我们就从浏览器的地址栏开始讲起。

用户输入

当用户在地址栏中输入一个查询关键字时，地址栏会判断输入的关键字是搜索内容，还是请求的URL。

如果是搜索内容，地址栏会使用浏览器默认的搜索引擎，来合成新的带搜索关键字的URL。
如果判断输入内容符合URL规则，比如输入的是 time.geekbang.org，那么地址栏会根据规则，把这段内容加上协议，合成为完整的URL，如 time.geekbang.org。

当用户输入关键字并键入回车之后，浏览器便进入下图的状态：

从图中可以看出，当浏览器刚开始加载一个地址之后，标签页上的图标便进入了加载状态。但此时图中页面显示的依然是之前打开的页面内容，并没立即替换为极客时间的页面。因为需要等待提交文档阶段，页面内容才会被替换。

URL请求过程

接下来，便进入了页面资源请求过程。这时，浏览器进程会通过进程间通信（IPC）把URL请求发送至网络进程，网络进程接收到URL请求后，会在这里发起真正的URL请求流程。那具体流程是怎样的呢？

首先，网络进程会查找本地缓存是否缓存了该资源。如果有缓存资源，那么直接返回资源给浏览器进程；如果在缓存中没有查找到资源，那么直接进入网络请求流程。这请求前的第一步是要进行DNS解析，以获取请求域名的服务器IP地址。如果请求协议是HTTPS，那么还需要建立TLS连接。

接下来就是利用IP地址和服务器建立TCP连接。连接建立之后，浏览器端会构建请求行、请求头等信息，并把和该域名相关的Cookie等数据附加到请求头中，然后向服务器发送构建的请求信息。

服务器接收到请求信息后，会根据请求信息生成响应数据（包括响应行、响应头和响应体等信息），并发给网络进程。等网络进程接收了响应行和响应头之后，就开始解析响应头的内容了。（为了方便讲述，下面我将服务器返回的响应头和响应行统称为响应头。）

（1）重定向

在接收到服务器返回的响应头后，网络进程开始解析响应头，如果发现返回的状态码是301或者302，那么说明服务器需要浏览器重定向到其他URL。这时网络进程会从响应头的Location字段里面读取重定向的地址，然后再发起新的HTTP或者HTTPS请求，一切又重头开始了。

比如，我们在终端里输入以下命令：

curl -I http://time.geekbang.org/

curl -I + URL的命令是接收服务器返回的响应头的信息。执行命令后，我们看到服务器返回的响应头信息如下：

从图中可以看出，极客时间服务器会通过重定向的方式把所有HTTP请求转换为HTTPS请求。也就是说你使用HTTP向极客时间服务器请求时，服务器会返回一个包含有301或者302状态码响应头，并把响应头的Location字段中填上HTTPS的地址，这就是告诉了浏览器要重新导航到新的地址上。

下面我们再使用HTTPS协议对极客时间发起请求，看看服务器的响应头信息是什么样子的。

curl -I https://time.geekbang.org/

我们看到服务器返回如下信息：

从图中可以看出，服务器返回的响应头的状态码是200，这是告诉浏览器一切正常，可以继续往下处理该请求了。

好了，以上是重定向内容的介绍。现在你应该理解了，在导航过程中，如果服务器响应行的状态码包含了301、302一类的跳转信息，浏览器会跳转到新的地址继续导航；如果响应行是200，那么表示浏览器可以继续处理该请求。

（2）响应数据类型处理

在处理了跳转信息之后，我们继续导航流程的分析。URL请求的数据类型，有时候是一个下载类型，有时候是正常的HTML页面，那么浏览器是如何区分它们呢？

答案是Content-Type。Content-Type是HTTP头中一个非常重要的字段，它告诉浏览器服务器返回的响应体数据是什么类型，然后浏览器会根据Content-Type的值来决定如何显示响应体的内容。

这里我们还是以极客时间为例，看看极客时间官网返回的Content-Type值是什么。在终端输入以下命令：

curl -I https://time.geekbang.org/

返回信息如下图：

从图中可以看到，响应头中的Content-type字段的值是text/html，这就是告诉浏览器，服务器返回的数据是HTML格式。

接下来我们再来利用curl来请求极客时间安装包的地址，如下所示：

curl -I https://res001.geekbang.org/apps/geektime/android/2.3.1/official/geektime_2.3.1_20190527-2136_offical.apk

请求后返回的响应头信息如下：

从返回的响应头信息来看，其Content-Type的值是application/octet-stream，显示数据是字节流类型的，通常情况下，浏览器会按照下载类型来处理该请求。

需要注意的是，如果服务器配置Content-Type不正确，比如将text/html类型配置成application/octet-stream类型，那么浏览器可能会曲解文件内容，比如会将一个本来是用来展示的页面，变成了一个下载文件。

所以，不同Content-Type的后续处理流程也截然不同。如果Content-Type字段的值被浏览器判断为下载类型，那么该请求会被提交给浏览器的下载管理器，同时该URL请求的导航流程就此结束。但如果是HTML，那么浏览器则会继续进行导航流程。由于Chrome的页面渲染是运行在渲染进程中的，所以接下来就需要准备渲染进程了。

准备渲染进程

默认情况下，Chrome会为每个页面分配一个渲染进程，也就是说，每打开一个新页面就会配套创建一个新的渲染进程。但是，也有一些例外，在某些情况下，浏览器会让多个页面直接运行在同一个渲染进程中。

比如我从极客时间的首页里面打开了另外一个页面——算法训练营，我们看下图的Chrome的任务管理器截图：

从图中可以看出，打开的这三个页面都是运行在同一个渲染进程中，进程ID是23601。

那什么情况下多个页面会同时运行在一个渲染进程中呢？

要解决这个问题，我们就需要先了解下什么是同一站点（same-site）。具体地讲，我们将“同一站点”定义为根域名（例如，geekbang.org）加上协议（例如，https:// 或者http://），还包含了该根域名下的所有子域名和不同的端口，比如下面这三个：

https://time.geekbang.org
https://www.geekbang.org
https://www.geekbang.org:8080

它们都是属于同一站点，因为它们的协议都是HTTPS，而且根域名也都是geekbang.org。

Chrome的默认策略是，每个标签对应一个渲染进程。但如果从一个页面打开了另一个新页面，而新页面和当前页面属于同一站点的话，那么新页面会复用父页面的渲染进程。官方把这个默认策略叫process-per-site-instance。

那若新页面和当前页面不属于同一站点，情况又会发生什么样的变化呢？比如我通过极客邦页面里的链接打开InfoQ的官网（www.infoq.cn/ ），因为infoq.cn和geekbang.org不属于同一站点，所以infoq.cn会使用一个新的渲染进程，你可以参考下图

从图中任务管理器可以看出：由于极客邦和极客时间的标签页拥有相同的协议和根域名，所以它们属于同一站点，并运行在同一个渲染进程中；而infoq.cn的根域名不同于geekbang.org，也就是说InfoQ和极客邦不属于同一站点，因此它们会运行在两个不同的渲染进程之中。

总结来说，打开一个新页面采用的渲染进程策略就是：

通常情况下，打开新的页面都会使用单独的渲染进程；
如果从A页面打开B页面，且A和B都属于同一站点的话，那么B页面复用A页面的渲染进程；如果是其他情况，浏览器进程则会为B创建一个新的渲染进程。

渲染进程准备好之后，还不能立即进入文档解析状态，因为此时的文档数据还在网络进程中，并没有提交给渲染进程，所以下一步就进入了提交文档阶段。

提交文档

首先要明确一点，这里的“文档”是指URL请求的响应体数据。

“提交文档”的消息是由浏览器进程发出的，渲染进程接收到“提交文档”的消息后，会和网络进程建立传输数据的“管道”。
等文档数据传输完成之后，渲染进程会返回“确认提交”的消息给浏览器进程。
浏览器进程在收到“确认提交”的消息后，会更新浏览器界面状态，包括了安全状态、地址栏的URL、前进后退的历史状态，并更新Web页面。

更新内容如下图所示：

这也就解释了为什么在浏览器的地址栏里面输入了一个地址后，之前的页面没有立马消失，而是要加载一会儿才会更新页面。

到这里，一个完整的导航流程就“走”完了，这之后就要进入渲染阶段了。

渲染阶段

一旦文档被提交，渲染进程便开始页面解析和子资源加载了，关于这个阶段的完整过程，我会在下一篇文章中来专门介绍。这里你只需要先了解一旦页面生成完成，渲染进程会发送一个消息给浏览器进程，浏览器接收到消息后，会停止标签图标上的加载动画。如下所示：

至此，一个完整的页面就生成了。那文章开头的“从输入URL到页面展示，这中间发生了什么？”这个过程极其“串联”的问题也就解决了。

总结：从输入URL到页面展示，这中间发生了什么

用户输入url并回车
浏览器进程检查url，组装协议，构成完整的url
浏览器进程通过进程间通信（IPC）把url请求发送给网络进程
网络进程接收到url请求后检查本地缓存是否缓存了该请求资源，如果有则将该资源返回给浏览器进程
如果没有，网络进程向web服务器发起http请求（网络请求），请求流程如下：
- 进行DNS解析，获取服务器ip地址，端口（端口是通过dns解析获取的吗？这里有个疑问）
- 利用ip地址和服务器建立tcp连接
- 构建请求头信息
- 发送请求头信息
- 服务器响应后，网络进程接收响应头和响应信息，并解析响应内容
网络进程解析响应流程；
- 检查状态码，如果是301/302，则需要重定向，从Location自动中读取地址，重新进行第4步（301/302跳转也会读取本地缓存吗？这里有个疑问），如果是200，则继续处理请求。
- 200响应处理：检查响应类型Content-Type，如果是字节流类型，则将该请求提交给下载管理器，该导航流程结束，不再进行后续的渲染，如果是html则通知浏览器进程准备渲染进程准备进行渲染。
准备渲染进程
- 浏览器进程检查当前url是否和之前打开的渲染进程根域名是否相同，如果相同，则复用原来的进程，如果不同，则开启新的渲染进程
传输数据、更新状态
- 渲染进程准备好后，浏览器向渲染进程发起“提交文档”的消息，渲染进程接收到消息和网络进程建立传输数据的“管道”
- 渲染进程接收完数据后，向浏览器发送“确认提交”
- 浏览器进程接收到确认消息后更新浏览器界面状态：安全、地址栏url、前进后退的历史状态、更新web页面

浏览器渲染

按照渲染的时间顺序，流水线可分为如下几个子阶段：构建 DOM 树、样式计算、布局阶段、分层、栅格化和显示。如图：

为了能更好地理解下文，你可以先结合下图快速抓住HTML、CSS和JavaScript的含义：

从上图可以看出，HTML的内容是由标记和文本组成。标记也称为标签，每个标签都有它自己的语意，浏览器会根据标签的语意来正确展示HTML内容。比如上面的<p>标签是告诉浏览器在这里的内容需要创建一个新段落，中间的文本就是段落中需要显示的内容

如果需要改变HTML的字体颜色、大小等信息，就需要用到CSS。CSS又称为层叠样式表，是由选择器和属性组成，比如图中的p选择器，它会把HTML里面<p>标签的内容选择出来，然后再把选择器的属性值应用到<p>标签内容上。选择器里面有个color属性，它的值是red，这是告诉渲染引擎把<p>标签的内容显示为红色

至于JavaScript（简称为JS），使用它可以使网页的内容“动”起来，比如上图中，可以通过JavaScript来修改CSS样式值，从而达到修改文本颜色的目的。

搞清楚HTML、CSS和JavaScript的含义后，那么接下来我们就正式开始分析渲染模块了。

由于渲染机制过于复杂，所以渲染模块在执行过程中会被划分为很多子阶段，输入的HTML经过这些子阶段，最后输出像素。我们把这样的一个处理流程叫做渲染流水线，其大致流程如下图所示：

按照渲染的时间顺序，流水线可分为如下几个子阶段：构建DOM树、样式计算、布局阶段、分层、绘制、分块、光栅化和合成。内容比较多，我会用两篇文章来为你详细讲解这各个子阶段。接下来，在介绍每个阶段的过程中，你应该重点关注以下三点内容

开始每个子阶段都有其输入的内容；
然后每个子阶段有其处理过程；
最终每个子阶段会生成输出内容。

理解了这三部分内容，能让你更加清晰地理解每个子阶段。

构建DOM树

为什么要构建DOM树呢？这是因为浏览器无法直接理解和使用HTML，所以需要将HTML转换为浏览器能够理解的结构——DOM树。

这里我们还需要简单介绍下什么是树结构，为了更直观地理解，你可以参考下面我画的几个树结构：

从图中可以看出，树这种结构非常像我们现实生活中的“树”，其中每个点我们称为节点，相连的节点称为父子节点。树结构在浏览器中的应用还是比较多的，比如下面我们要介绍的渲染流程，就在频繁地使用树结构。

接下来咱们还是言归正传，来看看DOM树的构建过程，你可以参考下图

从图中可以看出，构建DOM树的输入内容是一个非常简单的HTML文件，然后经由HTML解析器解析，最终输出树状结构的DOM。

为了更加直观地理解DOM树，你可以打开Chrome的“开发者工具”，选择“Console”标签来打开控制台，然后在控制台里面输入“document”后回车，这样你就能看到一个完整的DOM树结构，如下图所示：

图中的document就是DOM结构，你可以看到，DOM和HTML内容几乎是一样的，但是和HTML不同的是，DOM是保存在内存中树状结构，可以通过JavaScript来查询或修改其内容。

那下面就来看看如何通过JavaScript来修改DOM的内容，在控制台中输入：

document.getElementsByTagName("p")[0].innerText = "black"

这行代码的作用是把第一个<p>标签的内容修改为black，具体执行结果你可以参考下图：

从图中可以看出，在执行了一段修改第一个<p>标签的JavaScript代码后，DOM的第一个p节点的内容成功被修改，同时页面中的内容也被修改了

好了，现在我们已经生成DOM树了，但是DOM节点的样式我们依然不知道，要让DOM节点拥有正确的样式，这就需要样式计算了

样式计算

样式计算的目的是为了计算出DOM节点中每个元素的具体样式，这个阶段大体可分为三步来完成

1. 把CSS转换为浏览器能够理解的结构

那CSS样式的来源主要有哪些呢？你可以先参考下图：

从图中可以看出，CSS样式来源主要有三种：

通过link引用的外部CSS文件
<style>标记内的 CSS
元素的style属性内嵌的CSS
和HTML文件一样，浏览器也是无法直接理解这些纯文本的CSS样式，所以当渲染引擎接收到CSS文本时，会执行一个转换操作，将CSS文本转换为浏览器可以理解的结构——styleSheets。
为了加深理解，你可以在Chrome控制台中查看其结构，只需要在控制台中输入document.styleSheets，然后就看到如下图所示的结构

从图中可以看出，这个样式表包含了很多种样式，已经把那三种来源的样式都包含进去了。当然样式表的具体结构不是我们今天讨论的重点，你只需要知道渲染引擎会把获取到的CSS文本全部转换为styleSheets结构中的数据，并且该结构同时具备了查询和修改功能，这会为后面的样式操作提供基础

2. 转换样式表中的属性值，使其标准化

现在我们已经把现有的CSS文本转化为浏览器可以理解的结构了，那么接下来就要对其进行属性值的标准化操作。

要理解什么是属性值标准化，你可以看下面这样一段CSS文本

body { font-size: 2em }
p {color:blue;}
span  {display: none}
div {font-weight: bold}
div  p {color:green;}
div {color:red; }

可以看到上面的CSS文本中有很多属性值，如2em、blue、bold，这些类型数值不容易被渲染引擎理解，所以需要将所有值转换为渲染引擎容易理解的、标准化的计算值，这个过程就是属性值标准化。

那标准化后的属性值是什么样子的？

从图中可以看到，2em被解析成了32px，red被解析成了rgb(255,0,0)，bold被解析成了700……

3. 计算出DOM树中每个节点的具体样式

现在样式的属性已被标准化了，接下来就需要计算DOM树中每个节点的样式属性了，如何计算呢？

这就涉及到CSS的继承规则和层叠规则了。

首先是CSS继承。CSS继承就是每个DOM节点都包含有父节点的样式。这么说可能有点抽象，我们可以结合具体例子，看下面这样一张样式表是如何应用到DOM节点上的

body { font-size: 20px }
p {color:blue;}
span  {display: none}
div {font-weight: bold;color:red}
div  p {color:green;}

这张样式表最终应用到DOM节点的效果如下图所示：

从图中可以看出，所有子节点都继承了父节点样式。比如body节点的font-size属性是20，那body节点下面的所有节点的font-size都等于20。

为了加深你对CSS继承的理解，你可以打开Chrome的“开发者工具”，选择第一个“element”标签，再选择“style”子标签，你会看到如下界面

这个界面展示的信息很丰富，大致可描述为如下

首先，可以选择要查看的元素的样式（位于图中的区域2中），在图中的第1个区域中点击对应的元素元素，就可以了下面的区域查看该元素的样式了。比如这里我们选择的元素是<p>标签，位于html.body.div.这个路径下面
其次，可以从样式来源（位于图中的区域3中）中查看样式的具体来源信息，看看是来源于样式文件，还是来源于UserAgent样式表。这里需要特别提下UserAgent样式，它是浏览器提供的一组默认样式，如果你不提供任何样式，默认使用的就是UserAgent样式。
最后，可以通过区域2和区域3来查看样式继承的具体过程。

以上就是CSS继承的一些特性，样式计算过程中，会根据DOM节点的继承关系来合理计算节点样式。

样式计算过程中的第二个规则是样式层叠。层叠是CSS的一个基本特征，它是一个定义了如何合并来自多个源的属性值的算法。它在CSS处于核心地位，CSS的全称“层叠样式表”正是强调了这一点。关于层叠的具体规则这里就不做过多介绍了，网上资料也非常多，你可以自行搜索学习

总之，样式计算阶段的目的是为了计算出DOM节点中每个元素的具体样式，在计算过程中需要遵守CSS的继承和层叠两个规则。这个阶段最终输出的内容是每个DOM节点的样式，并被保存在ComputedStyle的结构内。

如果你想了解每个DOM元素最终的计算样式，可以打开Chrome的“开发者工具”，选择第一个“element”标签，然后再选择“Computed”子标签，如下图所示：

上图红色方框中显示了html.body.div.p标签的ComputedStyle的值。你想要查看哪个元素，点击左边对应的标签就可以了

布局阶段

现在，我们有DOM树和DOM树中元素的样式，但这还不足以显示页面，因为我们还不知道DOM元素的几何位置信息。那么接下来就需要计算出DOM树中可见元素的几何位置，我们把这个计算过程叫做布局。

Chrome在布局阶段需要完成两个任务：创建布局树和布局计算

1. 创建布局树

你可能注意到了DOM树还含有很多不可见的元素，比如head标签，还有使用了display:none属性的元素。所以在显示之前，我们还要额外地构建一棵只包含可见元素布局树。

我们结合下图来看看布局树的构造过程：

从上图可以看出，DOM树中所有不可见的节点都没有包含到布局树中。

为了构建布局树，浏览器大体上完成了下面这些工作

遍历DOM树中的所有可见节点，并把这些节点加到布局中；
而不可见的节点会被布局树忽略掉，如head标签下面的全部内容，再比如body.p.span这个元素，因为它的属性包含 dispaly:none，所以这个元素也没有被包进布局树

2. 布局计算

现在我们有了一棵完整的布局树。那么接下来，就要计算布局树节点的坐标位置了。布局的计算过程非常复杂，我们这里先跳过不讲，等到后面章节中我再做详细的介绍。

在执行布局操作的时候，会把布局运算的结果重新写回布局树中，所以布局树既是输入内容也是输出内容，这是布局阶段一个不合理的地方，因为在布局阶段并没有清晰地将输入内容和输出内容区分开来。针对这个问题，Chrome团队正在重构布局代码，下一代布局系统叫LayoutNG，试图更清晰地分离输入和输出，从而让新设计的布局算法更加简单。

分层

现在我们有了布局树，而且每个元素的具体位置信息都计算出来了，那么接下来是不是就要开始着手绘制页面了？

答案依然是否定的。

因为页面中有很多复杂的效果，如一些复杂的3D变换、页面滚动，或者使用z-indexing做z轴排序等，为了更加方便地实现这些效果，渲染引擎还需要为特定的节点生成专用的图层，并生成一棵对应的图层树（LayerTree）。如果你熟悉PS，相信你会很容易理解图层的概念，正是这些图层叠加在一起构成了最终的页面图像。

要想直观地理解什么是图层，你可以打开Chrome的“开发者工具”，选择“Layers”标签，就可以可视化页面的分层情况，如下图所示

从上图可以看出，渲染引擎给页面分了很多图层，这些图层按照一定顺序叠加在一起，就形成了最终的页面，你可以参考下图

现在你知道了浏览器的页面实际上被分成了很多图层，这些图层叠加后合成了最终的页面。下面我们再来看看这些图层和布局树节点之间的关系，如文中图所示：

通常情况下，并不是布局树的每个节点都包含一个图层，如果一个节点没有对应的层，那么这个节点就从属于父节点的图层。如上图中的span标签没有专属图层，那么它们就从属于它们的父节点图层。但不管怎样，最终每一个节点都会直接或者间接地从属于一个层。

那么需要满足什么条件，渲染引擎才会为特定的节点创建新的层呢？通常满足下面两点中任意一点的元素就可以被提升为单独的一个图层。

第一点，拥有层叠上下文属性的元素会被提升为单独的一层。

页面是个二维平面，但是层叠上下文能够让HTML元素具有三维概念，这些HTML元素按照自身属性的优先级分布在垂直于这个二维平面的z轴上。你可以结合下图来直观感受下：

从图中可以看出，明确定位属性的元素、定义透明属性的元素、使用CSS滤镜的元素等，都拥有层叠上下文属性。

第二点，需要剪裁（clip）的地方也会被创建为图层。

不过首先你需要了解什么是剪裁，结合下面的HTML代码：

<style>
      div {
            width: 200;
            height: 200;
            overflow:auto;
            background: gray;
        } 
</style>
<body>
    <div >
        <p>所以元素有了层叠上下文的属性或者需要被剪裁，那么就会被提升成为单独一层，你可以参看下图：</p>
        <p>从上图我们可以看到，document层上有A和B层，而B层之上又有两个图层。这些图层组织在一起也是一颗树状结构。</p>
        <p>图层树是基于布局树来创建的，为了找出哪些元素需要在哪些层中，渲染引擎会遍历布局树来创建层树（Update LayerTree）。</p> 
    </div>
</body>

在这里我们把div的大小限定为200 * 200像素，而div里面的文字内容比较多，文字所显示的区域肯定会超出200 * 200的面积，这时候就产生了剪裁，渲染引擎会把裁剪文字内容的一部分用于显示在div区域，下图是运行时的执行结果

出现这种裁剪情况的时候，渲染引擎会为文字部分单独创建一个层，如果出现滚动条，滚动条也会被提升为单独的层。你可以参考下图：

所以说，元素有了层叠上下文的属性或者需要被剪裁，满足这任意一点，就会被提升成为单独一层。

图层绘制

在完成图层树的构建之后，渲染引擎会对图层树中的每个图层进行绘制，那么接下来我们看看渲染引擎是怎么实现图层绘制的？

试想一下，如果给你一张纸，让你先把纸的背景涂成蓝色，然后在中间位置画一个红色的圆，最后再在圆上画个绿色三角形。你会怎么操作呢？

通常，你会把你的绘制操作分解为三步：

制蓝色背景；
在中间绘制一个红色的圆；
再在圆上绘制绿色三角形

渲染引擎实现图层的绘制与之类似，会把一个图层的绘制拆分成很多小的绘制指令，然后再把这些指令按照顺序组成一个待绘制列表，如下图所示：

从图中可以看出，绘制列表中的指令其实非常简单，就是让其执行一个简单的绘制操作，比如绘制粉色矩形或者黑色的线等。而绘制一个元素通常需要好几条绘制指令，因为每个元素的背景、前景、边框都需要单独的指令去绘制。所以在图层绘制阶段，输出的内容就是这些待绘制列表。

你也可以打开“开发者工具”的“Layers”标签，选择“document”层，来实际体验下绘制列表，如下图所示：

在该图中，区域1就是document的绘制列表，拖动区域2中的进度条可以重现列表的绘制过程。

栅格化（raster）操作

绘制列表只是用来记录绘制顺序和绘制指令的列表，而实际上绘制操作是由渲染引擎中的合成线程来完成的。你可以结合下图来看下渲染主线程和合成线程之间的关系：

如上图所示，当图层的绘制列表准备好之后，主线程会把该绘制列表提交（commit）给合成线程，那么接下来合成线程是怎么工作的呢？

那我们得先来看看什么是视口，你可以参看下图：

通常一个页面可能很大，但是用户只能看到其中的一部分，我们把用户可以看到的这个部分叫做视口（viewport）。

在有些情况下，有的图层可以很大，比如有的页面你使用滚动条要滚动好久才能滚动到底部，但是通过视口，用户只能看到页面的很小一部分，所以在这种情况下，要绘制出所有图层内容的话，就会产生太大的开销，而且也没有必要。

基于这个原因，合成线程会将图层划分为图块（tile），这些图块的大小通常是256x256或者512x512，如下图所示：

然后合成线程会按照视口附近的图块来优先生成位图，实际生成位图的操作是由栅格化来执行的。所谓栅格化，是指将图块转换为位图。而图块是栅格化执行的最小单位。渲染进程维护了一个栅格化的线程池，所有的图块栅格化都是在线程池内执行的，运行方式如下图所示：

通常，栅格化过程都会使用GPU来加速生成，使用GPU生成位图的过程叫快速栅格化，或者GPU栅格化，生成的位图被保存在GPU内存中。

相信你还记得，GPU操作是运行在GPU进程中，如果栅格化操作使用了GPU，那么最终生成位图的操作是在GPU中完成的，这就涉及到了跨进程操作。具体形式你可以参考下图：

从图中可以看出，渲染进程把生成图块的指令发送给GPU，然后在GPU中执行生成图块的位图，并保存在GPU的内存中。

合成和显示

一旦所有图块都被光栅化，合成线程就会生成一个绘制图块的命令——“DrawQuad”，然后将该命令提交给浏览器进程。

浏览器进程里面有一个叫viz的组件，用来接收合成线程发过来的DrawQuad命令，然后根据DrawQuad命令，将其页面内容绘制到内存中，最后再将内存显示在屏幕上。

到这里，经过这一系列的阶段，编写好的HTML、CSS、JavaScript等文件，经过浏览器就会显示出漂亮的页面了。

渲染流水线大总结

好了，我们现在已经分析完了整个渲染流程，从HTML到DOM、样式计算、布局、图层、绘制、光栅化、合成和显示。下面我用一张图来总结下这整个渲染流程：

结合上图，一个完整的渲染流程大致可总结为如下

渲染进程将HTML内容转换为能够读懂的DOM树结构。
渲染引擎将CSS样式表转化为浏览器可以理解的styleSheets，计算出DOM节点的样式。
创建布局树，并计算元素的布局信息。
对布局树进行分层，并生成分层树。
为每个图层生成绘制列表，并将其提交到合成线程。
合成线程将图层分成图块，并在光栅化线程池中将图块转换成位图。
合成线程发送绘制图块命令DrawQuad给浏览器进程。
浏览器进程根据DrawQuad消息生成页面，并显示到显示器上

普通图层和复合图层

渲染步骤就提到了composite概念;浏览器渲染的图层一般包含两大类：普通图层以及复合图层。

普通文档流内可以理解为一个复合图层（这里默认复合层，里面不管添加多少元素，其实都是在同个复合图层中）
absolute布局（fixed也一样），虽然可以脱离文档流，但它仍然属于默认复合层
可以通过硬件加速的方式，声明一个新的复合图层，它会单独分配资源（当然也会脱离普通文档流，这样一来，不管这个复合图层中怎么变化，也不会影响默认复合层里的回流重绘）

可以简单理解下：GPU中，各个复合图层是单独绘制的，所以互不影响，这也是为什么某些场景硬件加速效果一级棒

如何变成复合图层（硬件加速）

将元素变成一个复合图层，就是传说中的硬件加速技术

最常用的方式：translate3d,translatez
opacity属性/过渡动画（需要动画执行的过程中才会创建合成层，动画没有开始或结束后元素还会回到之前的状态）
will-chang属性（这个比较偏僻），一般配合opacity与translate使用（而且经测试，除了上述可以引发硬件加速的属性外，其它属性并不会变成复合层），作用是提前告诉浏览器要变化，这样浏览器会开始做一些优化工作（这个最好用完后就释放）
<video><iframe><canvas><webgl>等元素
其它，譬如以前的flash插件

absolute和硬件加速的区别

可以看到，absolute虽然可以脱离普通文档流，但是无法脱离默认复合层。

所以，就算absolute中信息改变时不会改变普通文档流中render树，但是，浏览器最终绘制时，是整个复合层绘制的，所以absolute中信息的改变，仍然会影响整个复合层的绘制。（浏览器会重绘它，如果复合层中内容多，absolute带来的绘制信息变化过大，资源消耗是非常严重的）

而硬件加速直接就是在另一个复合层了（另起炉灶），所以它的信息改变不会影响默认复合层（当然了，内部肯定会影响属于自己的复合层），仅仅是引发最后的合成（输出视图）

复合图层的作用

一般一个元素开启硬件加速后会变成复合图层，可以独立于普通文档流中，改动后可以避免整个页面重绘，提升性能。但是尽量不要大量使用复合图层，否则由于资源消耗过度，页面反而会变的更卡。

硬件加速时请使用index

使用硬件加速时，尽可能的使用index,防止浏览器默认给后续的元素创建复合层渲染具体的原理是： webkit CSS3中，如果这个元素添加了硬件加速，并且index层级比较低，那么在这个元素的后面其它元素（层级比这个元素高的，或者相同的，并且relective或absolute属性相同的），会默认变为复合层渲染，如果处理不当会极大的影响性能

简单点理解，可以认为是一个隐式合成的概念：如果a是一个复合层，而且b在a上面，那么b也会被隐式转为一个复合图层，这点需要特别注意

浏览器学习总结

线程和进程

浏览器是多进程的

重点是浏览器内核（渲染进程）

V8：强大的JavaScript引擎

JIT

垃圾回收

从`Event Loop`谈`JS`的运行机制

定时器

`Promise`时代的`microtask`与`macrotask`

导航流程：从输入URL到页面展示这中间发生了什么

从输入URL到页面展示

用户输入

URL请求过程

准备渲染进程

提交文档

渲染阶段

总结：从输入URL到页面展示，这中间发生了什么

浏览器渲染

构建DOM树

样式计算

1. 把CSS转换为浏览器能够理解的结构

2. 转换样式表中的属性值，使其标准化

3. 计算出DOM树中每个节点的具体样式

布局阶段

1. 创建布局树

2. 布局计算

分层

图层绘制

栅格化（raster）操作

合成和显示

渲染流水线大总结

相关概念

1. 更新了元素的几何属性（重排）

2. 更新元素的绘制属性（重绘）

3. 直接合成阶段

总结浏览器渲染流程

普通图层和复合图层

浏览器学习总结

线程和进程

浏览器是多进程的

重点是浏览器内核（渲染进程）

V8：强大的JavaScript引擎

JIT

垃圾回收

从Event Loop谈JS的运行机制

定时器

Promise时代的microtask与macrotask

导航流程：从输入URL到页面展示这中间发生了什么

从输入URL到页面展示

用户输入

URL请求过程

准备渲染进程

提交文档

渲染阶段

总结：从输入URL到页面展示，这中间发生了什么

浏览器渲染

构建DOM树

样式计算

1. 把CSS转换为浏览器能够理解的结构

2. 转换样式表中的属性值，使其标准化

3. 计算出DOM树中每个节点的具体样式

布局阶段

1. 创建布局树

2. 布局计算

分层

图层绘制

栅格化（raster）操作

合成和显示

渲染流水线大总结

相关概念

1. 更新了元素的几何属性（重排）

2. 更新元素的绘制属性（重绘）

3. 直接合成阶段

总结浏览器渲染流程

普通图层和复合图层

从`Event Loop`谈`JS`的运行机制

`Promise`时代的`microtask`与`macrotask`