[Weex Tips] 合理使用 Weex 的生命周期

这是 Weex Tips 系列文章中的一篇，汇总目录在 这里。

• 首先建议先看一下有关组件定义的官方文档，其中介绍了生命周期。
• 在 Weex 项目里有个 issue 专门描述了 Weex 的生命周期，里面有几张很清晰的图，我这里只讲一下用法。
• 如果想了解组件的编译细节可以参考：《详解 Weex JS Framework 的编译过程》。

如果看完了上边的链接，对 Weex 生命周期的理解应该很到位了，可以简单总结成这么一张图：

注：在新版本的 JS Framework（>0.15.6）中才支持 destroyed 生命周期。

生命周期的用法

<script>
  module.exports = {
    data: {},
    methods: {},

    init: function () {
      console.log('在初始化内部变量，并且添加了事件功能后被触发');
    },
    created: function () {
      console.log('完成数据绑定之后，模板编译之前被触发');
    },
    ready: function () {
      console.log('模板已经编译并且生成了 Virtual DOM 之后被触发');
    },
    destroyed: function () {
      console.log('在页面被销毁时调用');
    }
  }
</script>

注意这几个生命周期函数 init 、created 、ready 、destroyed 和 data 、methods 属性是平级的，不要将其放在 methods 中，虽然当前版本兼容这种用法，以后也有可能会放弃支持。

除此之外，不建议在根对象上定义其他属性，数据应该放在 data 属性中，自定义的方法放在 methods 中，方法的执行环境（this）是当前组件对应的 Vm 对象，接口参考：Instance Apis。

init

在 init 方法执行时，刚初始化了内部变量，添加了事件的功能。此时还没有执行数据绑定，也没有创建 Virtual-DOM ，所以不能通过 this 获取到 data 中的数据，不能调用到 methods 中定义的方法，也不能获取到 Virtual-DOM 的节点。

可以在这个方法中可以初始化一些内部变量，也可以绑定一些自定义的事件。

created

created 的名称有点令人迷惑，会让人以为节点全部都创建完成了，其实只是刚完成了数据绑定，还没开始编译模板。此时可以通过 this 操作 data 中的数据，也可以调用 methods 中的方法，但是获取不到 Virtual-DOM 的节点。

由于还没开始执行节点的渲染，可以在 created 方法中修改 data 中的数据（例如某些需要动态计算的属性），此时的修改不会触发额外的渲染。

ready

ready 开始执行时，表示当前组件已经渲染完成。这个过程是自底向上触发的，会首先先执行子组件的 ready 方法。也就是说，在父组件执行 ready 时，所有子组件都已经渲染完成，而且已经执行完各自的 ready 方法。

此时可以通过 this.$el(id) 获取到节点的 Virtual-DOM，也可以通过 this.$vm(id) 获取到子组件的 Vm 实例。

不过，在 ready 方法中要小心地操作 data 中的数据，避免频繁赋值，因为此时已经完成了数据和 UI 的绑定，每次修改值都可能触发局部页面重新渲染。建议先取出需要频繁改动的值，然后等操作执行结束后，再一并赋值：

module.exports = {
  data: {
    count: 0
  },
  ready: function () {
    var count = this.count;
    for (var i = 0; i < 999; i++) {
      count += Math.random();
    }
    this.count = count;
  }
}

如代码所示，在修改 this.count 前先获取它的值，在执行完操作后再赋值回去，如果在循环体中直接设置 this.count 的值，页面将触发 999 次局部刷新，很可能会导致页面卡顿。

对于复杂的数据对象，也建议用 取值 -> 修改 -> 赋值 的方式更新数据。

destroyed

destroyed 方法将在组件销毁（通常是页面跳转）时被调用。和 ready 类似，它也是自底向上执行，先触发子组件的 destroyed 方法，再触发自身。而且框架会先执行开发者定义的 destroyed 方法，然后再清除内部属性。

如果添加了一些属性到全局或者 this 上，建议在 destroyed 方法中手动清除，避免内存泄漏。

其他建议

无论在何时，都不建议获取 Vm 和 Virtual-DOM 内部属性，这部分数据对开发者是透明的，而且在版本迭代过程中很可能会修改。

如果有特殊开发需求，建议联系 Weex 开发组的同学讨论解决方法。