TWaver - 專注UI技術(shù)

作為一名TWaver Evangelist，我的工作目的就是通過與客戶的交流、培訓(xùn)甚至現(xiàn)場支持等方式幫助用戶將TWaver更好地應(yīng)用到客戶項(xiàng)目中，TWaver是這么一款橫跨Java、Web、Flex和.NET等多種技術(shù)平臺(tái)的GUI圖形組件，因此我的工作內(nèi)容簡單的說就是：幫助客戶正確使用GUI。

提到GUI線程安全，這是我最想談也最不想談的話題，想談因?yàn)榇藛栴}不說明白，用戶不清楚項(xiàng)目架構(gòu)設(shè)計(jì)之初GUI最需要考慮的問題，往往后期集成測試上線時(shí)會(huì)出現(xiàn)災(zāi)難性的后果；不想談因?yàn)檫@個(gè)話題太大了，從UI單線程的基本事件派發(fā)原理，到Swing、SWT、Flex、Silverlight、WPF甚至是Swing in EclipseRCP，Silverlight in windowsFroms，Applet in MFC等這種“雜交”的情況，這個(gè)話題一展開沒有幾個(gè)小時(shí)剎不住車，甚至需要陷入幫Sun、Adobe、MS向客戶解釋為什么Swing和Silverlight不能設(shè)計(jì)成線程安全，F(xiàn)lex和JavaScript為什么不提供線程的問題。

anyway，我桌面已擺著一塊大面包，一大杯濃茶（我哥常鄙視我這樣的喝法糟蹋了好茶葉），希望能有精力一口氣把這該死的問題一次性的解釋透徹。

總得來說目前幾乎所有主流的GUI技術(shù)采用的都是Single UI Thread的實(shí)現(xiàn)方式，簡單說你操作任何組件都必須在那個(gè)唯一的UI Thread里面進(jìn)行，否則就會(huì)出錯(cuò)，這里指的也不僅僅是UI組件，大部分時(shí)候我們所指的是綁定UI組件的Model部分，因?yàn)榇蟛糠諫UI技術(shù)無論是Swing/SWT的MVC，或Flex和TWaver那樣的MVP，或微軟在WPF和Silverlight中采用的MVP的變異MVVM，這些事件機(jī)制最終會(huì)導(dǎo)致你對(duì)Model層的修改實(shí)則間接的也是修改了UI組件，因此在非UI Thread的所有任何其他thread地方你絕對(duì)不能碰UI組件已經(jīng)其所綁定的Model。

用TWaver的話說：你操作network,tree,table,sheet,list,chart包括已經(jīng)綁定這些view的databox、element、selectionmodel、alarm、alarmmodel等都必須確保代碼運(yùn)行在UI Thead中。這里有個(gè)地方需要注意我指的是已經(jīng)綁定了View的模型，由于TWaver的DataBox是可以用xml的文本和Serializable的二進(jìn)制兩種方式進(jìn)行序列化，因此很多用戶會(huì)把twaver的databox數(shù)據(jù)構(gòu)建放在后臺(tái)進(jìn)行，包括TWaver Web整個(gè)模型是在J2EE后臺(tái)容器操作，這種情況下你只要保證單線程操作即可，并不要求這個(gè)線程必須是UI Thread，因?yàn)槟氵€沒有綁定View因此沒有UI Thread線程安全的限制。

有些人問為什么要有這些限制，為什么TWaver不能設(shè)計(jì)成現(xiàn)場安全的，其實(shí)我們的回答和Sun(現(xiàn)在的Oracle)的解釋是一致的Why did we implement Swing this way?，同樣你也可以找到Why did we implement SWT,Flex,WindowsForms,Silverlight,WPF….this way的類似解釋的文章，并不是我們逃脫責(zé)任將痛苦留給客戶，而是因?yàn)槲覀冋J(rèn)為多線程的GUI框架非常困難，更不利于用戶的開發(fā)調(diào)試，甚至由于需要進(jìn)行的各種同步保護(hù)反而降低了整體GUI交互效果。

簡單說一個(gè)存著number元素的list讓你求sum，如果有多線程并發(fā)在你for循環(huán)的時(shí)候動(dòng)態(tài)修改你怎么辦，你會(huì)說加上lock鎖定這個(gè)list不就得了，如果這個(gè)list非常長需要運(yùn)行很長時(shí)間那豈不其他人都被你堵住了，你會(huì)想的想java.util.concurrent的實(shí)現(xiàn)那樣分成更多的塊來操作，老大你看看ConcurrentHashMap的一千多行代碼才僅僅解決了map問題，你還會(huì)說看看微軟C#4的強(qiáng)大的并行處理Parallel.ForEach函數(shù)，即使是這個(gè)也僅僅解決了無狀態(tài)和沒有太多耦合邏輯的運(yùn)算分解，對(duì)于復(fù)雜的GUI耦合邏輯目前還沒有靈丹妙藥，Parallel.ForEach也是需要讓你修改代碼的，現(xiàn)在的本子動(dòng)不動(dòng)就配上4個(gè)8個(gè)CPU，但跑在上面的GUI程序性能不會(huì)比當(dāng)CPU的強(qiáng)，因?yàn)樾枰狦UI密集運(yùn)算工作時(shí)依然只有一個(gè)CPU在工作。

這些年并行計(jì)算呼聲很高，google這樣的巨人已經(jīng)讓我們老百姓感受到了并行計(jì)算的優(yōu)勢，但回到GUI我們依然無法輕松、廉價(jià)和透明的體驗(yàn)到并行的好處，也許有那么一天會(huì)到來，但目前階段我并不渴望，以目前的語言類庫基礎(chǔ)如果采用并發(fā)的方式只會(huì)讓我們的調(diào)試開發(fā)更痛苦，當(dāng)然最重要的是現(xiàn)在的主要瓶頸已經(jīng)不是GUI的組件了，而是數(shù)據(jù)DATA，從海量的數(shù)據(jù)中查詢獲取到你需要的DATA這個(gè)過程才是瓶頸，良好的GUI框架設(shè)計(jì)不應(yīng)該將數(shù)據(jù)的獲取與界面的呈現(xiàn)耦合得不可分離，就像TWaver可以秒級(jí)的加載萬甚至10萬以上的圖元，但最大的瓶頸是用戶如何更短的時(shí)間去獲取和傳輸這些數(shù)據(jù)。

再看看現(xiàn)在熱賣得脫銷iphone4（一萬多甚至最高兩萬二的天價(jià)讓我想起當(dāng)年的大哥大時(shí)代）和IPad，對(duì)應(yīng)這樣的硬件配置用于瀏覽網(wǎng)頁，受發(fā)郵件，聽歌看碟，玩玩小游戲已經(jīng)搓搓有余了，大家抱怨的是信號(hào)門，抱怨的是不堪重負(fù)的AT&T網(wǎng)絡(luò)，題外話Cocoa同樣也不是線程安全的哦：

There may be perceived performance advantages that accrue from using multiple threads with Core Data. In particular, if you execute a large or complex fetch that takes some time, you might execute the full fetch on a background thread. It is important to consider, however, that most of the Application Kit is not thread safe and that you need to take considerable care that object graphs do not get into an inconsistent state.For the most part, the Application Kit is not thread safe; in particular, Cocoa bindings and controllers are not thread safe

因此現(xiàn)階段我們唯一能做的就是老老實(shí)實(shí)遵守Single UI Thread設(shè)計(jì)帶來的限制，這個(gè)Thread有很多叫法，在Swing里面稱之為EDT(Event Dispatcher Thread)，以下的文章中我們都會(huì)簡稱之EDT。