JS控件的生命周期跟其他平台UI的生命周期类似，但是又有自己的特点，我们只有将控件的生命周期划分清晰，所有的控件编写、mixins的编写和plugin的编写才能遵循控件的生命周期做统一的管理。在这里我把JS的生命周期定义为4部分：
1.initializer: 初始化，做一些不牵扯DOM操作的初始化操作
2.createDom: 创建 DOM，在这个过程中我们创建控件需要的DOM结构
3.renderUI: 生成控件的内部元素，在这里调用子控件的渲染方法，开启子控件的生命周期
4.bindUI: 绑定事件，可以绑定子控件事件也可以绑定内部DOM的事件
5.synUI: DOM结构以及子控件生成完毕后，我们在配置项中传入的值或者默认的配置项要应用到DOM上，例如 width,height,focusable之类的属性
6.destructor: 析构函数，移除控件，清理控件上的事件，清理子控件，清理控件自己的DOM以及控件的一些对其他控件的引用。
图 1
初始化：
控件初始化过程中做以下事情：
1.调用继承的父类的初始化函数，包括原型链上的父类和mixins
2.处理配置项，合并默认配置项和用户传入的配置项
3.处理绑定到改对象的事件
4.初始化插件（plugin)
初始化完成后，是否创建DOM看具体的策略，类似于ext的实现，可以延迟创建DOM
创建DOM
创建DOM的过程如下：
1.调用继承的父类的创建DOM的函数，包括原型链上的父类和mixins
2.创建控件的DOM
3.调用控件插件的创建DOM的函数
渲染子控件和内部DOM操作
执行过程如下：
1.调用父类的渲染函数，包括原型链上的父类和mixins
2.调用插件的渲染函数
我们可以在顶级的父类来初始化子控件。好处是，子类不需要做子控件初始化的操作此时：
1.如果子控件还未初始化则执行初始化
2.继续执行子控件的创建DOM、渲染子控件、绑定事件、同步配置项函数执行
绑定事件
由于此时控件的DOM和内部的子控件已经渲染完毕，则可以在子控件或者DOM上绑定事件。绑定事件的过程：
1.调用父类的绑定事件方法，包括原型链上的父类和mixins
2.调用插件（plugin）的绑定事件方式
注意：在子控件或者内部DOM上绑定事件时，使用委托，不要直接在子控件或者DOM上绑定事件，一旦子控件添加或者删除，内部DOM变化都会引起事件失效。
同步配置项
首先说明一下什么叫做同步配置项，前面我们在初始化控件时，已经对配置项做过一定的处理（至于如何处理，后面讲 JS控件属性 的时候会讲到）,但是配置项并未作用到DOM上或者内部子控件上。
为什么在这时候处理同步，而不是在创建DOM和渲染子控件时，有2个原因：
1.在创建DOM和渲染子控件时，所有的DOM和子控件并未完整生成此时同步需要进行大量判断
2.我们需要把同步配置项的工作提取成方法，修改配置项时，内部DOM和子控件跟着变化。
例如：配置项里有 { width : 100 }
1.如果我们在渲染DOM时同步，则可能把“width=100px；”直接设置到DOM上，而到我们需要修改这个width时，我们还需要写一个函数来设置这个值。
2.反之，我们把同步配置项集中处理，将一个个的同步配置项的过程抽取成一个个函数，那么我们初始化 width的过程和修改width的过程完全一样，这样概念和逻辑就统一起来。
同步配置项的过程依然如其他步骤一样：
1.调用父类的同步方法，包括原型链上的父类和mixins
2.调用插件（plugin）的同步方法
注意：我们应该可以配置一个配置项是否在此时同步，原因有很多，比如多个配置项会产生同一操作，如果多个配置项同时同步，那么一个过程会反复执行多次。
移除控件
任何对象都有构造函数，必定也有析构函数，但是这个函数往往是大家最容易忽视的地方，但是也是非常重要的地方，暂且不说内存泄露之类的问题，就是如果一个控件的移除工作做得不够好，会对正常的使用带来很大的麻烦。
这个函数又是最不好写的一个函数，因为它需要处理以下工作：
1.清理使用的其他控件，是否也移除看具体情形。区分 关联和聚合
2.清理子控件
3.清理绑定到控件和DOM上的事件
4.移除DOM
5.清理变量的引用，这个比较麻烦和繁琐，所以我们需要对控件的引用做统一的管理
同样此函数也要执行：
1.调用父类的析构函数，包括原型链上的父类和mixins
2.调用插件的析构函数
问题
上面讲的全部是具体的步骤，但是在实现的时候遇到了一系列的问题：
1.调用父类的方法存在问题
1)调用原型链上的父类方法，只能使用 className.superclass.method.call(this)这类的方法，this.constructor.superclass.method.call(this)不能使用，原因在 js 控件继承 的extend一章中有讲到，这种调用方式繁琐而且维护不方便。
2)调用mixins上的方法，在JS 继承 mixins一章中我讲到过mixins的实现原理，覆盖同名方法，mixins的方法其实已经作为控件的prototype上的方法，所以最好不要使用同名方法，如果多个mixins都是用 renderUI,synUI之类的方法，而继承这些mixins的控件没有实现renderUI这类方法，那么就会被覆盖。
2.调用插件的方法也存在问题
1)我们需要获得当前控件的引用
解决方式：
1. 针对调用父类的方法我们可以在控件渲染时，按照原型链的顺序，先调用父类的方法再调用子类的方法直到当前控件：
如上面的继承关系，我们执行C.renderUI()时，按照继承原型链的顶层向下执行。
2. 执行minxins的方法，我们执行renderUI时，去依次执行 mixin 的__renderUI方法。
3. 执行父类的renderUI 时，如果也存在mixins那么执行mixin的 __renderUI方法。
图3
如上图所示： inherits表示原型链继承，extends表示 mixin扩展
那么c.renderUI的执行过程如下：
A.renderUI ->D.__renderUI->B.renderUI->E.__renderUI->C.renderUI
3. 调用插件方法时需要传递控件本身的引用即可，如：
plugin1.render(this)
4. 析构函数 destructor比较特使，执行的顺序跟上面2中讲的顺序有所不同：
子类 destructor -> 子类扩展 destructor -> 父类 destructor -> 父类扩展 destructor
按照图3的继承结构其析构函数执行的顺序是：
C. destructor ->E.__destructor->B.destructor->E.__destructor->a.destructor
原因是，子类的一些引用依赖于父类或者扩展类，如果父类和扩展类先执行析构函数，那么子类在使用某些变量/属性时会报错。
这一节我把控件的生命周期讲了一遍，所有的着一些都是来自于 KISSY框架的UIBase,感兴趣的可以去看一下，非常精彩的实现http://docs.kissyui.com/kissy/docs/#!/api/KISSY.Component.UIBase的
