面试肯定会问到这个吧~
So：再一次的屡屡浏览器的渲染机制~
在渲染一开始会先从网络层获取请求文档（HTML、XML）的内容，然后再进行以下基本流程
3.1 解析HTML =》 DOM树
从HTML文本解析到HTML语法树，再解析到文档对象树（DOM Tree） HTML语法树生成的两个过程 1. 词法解析： 按照词法规则将HTML文本分割成大量的标记(Token), 并去除其中无关的字符(空格), 2. 语法解析： 匹配Token序列生成语法树, 有两种匹配方式：自上而下，自下而上 2.1 自上而下解析器和自下而上解析器。直观地来说，自上而下的解析器从语法的高层结构出发，尝试从中找到匹配的结构。而自下而上的解析器从低层规则出发，将输入内容逐步转化为语法规则，直至满足高层规则 2.2 但是HTML无法用常规的自上而下或自下而上的解析器进行解析 原因： 2.2.1 语言的宽容本质， 2.2.2. 浏览器对常见无效HTML用法的包容态度, 2.2.3. 解析过程需要不断重复，源内容在解析过程中通常不会改变，但是HTML中，脚本标记如果包含document.write，就会添加额外的标记，这样的解析过程实际上就更改了输入内容 3. 容错机制： 解析器在对标记化输入内容进行解析，以构建文档树，如果文档的格式正确就直接进行解析，遗憾的是，HTML文档不可能不会有格式错误的时候，因此解析器必须具备一定的容错性 3.1 明显不能再某些外部标记中添加的元素，在此情况下，我们应该关闭所有标记，知道出现禁止添加的元素，然后再加入该元素 3.2 浏览器不能直接添加的元素，但开发者忘记添加了，浏览器会自动添加 3.3 向inline元素内添加block元素。闭合所有inline元素，直到出现下一个较高级的block元素 3.4 如果这样仍然无效。可关闭所有元素、直到可以添加元素可止，或者忽略该标记
浏览器内核中对HTML页面真正的内部表示并不是语法树，而是文档对象模型，DOM也是树形结构，以Document对象为根元素,
DOM节点基本和HTML语法树节点一一对应
2.3 JS解析的影响
DOM树创建过程中遇到script标签会创建HTMLScriptElement实例，HTMLScript-Element的父类ScriptElement中包含了对JS脚本的所有处理，包括下载、缓存、执行。
3.2 解析CSS =》 CSSOM
页面中所有的CSS由样式表CSSStyleSheet集合构成，而CSSStyle是一系列CSSRule的集合，每一条CSSRule则由选择器CSSStyleSelector部分和声明CSSStyleDeclaration部分构成, 而CSSStyleDeclaration是css树形和值的key-Value集合
CSS解析完毕后进行CSSRule的匹配过程，寻找满足每条css规则Selector部分的HTML元素，然后将其Declaration部分应用于该元素，实际上还会考虑样式的继承和样式默认(遵循CSS规则)
3.3 布局： 渲染树(Render Tree) <= attchment(DOM Tree + Style Rules）
渲染树用于表示文档的可视信息，记录文档中每个可视元素的布局和渲染方式 HTML页面通过CSS控制页面布局，所以渲染树的每个节点对象都需要知道自己身上的CSS属性，那么CSSSelector此时就是在找到对应的渲染节点
所以渲染树的每个Node都存储了绘制页面所需的样式及布局信息，每个节点都知道如何去绘制自己，这也就是渲染树与DOM树的区别，渲染树用于显示，那些不可见的元素不会出现在渲染树中 不可见元素
【回流(reflow)】
布局优化方案： 尽量触发小规模的重绘，不会触发回流 1. 不要一条一条修改DOM属性，修改className或者修改CSSText 2. 对于一个元素进行复杂的操作时，可以先隐藏它，操作完成后再显示 3. 在需要经常获取那些引起浏览器回流的属性值时，要缓存到变量中 4. 不要使用table布局，因为一个小改动可能会造成整个table重新布局 5. 对于一些进行动画的元素，可以进行硬件渲染，从而避免重绘和回流
【重绘(repaint)】
3.4 绘制 painting
在绘制阶段，系统会遍历渲染树，并调用渲染器的"paint"方法，将渲染器的内容显示在屏幕上
以下是两大内核的渲染流程
