浏览器渲染流程

这个东西，面试会出在哪里呢？ 从输入一个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操作次数，性能会有较大提升。