前言

前段时间进行了weex页面尝试, 页面滚动加载渲染得非常流畅, 让H5页面拥有了native般的体验。
如此之利器，让人非常想探一究竟，因此最近进行了js-framwork源码学习(weex开源地址：https://github.com/alibaba/weex)，希望能进一步了解其dom渲染机制。

一. 文件结构

weex代码结构如下，重点关注其js-framework实现。

    ├── weex-dev
      ├── android
      ├── ios
      ├── bin
      ├── doc
      ├── examples
      ├── src
      │  ├── components
      │  ├── h5-render
      │  ├── js-framework
      │  ├── README.md
      ├── test
      ├── website
      ├── index.html
      ├── package.json
      ├── webpack.config.js
      ├── README.md
      └── ...

阅读js-framework代码,我整理了一份思维导图。

framework.js是Instance创建的入口，可以从这个文件开始自顶向下地阅读代码，了解其工作原理。可以重点理解它的DOM结构，初始化过程，数据更新过程，下面我也将从这几个方面进行描述。

二. 主要类分析

1. DOM、Listener与EventManager

Weex的DOM结构由Document、Element、Comment三类组成。Element创建普通节点，Comment用于创建frag block节点。每个节点都有一个唯一的ref值，可以很方便地在文档中被查询到，同时记录其父节点parentRef，通过这种’双向链表‘的操作可以方便进行节点拼接和获取。文档树节点Document记录整个DOM的结构，同时在Document上绑定EventManager事件处理器和Listener监听操作处理器。EventManager记录每个绑定了事件的节点和它对应的事件处理函数,提供事件的添加、删除和触发。Listener提供了dom操作转化为callNative的能力，通过将每一个操作转化为对应类型的actions，如createBody、addElement,并将每一个actions记录updates数组。

2. compiler、directive、watcher

Weex复用了 Vue.js 的数据监听和依赖收集的代码实现。通过observer、directive、watcher之间的协作，建立数据（Model）和视图（View）的关联关系：

• observer 对 data 进行了监听，并且提供订阅某个数据项的变化的能力
• compiler解析template，并解析其中的 directive，得到每一个 directive 所依赖的数据项及其更新方法
• watcher 把上述两部分结合起来，即把 directive 中的数据依赖订阅在对应数据的 observer 上，这样当数据变化的时候，就会触发 observer，进而触发相关依赖对应的视图更新方法。

三. 初始化过程

当我们在浏览器中输入我们的bundle地址，其解析渲染为HTML过程大致可以分解为createInstance->initInstace->run bundle->define->boostrap->create Vm->生命周期函数。可细化为下面这些步骤：

initInstance: 根据webpack打包后的js代码来定义实例。
define: 解析代码中的__weex_define__("@weex-component/bottom-bar"）定义的component，包含依赖的子组件。并将component记录到customComponentMap[name] = exports数组中，维护组件与组件代码的对应关系。由于会依赖子组件，因此会被多次调用。

• define执行后的APPInstance实例结构：
  

bootstrap：解析代码中的__weex_bootstrap__("@weex-component/30d1c553f95b5f87afb6a1cff70a7bbd")执行当前页面，提取customComponentMap中记录的组件代码进行初始化。只会执行一次。
downgrade: 检测页面降级配置进行页面降级。
initEvents: 绑定events和lifecycle（init、create、ready）执行的钩子。
initScope: 执行initData()、initComputed、initMethods。初始化data、computed属性和methods，并进行data的observer监听。
build: 根据预留选项opt.replace进行编译，目前该选项还未被实质使用。编译完成后执行ready的钩子命令，执行ready。
compile: 编译视图。
updateActions: 检测是否有数据更新需要执行。
createFinish: 表明dom结构创建完成，想callQueue队列中添加一个'createFinish'的actions。
processCallQueue: 依次执行队列中的actions，进行节点渲染到页面的过程，为了性能考虑，通过requestAnimationFrame进行分帧渲染。

• callQueue队列
  

通过初始化过程我们可以得到init -> 数据监听 -> created -> 视图生成 -> ready，为了避免重复的视图操作，可在init进行数据的获取，created阶段进行数据的赋值和修改。

部分过程细化

1. compile()：

首先根据tagert的type类型选择不同的编译方式：数组类型、content类型(占位，可参考special-element)、repeat元素、if元素、function类型元素、子组件元素、内置定义的元素。内置元素类型可在config.js中查看，目前是text、image、container、slider、cell。以内置元素的编译为例，进行body和element节点的编译。在编译的时候会解析节点的attr、class、style、events指令，并进行监听。
从上图可知，weex提供了两种append方式：tree、node。

• tree：先渲染子节点树，最后渲染父节点
• node：先渲染父节点，然后子节点一个个append
• 进行了不同的节点数量，VM创建耗时采样对比，从图中可以看出当节点个数较多的时候tree模式比node模式渲染的快

2. attachTarget()、updateActions()、callTasks()：

attachTarget: 进行节点渲染的时候，将每个append动作细化为具体的actions，置入callQueue队列中。
updateActions: 检测是否有diff，如果有，则执行diff中记录的task
callTasks: 调用callNative，根据执行状态判断是否执行callQueue列表中的人物或者置入callQueue队列中。

四. 数据更新过程

执行click事件，其中修改了data数据值，执行顺序如下：

通过上文分析，可以认为：

1. tree模式比node模式渲染的快。
2. 每个节点的创建都对应一个callQueue任务，节点逐个逐个的append到页面中。
3. 依赖发布订阅模式收集依赖，监听每一个属性的变化，可直接获取更新操作，映射到dom结构中。
4. 与native交互通过 CallNative()方法；响应JS调用采用CallJS()方法。

以上是个人拙见，本文中描述不正确的地方欢迎指正~