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

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

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

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

[Weex Tips] 合理使用 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>

注意这几个生命周期函数 initcreatedreadydestroyeddatamethods 属性是平级的,不要将其放在 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 方法。

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

此时可以通过 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 开发组的同学讨论解决方法。

上一篇:进击的 Kubernetes 调度系统(一):Kubernetes scheduling framework


下一篇:C# WinForm多线程开发(一) Thread类库