-
-当数据转换为字符串以后，浏览器会先将这些字符串通过词法分析转换为标记（ *token* ），这一过程在词法分析中叫做标记化（ *tokenization* ）。
-
-那么什么是标记呢？
-
-这其实属于编译原理这一块的内容了。简单来说，标记还是字符串，是构成代码的最小单位。这一过程会将代码分拆成一块块，并给这些内容打上标记，便于理解这些最小单位的代码是什么意思。
-
-
-
-当结束标记化后，这些标记会紧接着转换为 *DOM* 节点，之后所有的 *DOM* 节点会根据彼此之间的关系形成一颗 *DOM* 节点树。
-
-
-
-以上就是浏览器从网络中接收到 *HTML* 文件然后一系列的转换过程。
-
-
-
-## *CSSOM* 树的形成
-
-接下来是转换 *CSS* 到 *CSSOM* 树的过程。整体流程和上面类似：
-
-
-
-在这一过程中，浏览器会确定每一个节点的样式到底是什么，并最终生成一颗样式规则树，这棵树上面记录了每一个 *DOM* 节点的样式。
-
-
-
-将 *CSS* 从字节数据转换为 *CSSOM* 这一过程其实是很消耗资源的。因为样式你可以自行设置给某个节点，也可以通过继承获得。在这一过程中，浏览器需要递归 *CSSOM* 树，然后确定具体的元素到底是什么样式。
-
-举个例子：
-
-```html
-
-
-在这一过程中，不是简单的将两者合并就行了。渲染树只会包括需要显示的节点和这些节点的样式信息，如果某个节点是 *display: none* 的，那么就不会在渲染树中显示。
-
-当浏览器生成渲染树以后，就会根据渲染树来进行布局（也可以叫做回流），之后确定每一个像素点的信息（重绘），然后调用 *GPU* 绘制，合成图层，显示在屏幕上。对于这一部分的内容因为过于底层，还涉及到了硬件相关知识，这里就不再继续展开内容了。
-
-## 阻塞渲染
-
-首先渲染的前提是已经生成了渲染树（ *Render Tree* ）。而生成渲染树的前提是生成了 *DOM* 树和 *CSSOM* 样式规则树。
-
-所以如果想要渲染的速度加快，我们就应该降低要渲染的文件的大小，并且 *HTML* 节点的层级扁平化（没有无意义的标签），优化选择器。
-
-当浏览器在解析到 *script* 标签时，会暂停构建 *DOM*，原因很简单，因为 *JS* 能够修改 *DOM* 节点，所以浏览器会先执行 *JS* 代码，当 *JS* 代码执行完成后才会从暂停的地方重新开始。
-
-也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 *JS* 文件，这也是都建议将 *script* 标签放在 *body* 标签底部的原因。
-
-另外，在现代浏览器中，为我们提供了新的方式来避免 *JS* 代码阻塞渲染的情况：
-
-- *async*
-- *defer*
-- *prefetch*
-- *preload*
-
-关于这几种方式的区别，我们在另外一篇文章中再具体来看。
-
-## 重绘和回流
-
-重绘和回流会在我们设置节点样式时频繁出现，同时也会很大程度上影响性能。
-
-- 重绘：当节点需要更改外观而不会影响布局的，比如改变 *color* 就叫称为重绘
-- 回流：布局或者几何属性需要改变就称为回流。
-
-**回流必定会发生重绘，重绘不一定会引发回流。**因此回流所需的成本比重绘高得多，改变父节点里的子节点很可能会导致父节点的一系列回流。
-
-当页面布局和几何信息发生变化的时候，就需要回流。比如以下情况：
-
-- 添加或删除可见的 *DOM* 元素
-
-- 元素的位置发生变化
-
-- 元素的尺寸发生变化（包括外边距、内边框、边框大小、高度和宽度等）
-
-- 内容发生变化，比如文本变化或图片被另一个不同尺寸的图片所替代。
-
-- 页面一开始渲染的时候（这肯定避免不了）
-
-- 浏览器的窗口尺寸变化（因为回流是根据视口的大小来计算元素的位置和大小的）
-
-### 现代浏览器的优化机制
-
-现代的浏览器都是很聪明的，由于每次重排（回流）都会造成额外的计算消耗，因此大多数浏览器都会通过队列化修改并批量执行来优化重排过程。
-
-浏览器会将修改操作放入到队列里，直到过了一段时间或者操作达到了一个阈值，才清空队列。
-
-但是，当你获取布局信息的操作的时候，会强制队列刷新，比如当你访问以下属性或者使用以下方法：
-
-- *offsetTop、offsetLeft、offsetWidth、offsetHeight*
-
-- *scrollTop、scrollLeft、scrollWidth、scrollHeight*
-
-- *clientTop、clientLeft、clientWidth、clientHeight*
-
-- *getComputedStyle( )*
-
-- *getBoundingClientRect*
-
-更多会触发回流的属性和方法可以参阅：*https://gist.github.com/paulirish/5d52fb081b3570c81e3a*
-
-### 减少回流和重绘的方式
-
-接下来，让我们谈谈如何减少回流和重绘。
-
-#### 1. 最小化重绘和回流
-
-由于重绘和重排可能代价比较昂贵，因此最好就是可以减少它的发生次数。为了减少发生次数，我们可以合并多次对 *DOM* 和样式的修改，然后一次处理掉。考虑这个例子：
-
-```js
-const el = document.getElementById('test');
-el.style.padding = '5px';
-el.style.borderLeft = '1px';
-el.style.borderRight = '2px';
-```
-
-例子中，有三个样式属性被修改了，每一个都会影响元素的几何结构，引起回流。
-
-当然，大部分现代浏览器都对其做了优化，因此，只会触发一次重排。但是如果在旧版的浏览器或者在上面代码执行的时候，有其他代码访问了布局信息(上文中的会触发回流的布局信息)，那么就会导致三次重排。
-
-因此，我们可以合并所有的改变然后依次处理，比如我们可以采取以下的方式。
-
-使用 *cssText*
-
-```js
-const el = document.getElementById('test');
-el.style.cssText += 'border-left: 1px; border-right: 2px; padding: 5px;';
-```
-
-将要修改的 *CSS* 样式写在一个样式类里面，然后通过添加和删除该样式类的方式来改变样式
-
-```js
-const el = document.getElementById('test');
-el.className += ' active';
-```
-
-#### 2. 批量修改 *DOM*
-
-当我们需要对 *DOM* 对一系列修改的时候，可以通过以下步骤减少回流重绘次数：
-
-1. 使元素脱离文档流
-
-2. 对其进行多次修改
-
-3. 将元素带回到文档中。
-
-该过程的第一步和第三步可能会引起回流，但是经过第一步之后，对 *DOM* 的所有修改都不会引起回流，因为它已经不在渲染树了。
-
-有三种方式可以让 *DOM* 脱离文档流：
-
-- 隐藏元素，应用修改，重新显示
-
-- 使用文档片段（ *document fragment* ）在当前 *DOM* 之外构建一个子树，再把它拷贝回文档。
-
-- 将原始元素拷贝到一个脱离文档的节点中，修改节点后，再替换原始的元素。
-
-考虑我们要执行一段批量插入节点的代码：
-
-```js
-function appendDataToElement(appendToElement, data) {
- let li;
- for (let i = 0; i < data.length; i++) {
- li = document.createElement('li');
- li.textContent = 'text';
- appendToElement.appendChild(li);
- }
-}
-
-const ul = document.getElementById('list');
-appendDataToElement(ul, data);
-```
-
-如果我们直接这样执行的话，由于每次循环都会插入一个新的节点，会导致浏览器回流一次。
-
-我们可以使用上面所提到的三种方式进行优化。
-
-（1）隐藏元素，应用修改，重新显示
-
-这个会在展示和隐藏节点的时候，产生两次重绘。
-
-```js
-function appendDataToElement(appendToElement, data) {
- let li;
- for (let i = 0; i < data.length; i++) {
- li = document.createElement('li');
- li.textContent = 'text';
- appendToElement.appendChild(li);
- }
-}
-const ul = document.getElementById('list');
-ul.style.display = 'none';
-appendDataToElement(ul, data);
-ul.style.display = 'block';
-```
-
-（2）使用文档片段（ *document fragment* ）在当前 *DOM* 之外构建一个子树，再把它拷贝回文档
-
-```js
-const ul = document.getElementById('list');
-const fragment = document.createDocumentFragment();
-appendDataToElement(fragment, data);
-ul.appendChild(fragment);
-```
-
-（3）将原始元素拷贝到一个脱离文档的节点中，修改节点后，再替换原始的元素。
-
-```js
-const ul = document.getElementById('list');
-const clone = ul.cloneNode(true);
-appendDataToElement(clone, data);
-ul.parentNode.replaceChild(clone, ul);
-```
-
-#### 3. 避免触发同步布局事件
-
-上文我们说过，当我们访问元素的一些属性的时候，会导致浏览器强制清空队列，进行强制同步布局。
-
-举个例子，比如说我们想将一个 *p* 标签数组的宽度赋值为一个元素的宽度，我们可能写出这样的代码：
-
-```js
-function initP() {
- for (let i = 0; i < paragraphs.length; i++) {
- paragraphs[i].style.width = box.offsetWidth + 'px';
- }
-}
-```
-
-这段代码看上去是没有什么问题，可是其实会造成很大的性能问题。
-
-在每次循环的时候，都读取了 *box* 的一个 *offsetWidth* 属性值，然后利用它来更新 *p* 标签的 *width* 属性。
-
-这就导致了每一次循环的时候，浏览器都必须先使上一次循环中的样式更新操作生效，才能响应本次循环的样式读取操作。每一次循环都会强制浏览器刷新队列，一刷新队列就会引发回流和重绘。
-
-我们可以优化为：
-
-```js
-const width = box.offsetWidth;
-function initP() {
- for (let i = 0; i < paragraphs.length; i++) {
- paragraphs[i].style.width = width + 'px';
- }
-}
-```
-
-#### 4. 复杂动画脱离文档流
-
-对于复杂动画效果，由于会经常的引起回流重绘，因此，我们可以使用绝对定位，让它脱离文档流。否则会引起父元素以及后续元素频繁的回流。
-
-#### 5. *CSS3* 硬件加速（ *GPU* 加速 ）
-
-比起考虑如何减少回流重绘，我们更期望的是，根本不要回流重绘。
-
-使用 *CSS3* 硬件加速，可以让 *transform、opacity、filters* 这些动画不会引起回流重绘。但是对于动画的其它属性，比如 *background-color* 这些，还是会引起回流重绘的，不过它还是可以提升这些动画的性能。
-
-常见的触发硬件加速的 *CSS* 属性：
-
-- *transform*
-
-- *opacity*
-
-- *filters*
-
-- *Will-change*
-
-## 一道常见的面试题
-
-至此，你明白了浏览器渲染一张页面的整体流程，每一个步骤是在做什么事情，也知道了经常听到别人口中的回流和重绘是什么意思，并且知道一些能够避免回流和重绘的方法。
-
-最后，我们以一道经常被问到的面试题结束本篇文章。
-
-**经典真题：为什么操作 *DOM* 慢？**
-
-参考答案：因为 *DOM* 是属于渲染引擎中的东西，而 *JS* 又是 *JS* 引擎中的东西。当我们通过 *JS* 操作 *DOM* 的时候，这个操作就必然涉及到了两个线程之间的通信，操作 *DOM* 次数一多，也就等同于一直在进行线程之间的通信，从而产生性能消耗。另外，操作 *DOM* 还会带来回流和重绘，这在一定程度上也有性能上的问题。
-
-用我们传统的开发模式，原生 *JS* 或 *JQuery* 操作 *DOM* 时，浏览器会从构建 *DOM* 树开始从头到尾执行一遍流程。假设在一次操作中，我需要更新 *10* 个 *DOM* 节点，浏览器收到第一个 *DOM* 请求后并不知道还有 *9* 次更新操作，因此会马上执行流程，最终执行 *10* 次。例如，第一次计算完，紧接着下一个 *DOM* 更新请求，这个节点的坐标值就变了，前一次计算为无用功。计算 *DOM* 节点坐标值等都是白白浪费的性能。即使计算机硬件一直在迭代更新，操作 *DOM* 的代价仍旧是昂贵的，频繁操作还是会出现页面卡顿，影响用户体验。
-
-在 *Vue、React* 这种框架出现后，提出了虚拟 *DOM* 的概念，虚拟 *DOM* 就是为了解决浏览器性能问题而被设计出来的。例如，如果一次操作中有 *10* 次更新 *DOM* 的动作，虚拟 *DOM* 不会立即操作 *DOM*，而是将这 *10* 次更新的 *diff* 内容保存到本地一个 *JS* 对象中，最终将这个 *JS* 对象一次性 *attch* 到 *DOM* 树上，再进行后续操作，避免大量无谓的计算量。所以，用 *JS* 对象模拟 *DOM* 节点的好处是，页面的更新可以先全部反映在 *JS* 对象（ 虚拟 *DOM* ）上，操作内存中的 *JS* 对象的速度显然要更快，等更新完成后，再将最终的 *JS* 对象映射成真实的 *DOM*，交由浏览器去绘制。
-
-
-
-------
-
-
-
--*EOF*-
\ No newline at end of file
diff --git a/01. 浏览器的渲染流程/浏览器的渲染流程.md b/01. 浏览器的渲染流程/浏览器的渲染流程.md
new file mode 100644
index 0000000..c91ae3a
--- /dev/null
+++ b/01. 浏览器的渲染流程/浏览器的渲染流程.md
@@ -0,0 +1,317 @@
+# 浏览器的渲染流程
+
+
+
+本文主要包含以下内容：
+
+- 浏览器渲染整体流程
+- 解析 *HTML*
+- 样式计算
+- 布局
+- 分层
+- 生成绘制指令
+- 分块
+- 光栅化
+- 绘制
+- 常见面试题
+
+
+
+## 浏览器渲染整体流程
+
+浏览器，作为用户浏览网页最基本的一个入口，我们似乎认为在地址栏输入 *URL* 后网页自动就出来了。殊不知在用户输入网页地址，敲下回车的那一刻，浏览器背后做了诸多的事情。
+
+去除 *DNS* 查找等这些细枝末节的工作，整个大的部分可以分为两个，那就是**网络**和**渲染**。
+
+
+
+首先，浏览器的网络线程会发送 *http* 请求，和服务器之间进行通信，之后将拿到的 *html* 封装成一个渲染任务，并将其传递给渲染主线程的消息队列。在事件循环机制的作用下，渲染主线程取出消息队列中的渲染任务，开启渲染流程。
+
+网络线程和服务器之间通信的过程并非本节课咱们要讨论的，本节课咱们要研究的主要内容，是浏览器的渲染进程如何将一个密密麻麻的 *html* 字符串渲染成最终页面的。
+
+我们先来看一下整体流程，整个渲染流程分为多个阶段，分别是： *HTML* 解析、样式计算、布局、分层、生成绘制指令、分块、光栅化、绘制：
+
+
+
+每个阶段都有明确的输入输出，上一个阶段的输出会成为下一个阶段的输入。
+
+这样，整个渲染流程就形成了一套组织严密的生产流水线。
+
+接下来，咱们就一起来看一下每一个阶段的各个流程究竟是在干什么。
+
+
+
+## 解析 *HTML*
+
+首先第一步就是解析 *html*，生成 *DOM* 树。
+
+当我们打开一个网页时，浏览器都会去请求对应的 *HTML* 文件。虽然平时我们写代码时都会分为 *HTML、CSS、JS* 文件，也就是字符串，但是计算机硬件是不理解这些字符串的，所以在网络中传输的内容其实都是 *0* 和 *1* 这些字节数据。
+
+当浏览器接收到这些字节数据以后，它会将这些字节数据转换为字符串，也就是我们写的代码。
+
+
+
+当数据转换为字符串以后，浏览器会先将这些字符串通过词法分析转换为标记（ *token* ），这一过程在词法分析中叫做标记化（ *tokenization* ）。
+
+为什么需要标记化呢？原因很简单，现在浏览器虽然将字节数据转为了字符串，但是此时的字符串就如何一篇标题段落全部写在一行的文章一样，浏览器此时仍然是不能理解的。
+
+例如：
+
+```html
+this is a test
+``` + +因此现在所做的标记化，本质就是要将这长长的字符串分拆成一块块，并给这些内容打上标记，便于理解这些最小单位的代码是什么意思。 + +
+
+将整个字符串进行了标记化之后，就能够在此基础上构建出对应的 *DOM* 树出来。
+
+
+
+上面的步骤，我们就称之为解析 *HTML*。整个流程如下图：
+
+
+
+在解析 *HTML* 的过程中，我们可以能会遇到诸如 *style、link* 这些标签，聪明的你应该已经想到了，这是和我们网页样式相关的内容。此时就会涉及到 *CSS* 的解析。
+
+为了提高解析效率，浏览器在开始解析前，会启动一个预解析的线程，率先下载 *HTML* 中的外部 *CSS* 文件和外部的 *JS* 文件。
+
+如果主线程解析到 *link* 位置，此时外部的 *CSS* 文件还没有下载解析好，主线程不会等待，继续解析后续的 *HTML*。这是因为下载和解析 *CSS* 的工作是在预解析线程中进行的。这就是 *CSS* 不会阻塞 *HTML* 解析的根本原因。
+
+
+
+最终，*CSS* 的解析在经历了从字节数据、字符串、标记化后，最终也会形成一颗 *CSSOM* 树。
+
+
+
+上面也有提到，预解析线程除了下载外部 *CSS* 文件以外，还会下载外部 *JS* 文件，那么这里同学们自然也会好奇针对 *JS* 代码浏览器是如何处理的？
+
+如果主线程解析到 *script* 位置，会停止解析 *HTML*，转而等待 *JS* 文件下载好，并将全局代码解析执行完成后，才能继续解析 *HTML*。
+
+为什么呢？
+
+这是因为 *JS* 代码的执行过程可能会修改当前的 *DOM* 树，所以 *DOM* 树的生成必须暂停。这就是 *JS* 会阻塞 *HTML* 解析的根本原因。
+
+
+
+因此，如果你想首屏渲染的越快，就越不应该在最前面就加载 *JS* 文件，这也是都建议将 *script* 标签放在 *body* 标签底部的原因。
+
+```html
+
+
+ ...
+
+
+
+
+
+
+```
+
+另外，在现代浏览器中，为我们提供了新的方式来避免 *JS* 代码阻塞渲染的情况：
+
+- *async*
+- *defer*
+- *prefetch*
+- *preload*
+
+关于这几种方式的区别，我们在另外一篇文章中再具体来看。
+
+最后总结一下此阶段的成果，第一步完成后，会得到 *DOM* 树和 *CSSOM* 树，浏览器的默认样式、内部样式、外部样式、行内样式均会包含在 *CSSOM* 树中。
+
+得到了两棵树，如下图所示：
+
+
+
+## 样式计算
+
+接下来进入第二步：样式计算
+
+拥有了 *DOM* 树我们还不足以知道页面的外貌，因为我们通常会为页面的元素设置一些样式。主线程会遍历得到的 *DOM* 树，依次为树中的每个节点计算出它最终的样式，称之为 *Computed Style*。
+
+在这一过程中，很多预设值会变成绝对值，比如 *red* 会变成 *rgb(255,0,0)*；相对单位会变成绝对单位，比如 *em* 会变成 *px*。
+
+
+
+浏览器会确定每一个节点的样式到底是什么，并最终生成一颗样式规则树，这棵树上面记录了每一个 *DOM* 节点的样式。
+
+另外需要注意的是，这里所指的浏览器确定每一个节点的样式，是指在样式计算时会对所有的 *DOM* 节点计算出**所有的**样式属性值。如果开发者在书写样式时，没有写某一项样式，那么大概率会使用其默认值。例如：
+
+
+
+关于样式计算的详细过程，请参阅文章《*CSS* 属性计算过程》。
+
+这一步完成后，我们就得到一棵带有样式的 *DOM* 树。也就是说，经过样式计算后，之前的 *DOM* 数和 *CSSOM* 数合并成了一颗带有样式的 *DOM* 树。
+
+
+
+## 布局
+
+前面这些步骤完成之后，渲染进程就已经知道页面的具体文档结构以及每个节点拥有的样式信息了，可是这些信息还是不能最终确定页面的样子。
+
+举个例子，假如你现在想通过电话告诉你的朋友你身边的一幅画的内容：“画布上有一个红色的大圆圈和一个蓝色的正方形”，单凭这些信息你的朋友是很难知道这幅画具体是什么样子的，因为他不知道大圆圈和正方形具体在页面的什么位置，是正方形在圆圈前面呢还是圆圈在正方形的前面。
+
+
+
+渲染网页也是同样的道理，只知道网站的文档流以及每个节点的样式是远远不足以渲染出页面内容的，还需要通过布局（*layout*）来计算出每个节点的几何信息（*geometry*）。
+
+生成布局树的具体过程是：主线程会遍历刚刚构建的 *DOM* 树，根据 *DOM* 节点的计算样式计算出一个布局树（*layout tree*）。布局树上每个节点会有它在页面上的 *x，y* 坐标以及盒子大小（*bounding box sizes*）的具体信息。
+
+
+
+布局树大部分时候，和 *DOM* 树并非一一对应。虽然它长得和先前构建的 *DOM* 树差不多，但是不同的是这颗树只有那些可见的（*visible*）节点信息。
+
+比如 *display:none* 的节点没有几何信息，因此不会生成到布局树；
+
+
+
+又比如使用了伪元素选择器，虽然 *DOM* 树中不存在这些伪元素节点，但它们拥有几何信息，所以会生成到布局树中。
+
+
+
+还有匿名行盒、匿名块盒等等都会导致 *DOM* 树和布局树无法一一对应。
+
+
+
+## 分层
+
+在确认了布局树后，接下来就是绘制了么？
+
+还不急，这里还会有一个步骤，就是**分层**。
+
+
+
+分层的好处在于，将来某一个层改变后，仅会对该层进行后续处理，从而提升效率。
+
+为了确定哪些元素需要放置在哪一层，主线程需要遍历整颗布局树来创建一棵层次树（*Layer Tree*）
+
+
+
+滚动条、堆叠上下文、*transform*、*opacity* 等样式都会或多或少的影响分层结果，也可以通过使用 *will-change* 属性来告诉浏览器对其分层。
+
+
+
+## 生成绘制指令
+
+分层工作结束后，接下来就是生成绘制指令。
+
+主线程会为每个层单独产生绘制指令集，用于描述这一层的内容该如何画出来。
+
+
+
+这里的绘制指令，类似于“将画笔移动到 *xx* 位置，放下画笔，绘制一条 *xx* 像素长度的线”，我们在浏览器所看到的各种复杂的页面，实际上都是这样一条指令一条指令的执行所绘制出来的。
+
+如果你熟悉 *Canvas*，那么这样的指令类似于：
+
+```js
+context.beginPath(); // 开始路径
+context.moveTo(10, 10); // 移动画笔
+context.lineTo(100, 100); // 绘画出一条直线
+context.closePath(); // 闭合路径
+context.stroke(); // 进行勾勒
+```
+
+但是你要注意，这一步只是生成诸如上面代码的这种绘制指令集，还没有开始执行这些指令。
+
+另外，还有一个重要的点你需要知道，生成绘制指令集后，渲染主线程的工程就暂时告一段落，接下来主线程将每个图层的绘制信息提交给合成线程，剩余工作将由合成线程完成。
+
+
+
+## 分块
+
+合成线程首先对每个图层进行分块，将其划分为更多的小区域。
+
+
+
+此时，它不再是像主线程那样一个人在战斗，它会从线程池中拿取多个线程来完成分块工作。
+
+
+
+## 光栅化
+
+分块完成后，进入**光栅化**阶段。所谓光栅化，就是将每个块变成位图。
+
+更简单的理解就是确认每一个像素点的 *rgb* 信息，如下图所示：
+
+
+
+光栅化的操作，并不由合成线程来做，而是会由合成线程将块信息交给 *GPU* 进程，以极高的速度完成光栅化。
+
+
+
+*GPU* 进程会开启多个线程来完成光栅化，并且优先处理靠近视口区域的块。
+
+
+
+
+
+## 绘制
+
+最后一步，我们总算迎来了真正的绘制。
+
+当所有的图块都被栅格化后，合成线程会拿到每个层、每个块的位图，从而生成一个个「指引（quad）」信息。
+
+
+
+指引会标识出每个位图应该画到屏幕的哪个位置，以及会考虑到旋转、缩放等变形。
+
+变形发生在合成线程，与渲染主线程无关，这就是 *transform* 效率高的本质原因。
+
+
+
+合成线程会通过 IPC 向浏览器进程（*browser process*）提交（*commit*）一个渲染帧。这个时候可能有另外一个合成帧被浏览器进程的 *UI*线程（*UI thread*）提交以改变浏览器的 *UI*。这些合成帧都会被发送给 *GPU* 完成最终的屏幕成像。
+
+如果合成线程收到页面滚动的事件，合成线程会构建另外一个合成帧发送给 *GPU* 来更新页面。
+
+
+
+
+
+最后总结一下浏览器从拿到 *html* 文档到最终渲染出页面的整体流程，如下图：
+
+
+
+
+
+## 常见面试题
+
+1. 什么是 *reflow*？
+
+>*reflow* 的本质就是重新计算 *layout* 树。
+>
+>当进行了会影响布局树的操作后，需要重新计算布局树，会引发 *layout*。
+>
+>为了避免连续的多次操作导致布局树反复计算，浏览器会合并这些操作，当 *JS* 代码全部完成后再进行统一计算。所以，改动属性造成的 *reflow* 是异步完成的。
+>
+>也同样因为如此，当 *JS* 获取布局属性时，就可能造成无法获取到最新的布局信息。
+>
+>浏览器在反复权衡下，最终决定获取属性立即 *reflow*。
+>
+>
+
+
+
+2. 什么是 *repaint*？
+
+>*repaint* 的本质就是重新根据分层信息计算了绘制指令。
+>
+>当改动了可见样式后，就需要重新计算，会引发 *repaint*。
+>
+>由于元素的布局信息也属于可见样式，所以 *reflow* 一定会引起 *repaint*。
+>
+>
+
+
+
+3. 为什么 *transform* 的效率高？
+
+>因为 *transform* 既不会影响布局也不会影响绘制指令，它影响的只是渲染流程的最后一个「*draw*」阶段
+>
+>由于 *draw* 阶段在合成线程中，所以 *transform* 的变化几乎不会影响渲染主线程。反之，渲染主线程无论如何忙碌，也不会影响 *transform* 的变化。
+>
+>
+
+
+
+-*EOF*-
diff --git a/01. 浏览器的渲染流程/课堂代码/index.html b/01. 浏览器的渲染流程/课堂代码/index.html
new file mode 100644
index 0000000..3fa34fc
--- /dev/null
+++ b/01. 浏览器的渲染流程/课堂代码/index.html
@@ -0,0 +1,33 @@
+
+
+
+
+
+
+ + Lorem ipsum dolor sit amet. +
++ Lorem ipsum dolor sit amet. +
+ + + \ No newline at end of file diff --git a/01. 浏览器的渲染流程/课堂代码/动画.html b/01. 浏览器的渲染流程/课堂代码/动画.html new file mode 100644 index 0000000..904a77c --- /dev/null +++ b/01. 浏览器的渲染流程/课堂代码/动画.html @@ -0,0 +1,51 @@ + + + + + + +