JS控件的生命周期跟其他平臺UI的生命周期類似，但是又有自己的特點，我們只有將控件的生命周期劃分清晰，所有的控件編寫、mixins的編寫和plugin的編寫才能遵循控件的生命周期做統(tǒng)一的管理。在這里我把JS的生命周期定義為4部分：

1.initializer: 初始化，做一些不牽扯DOM操作的初始化操作
2.createDom: 創(chuàng)建 DOM，在這個過程中我們創(chuàng)建控件需要的DOM結(jié)構(gòu)
3.renderUI: 生成控件的內(nèi)部元素，在這里調(diào)用子控件的渲染方法，開啟子控件的生命周期
4.bindUI: 綁定事件，可以綁定子控件事件也可以綁定內(nèi)部DOM的事件
5.synUI: DOM結(jié)構(gòu)以及子控件生成完畢后，我們在配置項中傳入的值或者默認的配置項要應(yīng)用到DOM上，例如 width,height,focusable之類的屬性
6.destructor: 析構(gòu)函數(shù)，移除控件，清理控件上的事件，清理子控件，清理控件自己的DOM以及控件的一些對其他控件的引用。

圖 1

初始化：

控件初始化過程中做以下事情：
1.調(diào)用繼承的父類的初始化函數(shù)，包括原型鏈上的父類和mixins
2.處理配置項，合并默認配置項和用戶傳入的配置項
3.處理綁定到改對象的事件
4.初始化插件（plugin)
初始化完成后，是否創(chuàng)建DOM看具體的策略，類似于ext的實現(xiàn)，可以延遲創(chuàng)建DOM

創(chuàng)建DOM

創(chuàng)建DOM的過程如下：
1.調(diào)用繼承的父類的創(chuàng)建DOM的函數(shù)，包括原型鏈上的父類和mixins
2.創(chuàng)建控件的DOM
3.調(diào)用控件插件的創(chuàng)建DOM的函數(shù)

渲染子控件和內(nèi)部DOM操作

執(zhí)行過程如下：
1.調(diào)用父類的渲染函數(shù)，包括原型鏈上的父類和mixins
2.調(diào)用插件的渲染函數(shù)
我們可以在頂級的父類來初始化子控件。好處是，子類不需要做子控件初始化的操作此時：
1.如果子控件還未初始化則執(zhí)行初始化
2.繼續(xù)執(zhí)行子控件的創(chuàng)建DOM、渲染子控件、綁定事件、同步配置項函數(shù)執(zhí)行
綁定事件
由于此時控件的DOM和內(nèi)部的子控件已經(jīng)渲染完畢，則可以在子控件或者DOM上綁定事件。綁定事件的過程：
1.調(diào)用父類的綁定事件方法，包括原型鏈上的父類和mixins
2.調(diào)用插件（plugin）的綁定事件方式
注意：在子控件或者內(nèi)部DOM上綁定事件時，使用委托，不要直接在子控件或者DOM上綁定事件，一旦子控件添加或者刪除，內(nèi)部DOM變化都會引起事件失效。

同步配置項

首先說明一下什么叫做同步配置項，前面我們在初始化控件時，已經(jīng)對配置項做過一定的處理（至于如何處理，后面講 JS控件屬性 的時候會講到）,但是配置項并未作用到DOM上或者內(nèi)部子控件上。
為什么在這時候處理同步，而不是在創(chuàng)建DOM和渲染子控件時，有2個原因：
1.在創(chuàng)建DOM和渲染子控件時，所有的DOM和子控件并未完整生成此時同步需要進行大量判斷
2.我們需要把同步配置項的工作提取成方法，修改配置項時，內(nèi)部DOM和子控件跟著變化。

