浏览器渲染流程
这个东西，面试会出在哪里呢？ 从输入一个url到返回页面的过程发生了什么？ 这道题对于我这种憨憨来讲是十分困难的。
发送http请求报文
传输层(TCP协议)把从应用层收到的数据(HTTP请求报文)进行分割，并在各个报文打上标签与端口号
在网络层(IP协议)增加作为通信目的地的MAC地址转发给链路层
服务器端从链路层收到数据，按序往上层发送，当到达应用层时
服务端进行处理，将对应资源放到报文实体，按照s1返回给客户端
http协议考察完毕
接下来就是浏览器渲染过程: 浏览器渲染引擎工作流程都差不多，分为5步：
- 创建dom树
- 创建styleRules
- 创建render树
- 布局layout
- 绘制painting
具体来讲：
- 第一步，用HTML分析器，分析HTML元素，构建一颗DOM树(标记化和树构建)。
- 用CSS分析器，分析CSS文件和元素上的inline样式，生成页面的样式表。
- 将DOM树和样式表，关联起来，构建一颗Render树(这一过程又称为Attachment)。每个DOM节点都有attach方法，接受样式信息，返回一个render对象(又名renderer)。这些render对象最终会被构建成一颗Render树。
- 有了Render树，浏览器开始布局，为每个Render树上的节点确定一个在显示屏上出现的精确坐标。
- Render树和节点显示坐标都有了，就调用每个节点paint方法，把它们绘制出来。(这些方法都是内部的，用js看不出)
时机 ：
- DOM树的构建 : 它是一个渐进的过程，渲染引擎会将其尽快的显示在屏幕上，不必等到整个html文档解析完毕才开始render树与布局
- DOM树、CSSDOM树、Render树是顺序渲染的吗？ 这三个过程实际上不是完全独立，是会有交叉的，会造成一边加载，一边解析，一边渲染的工作现象。
顺带说一句：CSS的解析顺序有点类似操作符的短路，是从右往左解析的，所以不推荐使用太多的后代选择器(.a .b)，而是直接使用.a-b这样的操作。这样解析会快一点。之后会出优化的文章。
JS操作DOM的代价
在传统的开发流程中，使用原生的JS或JQ操作DOM时，很有可能触发回流操作，浏览器重新渲染部分或全部文档，更可怕的是，当需要更新多个节点时，一个节点更新后，导致前一个节点的坐标信息更新，前一次计算为无用功，计算DOM节点浪费了性能，所以直接操作DOM的代价十分昂贵，频繁操作还会造成页面卡顿影响用户体验
为什么需要虚拟DOM
首先，传统使用jquery的开发流程，对于数据量大，视图复杂并且功能繁多的页面，需要不断给节点添加事件，然后在回调中实现更新dom节点的操作，这样导致应用程序变得非常难以维护，后来人们采用MCV,MVP的架构模式。希望从代码层面降低维护这种复杂程序的维护。但是 MVC 架构没办法减少你所维护的状态，也没有降低状态更新你需要对页面的更新操作（前端来说就是DOM操作），你需要操作的DOM还是需要操作，只是换了个地方。
说的是这种
(function(){
var container = document.body
var Dom = {
a : document.getElementById('#a')
}
// M层
var xxxModel = function() {
var actino1 = function(),
action2,action3....
return {
action1...
}
}
// V层
var UIRender = function() {
..parseChapterData
return function(data) {
container.html(parseChapterData(data))
}
}
// C层
var EventHandler = function() {
// ...绑定事件
a.onclick = ...
a.addEventListener(...)
}
main()
})()
另一方面，虚拟DOM是为了解决浏览器性能问题设计出来的，我们执行更新大量节点操作时，通过在这个虚拟DOM上实现了一个 diff 算法找出最小变更，再把这些变更写入实际的DOM中。这个虚拟DOM以JS结构的形式存在，计算性能会比较好，而且由于减少了实际DOM操作次数，性能会有较大提升。
