看到一篇很好的文章，浏览器的工作原理，http://www.html5rocks.com/zh/tutorials/internals/howbrowserswork/
看一遍，把要点梳理一下。
1.浏览器的结构
1）UI 主界面、地址栏、前进后退等
2）Browser engine，adapter层。
3）render engine，如果adapter层发来html的请求，render会解析html和css，并将结果最终渲染到屏幕上。
4）network，底层网络模块，与平台无关，负责所有网络接口。
5）JavaScript解释器，负责解析和执行JS
6）UI后端，绘制基本的窗口小控件，和平台无关，在底层使用操作系统的绘制方法。
7）数据存储，如cookie和indexdb等
Render Engine，渲染引擎
渲染引擎是web的核心，因为web中一般不做复杂的计算等操作。页面需要及时响应用户操作，流畅的渲染。那么来看一下渲染的基本流程
1.解析HTML，生成DOM-TREE，解析CSS，生成CSSOM，合成RenderTree，就是包含一堆矩形的树，树结构代表了显示顺序。
2.layout，计算位置
3.paint
下图是webkit的渲染过程
解析过程
上面的流程中，HTML Parser CSS Parser都涉及到了一个解析的过程，什么是解析？
解析就是把文档转化成代码能理解的结构，生成结果被称为解析树或语法树。
解析基于确定的语法规则，即与上下文无关的语法。
解析可以分为两个过程：词法分析和语法分析。
解析把两个过程交给两个组件，词法分析器和解析器。
词法分析器负责把输入内容分成一个个标记。
解析器负责把标记构建成解析树。解析器的解析是一个迭代过程，即向词法分析器请求一个新标记，如果匹配语法规则，则把对应该标记的节点添加到解析树中，如果不匹配，则把这个标记缓存，继续请求标记，直到找到一个匹配的语法规则。
解析树往往还不是最终产品，这个时候需要使用编译器把解析树转成机器代码。
一般的解析可以去看龙书，Html语言不适用于常规解析器，因为HTML不是一种上下文无关的语言，这源于HTML有一定的容错能力。CSS和JavaScript可以。
HTML有自定义的解析器，采用DTD格式定义。
解析算法分为两个步骤，标记化和构建树：
标记化算法使用状态机驱动，该算法比较复杂，通过一个例子叙述：
<html> <body> Hello world </body> </html>
1.初始状态为 数据状态，
2.遇到<时，更改为标记打开状态，
3.之后读取一个a-z字符，进入标记名状态
4.直到遇到>，进入数据状态
5.数据状态下去读Hello world，直到<，进入标记打开状态
6.标记打开状态下遇到/号，创建 end tag token并进入标记名状态
7.读取a-z字符直到>，回到数据状态。
解析器创建时，会创建Document对象。在解析器工作的时候，已Document为根节点的DOM树不断更新，解析器生成的元素不仅仅会加入DOM树，还会放到堆栈中去，堆栈用来纠正嵌套错误和未关闭的标记。
树构建过程
树构建阶段的输入是一个来自标记化阶段的标记序列。第一个模式是“initial mode”。接收 HTML 标记后转为“before html”模式，并在这个模式下重新处理此标记。这样会创建一个 HTMLHtmlElement 元素，并将其附加到 Document 根对象上。
然后状态将改为“before head”。此时我们接收“body”标记。即使我们的示例中没有“head”标记，系统也会隐式创建一个 HTMLHeadElement，并将其添加到树中。
现在我们进入了“in head”模式，然后转入“after head”模式。系统对 body 标记进行重新处理，创建并插入 HTMLBodyElement，同时模式转变为“in body”。
现在，接收由“Hello world”字符串生成的一系列字符标记。接收第一个字符时会创建并插入“Text”节点，而其他字符也将附加到该节点。
接收 body 结束标记会触发“after body”模式。现在我们将接收 HTML 结束标记，然后进入“after after body”模式。接收到文件结束标记后，解析过程就此结束。
树构建过程
解析过程结束后，浏览器将文档注为交互状态，开始加载 defferd模式下的脚本。然后文档状态成为完成，随之触发加载事件。
容错
浏览器底层有大量的代码来对诸如 无效tag，结束符错误等容错。
来看看webkit的容错说明
解析器对标记化输入内容进行解析，以构建文档树。如果文档的格式正确，就直接进行解析。
遗憾的是，我们不得不处理很多格式错误的 HTML 文档，所以解析器必须具备一定的容错性。
我们至少要能够处理以下错误情况：
- 明显不能在某些外部标记中添加的元素。在此情况下，我们应该关闭所有标记，直到出现禁止添加的元素，然后再加入该元素。
- 我们不能直接添加的元素。这很可能是网页作者忘记添加了其中的一些标记（或者其中的标记是可选的）。这些标签可能包括：HTML HEAD BODY TBODY TR TD LI（还有遗漏的吗？）。
- 向 inline 元素内添加 block 元素。关闭所有 inline 元素，直到出现下一个较高级的 block 元素。
- 如果这样仍然无效，可关闭所有元素，直到可以添加元素为止，或者忽略该标记。
- 示例网站 www.liceo.edu.mx 嵌套了约 1500 个标记，全都来自一堆 <b> 标记。我们只允许最多 20 层同类型标记的嵌套，如果再嵌套更多，就会全部忽略。
- 支持格式非常糟糕的 HTML 代码。我们从不关闭 body 标记，因为一些愚蠢的网页会在实际文档结束之前就关闭。我们通过调用 end() 来执行关闭操作。
CSS解析是遵循一般的解析规则的，这里不赘述。
脚本和文档处理的顺序
当遇到一个script标签时，会立即停止文档的解析，进行js解析。
如果script标签带有defer标记，则会在文档解析完成后再解析。
h5增加了一个标记，将script标记为异步，则会开线程去解析它。
预解析
这是一项优化。在执行脚本的时候，其他线程回去解析剩下的文档部分，找出并加载需要下载的网络资源。预解析器不会动DOM树，只是寻找需要下载的资源。
样式表
理论上CSS和HTML不是一个解析器，但有些JS会请求CSS，所以浏览器在解析CSS的时候会禁止有交互的脚本。
Render-Tree
在DOM-Tree构建的时候，同时也在生成一个Render-Tree。Render-Tree是DOM-Tree的子集，它不包含那些display:none的元素，以及head等。
一般情况下DOM-Tree和Render-Tree的位置是对应的，但不包括absolute和float等非文档流内容，它们位于其他位置，原位置放一个占位符。
样式计算
样式计算是个复杂而庞大的工程，如 匹配规则为 div div div div，这样的匹配会很耗时，而且找了很久可能找到一个三层的。
浏览器为了样式计算进行了很多工作
共享样式数据
规则树
结构划分
使用规则树计算样式上下文
对规则进行处理以简化匹配
以正确的层叠顺序应用规则
样式表层叠顺序
特异性
特异性这里详细记一下
某个样式的属性声明可能会出现在多个样式表中，同一个样式表中也可能出现多次，那么他们的重要性为（优先级从低到高）：
1.浏览器声明
2.用户普通声明
3.作者普通声明
4.作者重要声明
5.用户重要声明
同样顺序的声明，按照特异性排序
特异性是 a-b-c-d
a：声明来自style，标记为1，否则为0
b：选择器中ID属性的个数
c：选择器中class属性和伪类的个数
d：选择器中元素名称和伪类的个数
规则排序
渐进式处理
这里不详细叙述。
布局-layout
layout是一个比较重的环节，不仅仅是layout消耗时间，而是layout后一定会引发paint。
HTML采用流式布局，意味着可以遍历一次就计算出来所有位置，从左到右，从上到下。有些特殊的如 表格需要多次遍历。
每一个节点都有一个layout/reflow方法，是一个递归过程。
Dirty位系统
为了避免细小改动都要进程整体布局，浏览器采用了Dirty位的设计。如果某个节点发生了改变，则将其与子代标注为dirty。还有一种标记，children are dirty，表示节点至少有一个子代需要重新布局。
布局分全局和增量两种
全局指必须重新布局，增量是只布局dirty节点（可能还需要布局其他元素）。全局布局是同步的，增量布局一般是异步的。
布局优化，如果只是位置改变或者缩放等，可以直接从缓存取原大小。某些子树修改，不必全局重新layout，如input，不会每输入一次就来一次全局更新。
Paint
paint的内容比较少，只是调用节点的paint方法。paint也有全局绘制和增量绘制两种。
优化
webkit在paint时会缓存之前的矩形，只绘制新旧矩形的差异部分。而当元素有了变化，浏览器会尽量做最小的改动。
线程
Render engin是单线程。
loop
主线程是一个loop，事件循环。
CSS模型
可视化模型，指画布
框模型，由框大小，padding，margin，border组成，display指定
position
普通 浮动 绝对
display：block 普通的矩形，拥有自己的区域
display：inline 没有自己的区域，位于容器block中
block是垂直的，inline是水平的
分层
z-index表示了框的第三个维度