例如：配置項里有 { width : 100 }
1.如果我們在渲染DOM時同步，則可能把“width=100px；”直接設(shè)置到DOM上，而到我們需要修改這個width時，我們還需要寫一個函數(shù)來設(shè)置這個值。
2.反之，我們把同步配置項集中處理，將一個個的同步配置項的過程抽取成一個個函數(shù)，那么我們初始化 width的過程和修改width的過程完全一樣，這樣概念和邏輯就統(tǒng)一起來。
同步配置項的過程依然如其他步驟一樣：
1.調(diào)用父類的同步方法，包括原型鏈上的父類和mixins
2.調(diào)用插件（plugin）的同步方法
注意：我們應(yīng)該可以配置一個配置項是否在此時同步，原因有很多，比如多個配置項會產(chǎn)生同一操作，如果多個配置項同時同步，那么一個過程會反復(fù)執(zhí)行多次。
移除控件
任何對象都有構(gòu)造函數(shù)，必定也有析構(gòu)函數(shù)，但是這個函數(shù)往往是大家最容易忽視的地方，但是也是非常重要的地方，暫且不說內(nèi)存泄露之類的問題，就是如果一個控件的移除工作做得不夠好，會對正常的使用帶來很大的麻煩。
這個函數(shù)又是最不好寫的一個函數(shù)，因為它需要處理以下工作：
1.清理使用的其他控件，是否也移除看具體情形。區(qū)分 關(guān)聯(lián)和聚合
2.清理子控件
3.清理綁定到控件和DOM上的事件
4.移除DOM
5.清理變量的引用，這個比較麻煩和繁瑣，所以我們需要對控件的引用做統(tǒng)一的管理
同樣此函數(shù)也要執(zhí)行：
1.調(diào)用父類的析構(gòu)函數(shù)，包括原型鏈上的父類和mixins
2.調(diào)用插件的析構(gòu)函數(shù)

問題

上面講的全部是具體的步驟，但是在實現(xiàn)的時候遇到了一系列的問題：
1.調(diào)用父類的方法存在問題
1)調(diào)用原型鏈上的父類方法，只能使用 className.superclass.method.call(this)這類的方法，this.constructor.superclass.method.call(this)不能使用，原因在 js 控件繼承 的extend一章中有講到，這種調(diào)用方式繁瑣而且維護不方便。
2)調(diào)用mixins上的方法，在JS 繼承 mixins一章中我講到過mixins的實現(xiàn)原理，覆蓋同名方法，mixins的方法其實已經(jīng)作為控件的prototype上的方法，所以最好不要使用同名方法，如果多個mixins都是用 renderUI,synUI之類的方法，而繼承這些mixins的控件沒有實現(xiàn)renderUI這類方法，那么就會被覆蓋。
2.調(diào)用插件的方法也存在問題
1)我們需要獲得當前控件的引用

解決方式：

1. 針對調(diào)用父類的方法我們可以在控件渲染時，按照原型鏈的順序，先調(diào)用父類的方法再調(diào)用子類的方法直到當前控件：


如上面的繼承關(guān)系，我們執(zhí)行C.renderUI()時，按照繼承原型鏈的頂層向下執(zhí)行。
2. 執(zhí)行minxins的方法，我們執(zhí)行renderUI時，去依次執(zhí)行 mixin 的__renderUI方法。
3. 執(zhí)行父類的renderUI 時，如果也存在mixins那么執(zhí)行mixin的 __renderUI方法。

圖3

如上圖所示： inherits表示原型鏈繼承，extends表示 mixin擴展
那么c.renderUI的執(zhí)行過程如下：

A.renderUI ->D.__renderUI->B.renderUI->E.__renderUI->C.renderUI
3. 調(diào)用插件方法時需要傳遞控件本身的引用即可，如：
plugin1.render(this)
4. 析構(gòu)函數(shù) destructor比較特使，執(zhí)行的順序跟上面2中講的順序有所不同：
子類 destructor -> 子類擴展 destructor -> 父類 destructor -> 父類擴展 destructor
按照圖3的繼承結(jié)構(gòu)其析構(gòu)函數(shù)執(zhí)行的順序是：
C. destructor ->E.__destructor->B.destructor->E.__destructor->a.destructor
原因是，子類的一些引用依賴于父類或者擴展類，如果父類和擴展類先執(zhí)行析構(gòu)函數(shù)，那么子類在使用某些變量/屬性時會報錯。

這一節(jié)我把控件的生命周期講了一遍，所有的著一些都是來自于 KISSY框架的UIBase,感興趣的可以去看一下，非常精彩的實現(xiàn)http://docs.kissyui.com/kissy/docs/#!/api/KISSY.Component.UIBase的

最新評論