??上篇???(?????)我們通過定制了CPU和內存展示界面，體驗了??HT for Web??通過定義矢量實現圖形繪制與業務數據的代碼解耦及綁定聯動，這類案例后續文章還會繼續以便大家掌握更多的矢量應用場景，本篇我們先切換個話題，談談模型-視圖-事件之間的關系。
????
圖形組件設計架構上主要就是在規劃Data模型，View視圖和Event事件之間的關系，這些年業界逐漸將各種GUI設計模式提煉成理論歸類，MVC、MVP和MVVM的主要大類常被統稱為MV*，有很多文章進行各種設計模式的定義和比較，本篇不打算深入展開理論的討論，不同圖形組件設計架構都會有很多差異，持續發展的組件其實每時每刻都在進行著各種設計上的改進，相信有很多不錯的組件已經創新出了更多新的更實用的設計模型，只不過還未被提煉到理論高度進行歸類讓世人知曉，因此過細去定義什么是P，什么是VM，哪個功能應該寫在哪個部分才算合理我覺得是沒太大意義的，只要不斷改進產品，團隊能更好維護擴展，用戶易學易用就夠了，理論高度留給?? ??這類神級大師去定義。
提到?? ???因為他的《??GUI ???》和《?? Model???》是我較早見到將MVC和MVP理清的文章，從實現角度其實幾十年前蘋果用于開發Mac OS X的??Cocoa ???技術已采用了類似的設計，并且-C語言的Key-Value 和Key-Value 機制，加上XCode工具的可視化支持，可以說多年來早已讓眾多開發者不知不覺在享受這些設計模型能帶來的開發力。Java的Swing界面一直飽受詬病，但其實很早就有?????這樣優秀項目，Swing本就不算大眾，了解更是小眾，而更少人了解?? ???這多年前就實現得非常不錯的MVP架構封裝，有興趣的讀者可看看這篇06年的??PPT《 and Data 》??。
Adobe的Flex和微軟的/WPF本被業界寄予厚望，沒想這哥倆如匆匆過客被老東家拋棄了，但他們還是推動了MVP和MVVM設計模式的普及，如今HTML5領域的、.js、、、Ember.js等眾多MV*框架如果雨后春筍般崛起，甚至需要有人專門維護個????的網站來： you an MV* ！
??HT???本身也是一套MV*的框架，但我們培訓客戶時很少過細討論設計模式，在我看來好的組件封裝應該不必讓用戶糾結于你的設計模式，用戶幾個月不用你的框架后，依然能快速上手不必有一個重寫學習的過程，這是我們最求的理想框架，從這個角度說目前很少有圖形框架能讓我們滿意，相信很多人有類似痛苦的經歷，一段時間不用某套框架后，要用時完全忘記如何入手，Swing老手不看老代碼不知如何對JTree和添加數據，Flex老手一下子想不起來，和 t這幾個自定義組件必掌握函數的細節熱詞可視化分析工具，SL/WPF老手想不起來定義一個屬性除了和還有多少要考慮的因素，上段提到的一堆新興的HTML5界MV*框架，相信更少有人敢說熟練精通，你可能在某個項目中用了好幾個月甚至一兩年，但一段時間不用你很容易忘記，因此對喊出精通缺乏勇氣了，我覺得這不是大家不聰明不勤奮，而是目前的這些框架真還沒做到足夠好，我們一直努力讓??HT???朝我們覺得滿意的方向發展，以后文章我再展開討論??HT??如何設計讓用戶不健忘的API接口。
回到今天模型-視圖-事件的話題，Data和View分離后必然需要有Event事件的監聽和派發機制來建立起數據綁定，我控制欲比較強不是很喜歡那種dirty 的機制，有事件變化我希望馬上被通知到，做我該做的處理，至于有人擔心性能問題那是多慮了，圖形組件發展這么多年已積累無數成熟技巧來規避事件的性能問題。
性能問題倒不用擔心，畢竟這方面任務大部分情況都是交由框架實現者去考慮，但不需要用戶深入了解框架的實現細節，并不意味著用戶可以完全不關系基本架構脈絡，框架應用者還是有必要了解模型-視圖-事件之間的引用關聯關系，否則容易出現內存泄露的問題，以前經歷過一個客戶團隊設計的客戶端框架，可管理所有界面的窗口，結果出現總是OOM的內存溢出，幫他們檢查后發現，他們有個全局的對象，在每個窗口創建時都會添加對窗口的引用，這樣固然貌似很強大，全局都可以控制所有界面窗口，但因為絕大多數開發人員，不會在窗口關閉要銷毀時主動去刪除全局對象的引用，進而導致了所有窗口都能被全局對象引用到而無法垃圾回收，因此框架的使用者還是有必要多框架的機制有所了解才能避免這類的內存泄露問題。
很多情況下內存泄露不是長期的運行也很難發覺，但對于??HT??的這種基于WebGL的3D組件問題尤為明顯，因為大部分瀏覽器對單個頁面能運行的WebGL上下文是有限制的，例如PC上的或也就運行十五六個，手機平板等移動終端會更受限，因此如果出現內存泄露老的上下文沒關閉，超越上限時就會出現類型”Too many WebGL . will be lost.”的異常。
以下我對《HT入門手冊》的第一個例子做個擴展，對工具條增加了如下代碼邏輯的三個按鈕，第一個按鈕一下子創建了20個新的Tab頁，每個Tab頁包含一個組件，另外兩個按鈕實現刪除部分頁簽的功能。
{
label: 'Create 20',
action: function(){
for(var i=0;i<20;i++){
var tab = new ht.Tab();
tab.setName('tab-'+i);
tab.setClosable(true);
tabView.getTabModel().add(tab);
var g3d = new ht.graph3d.Graph3dView(dataModel);
g3d.name = 'g3d-' + i;
window['g3d-' + i] = g3d;
tab.setView(g3d);
}
}
},
{
label: 'Destroy 5',
action: function(){
var emptyModel = new ht.DataModel();
tabView.remove('tab-5');
window['g3d-5'].setDataModel(emptyModel);
delete window['g3d-5'];
this.disabled = true;
}
},
{
label: 'Destroy 6-10',
action: function(){
for(var i=6; i<=10; i++){
tabView.remove('tab-' + i);
var emptyModel = new ht.DataModel();
window['g3d-' + i].setDataModel(emptyModel);
delete window['g3d-' + i];
}
this.disabled = true;
}
}
點擊創建20個頁簽的按鈕分別打開頁簽之后系統的內存對象引用關系如下圖所示：
??
??
因為作為全局對象被應用著，而且其他新創建的頁簽中的都綁定了該數據模型，框架使用者應該了解，各種組件都對數據模型添加了事件監聽，其實數據模型并不知道各種View的存在，數據模型僅遵循有數據變化后將事件正確的派發給所有消費者，而這20個就是其中的消費者，而中每個有都有一個WebGL的上下文，因而形成了一條從全局到數據模型，再到組件，最后到WebGL上下文的引用關系網，這樣自然如果我們不主動斷開這個關系，哪怕Tab頁簽被關閉銷毀熱詞可視化分析工具，依然還會存在系統內存的問題（這個例子我們為了測試方便其實還在上直接引用了Tab和對象）。
??
???
因此由??以上視頻??你會發現在下當點擊到第16個包含的頁簽后就出現了”Too many WebGL . will be lost.”的異常，在WebGL中可通過對添加的事件監聽可判斷自己的上下文被銷毀了，并可通過添加的事件監聽在瀏覽器資源足夠時重新進行恢復。
在我們這個案例中要讓系統資源恢復，我們必須讓過多的Tab頁簽中的被徹底回收，因此工具條上的另外兩個按鈕從代碼邏輯可知，我們將設置了一個新的空得數據模型，使其斷開了和全局.的引用，當然Tab頁簽也得刪除，從??以上視頻??中也可以看得出當我們銷毀了部分Tab頁簽后就能得到的事件恢復，因此第一個”HT for 3D Web”的頁簽經歷了和的過程。
啟動初始化時只有”HT for 3D Web”的第一個頁簽，因此通過的Debug 可查看到ht..的 Count項只有1，通過的我們還可以清楚的掌握目前達到那些對象引用了對象：
??
??
當點擊構建20個頁簽按鈕后，能看到 Count為21：
??
??
當我們點擊兩個刪除按鈕銷毀6個Tab頁簽后發現， Count下降到了15：
??
??
最后可以發現第一個HT for 3D Web的頁簽浴火重生了
??
??
這個案例只是為了測試方便因此將對象作為全局變量，所以引發了一些列內存泄露的資源不足問題，一般項目應用中不用的組件不需要考慮這么復雜，例如還需要斷開引用這些步驟，常規應用場景中例如一個對話框打開后，一般數據模型和視圖組件都在這個對話框范圍內相互引用，只要確保不出現上文提到的有全局引用能影響這個對話框內的某個對象，那么你在使用完該對話框后不需要做任何處理，那一堆的對象哪怕他們之間引用再復雜甚至互相應用，反正沒有全局對象能夠再引用到他們，他們統統都會被銷毀。
????
總結下本篇的兩個觀點：
1、再好的封裝設計也需要使用者掌握基本的架構脈絡，就像再好的車你也得學會開學會基本的保養，什么都不學的話，再好的框架也會像好車一樣被你開壞
2、不要懼怕MV*的事件和引用關系，理清事件機制和對象引用關系后，你可以精確掌控任何時刻的任何內部細節，這點主要針對設計框架者而言，使用者應該大膽的擁抱MV*的框架，性能和各種潛在的內存問題放心的交給框架去解決