UI是User　Interface的縮寫，通常被認(rèn)為是MVC中View的部分，作用是提供跟人機(jī)交互的可視化操作界面。MVC中Model提供內(nèi)容給UI進(jìn)行渲染，用戶通過UI框架產(chǎn)生響應(yīng)，一般而言會(huì)由控制層調(diào)用業(yè)務(wù)邏輯進(jìn)行處理，并把處理結(jié)果以Model方式返回View，再次渲染。UI框架的大致過程就是如此，按實(shí)現(xiàn)方式可以分為RIA和瘦客戶端方式，目前基于B/S的瘦客戶端方式比較流行。
UI框架套路上很簡(jiǎn)單，但是想要做好可就不容易了。目前基于MVC的框架燦若繁星，不客氣的說是個(gè)軟件公司就有自己的技術(shù)框架，技術(shù)厲害的公司可能還有幾套。筆者也經(jīng)歷過多家互聯(lián)網(wǎng)公司，也用過不少框架，界面開發(fā)始終是短板所在。

一、新UI框架的需求由來

1. 場(chǎng)景A
UI框架對(duì)View層沒有封裝或者支持有限。View層的代碼全部需要開發(fā)人員手動(dòng)完成，框架沒有提供代碼封裝或者相關(guān)代碼生成工具，導(dǎo)致項(xiàng)目開發(fā)流程中，出現(xiàn)大量Ctrl+C、Crtl+V，進(jìn)而影響界面代碼質(zhì)量。
筆者曾和IT業(yè)界比較有名的外包公司合作過項(xiàng)目，一個(gè)JSP頁面四、五千行代碼，Java業(yè)務(wù)邏輯、html布局和css樣式糅合在一起，不要說修改了，就是看明白頁面也是異常艱難。跟開發(fā)人員溝通了解到，團(tuán)隊(duì)采用界面實(shí)現(xiàn)方式是jsp，框架提供的樣式不滿足客戶需求，迫使團(tuán)隊(duì)自行開發(fā)很多框架層面的功能。經(jīng)常一個(gè)需求變動(dòng)，導(dǎo)致開發(fā)人員修改十幾處地方，頁面的混亂就可想而知了。

2. 場(chǎng)景B
技術(shù)框架分層嚴(yán)格，界面完全組件化。View層和Model層完全分離，開發(fā)人員編寫頁面需要額外學(xué)習(xí)組件，訪問后臺(tái)成本巨大，很多業(yè)務(wù)需求需要通過框架升級(jí)方式才能解決，時(shí)間浪費(fèi)嚴(yán)重。
這是從一個(gè)極端走到另一個(gè)極端，以嚴(yán)格的框架徹底限制死開發(fā)人員。筆者參與過的銀行項(xiàng)目，就是采用這種方式：開發(fā)人員寫的頁面全是組件模板，無法靈活定義一些功能，導(dǎo)致全部業(yè)務(wù)需求完全通過組件體現(xiàn)，而且開發(fā)人員本身無法修改組件，組件存在Bug或者無法實(shí)現(xiàn)某些業(yè)務(wù)場(chǎng)景，那開發(fā)人員還要在組件團(tuán)隊(duì)、項(xiàng)目領(lǐng)導(dǎo)之間扯皮，搞得所有人身心俱疲。

3. 場(chǎng)景C
框架性能問題。框架設(shè)計(jì)人員追求華麗的頁面效果，完美的層次封裝就容易導(dǎo)致這種后果，特別是在頁面復(fù)雜或者頁面嵌套多時(shí)，很容易發(fā)生這種問題。
開發(fā)人員最怕遇到這種問題，這意味著項(xiàng)目要傷筋動(dòng)骨。還以銀行項(xiàng)目做例子：原先框架版本是3.0，業(yè)務(wù)領(lǐng)導(dǎo)認(rèn)為界面太土，不美觀，經(jīng)過框架團(tuán)隊(duì)一年多的努力，框架4.0對(duì)界面做了大幅度的美化處理，提供了復(fù)雜的封裝，結(jié)果造成嚴(yán)重的性能問題。因?yàn)殂y行項(xiàng)目頁面復(fù)雜，有些表單要展示幾百個(gè)字段，用框架4.0開發(fā)后要10多秒，根本無法被接受。最后這一系列的代價(jià)由開發(fā)人員買單，用html原生語法重新開發(fā)這個(gè)復(fù)雜頁面。

4. 場(chǎng)景D
升級(jí)維護(hù)問題。有些框架設(shè)計(jì)時(shí)，設(shè)計(jì)人員迫于團(tuán)隊(duì)或者領(lǐng)導(dǎo)壓力，框架集合太多業(yè)務(wù)邏輯，導(dǎo)致后期團(tuán)隊(duì)面臨兩難選擇：不升級(jí)，Bug無法解決；升級(jí)界面產(chǎn)生各種問題，需要花費(fèi)大量精力去糾正。
這種場(chǎng)景也不少見，特別是框架包含多個(gè)項(xiàng)目的業(yè)務(wù)需求時(shí)，沖突由為明顯，筆者經(jīng)歷過一個(gè)項(xiàng)目：每次升級(jí)，代碼需要對(duì)比幾百處，浪費(fèi)2-3天的時(shí)間，就這樣還不能保證完全正確；最可怕的是，每次升級(jí)都要如此。

歸納一下，對(duì)UI框架有如下需求：
1.提升開發(fā)效率，減少重復(fù)代碼。對(duì)于開發(fā)人員而言，開發(fā)時(shí)，界面寫得代碼越短越好；維護(hù)時(shí)，修改的地方越少越好。
2.清楚的UI層次，框架可以分離業(yè)務(wù)邏輯、布局和樣式，讓頁面結(jié)構(gòu)清晰明了，讓開發(fā)人員集中更多精力在業(yè)務(wù)邏輯，而不是頁面布局、js、css等技術(shù)細(xì)節(jié)。
3.豐富的組件支持，項(xiàng)目團(tuán)隊(duì)大部分業(yè)務(wù)場(chǎng)景應(yīng)該可以被框架組件涵蓋，而無需重新開發(fā)。
4.靈活的擴(kuò)展能力，項(xiàng)目團(tuán)隊(duì)可以根據(jù)框架規(guī)范自行擴(kuò)展展示組件，實(shí)現(xiàn)個(gè)性化需求。
5.優(yōu)異的性能，UI界面展示時(shí)的響應(yīng)時(shí)間應(yīng)該和原生態(tài)語言接近。框架能處理JS、CSS加載及合并的問題。
6.框架升級(jí)不影響業(yè)務(wù)代碼。

只有滿足上述要求的UI框架，對(duì)開發(fā)人員和項(xiàng)目團(tuán)隊(duì)才是真正有幫助的UI框架。

二、TinyUI的解決方案

 
Tiny團(tuán)隊(duì)對(duì)UI框架也有自己的想法，也提出一種UI框架解決方案。TinyUI采用如下設(shè)計(jì)原則，項(xiàng)目團(tuán)隊(duì)在技術(shù)選型時(shí)需要考慮清楚。

TinyUI的原則
1.保證界面開發(fā)的靈活性，尊重開發(fā)人員的開發(fā)權(quán)利。
Tiny團(tuán)隊(duì)遵守“二八”原則，認(rèn)為再完美的UI框架也只能解決80%實(shí)際開發(fā)過程中遇到的界面問題，剩下的20%需要開發(fā)人員的經(jīng)驗(yàn)和智慧才能解決。那種提倡一攬子解決全部界面開發(fā)問題的UI框架，只會(huì)讓設(shè)計(jì)者陷入過多技術(shù)細(xì)節(jié)，導(dǎo)致過度設(shè)計(jì)。因此，TinyUI提供最大程度的靈活：只要遵守必要的框架規(guī)范，開發(fā)人員可以自由擴(kuò)展組件，來滿足日益變化的業(yè)務(wù)需求。
2.技術(shù)問題與業(yè)務(wù)邏輯分離。
TinyUI采用開源協(xié)議，作為開源軟件來提供UI框架，代碼本身不包含任何業(yè)務(wù)邏輯。避免框架設(shè)計(jì)者開發(fā)業(yè)務(wù)組件，業(yè)務(wù)團(tuán)隊(duì)使用的模式。技術(shù)問題由設(shè)計(jì)者解決，而業(yè)務(wù)邏輯由業(yè)務(wù)團(tuán)隊(duì)根據(jù)自身業(yè)務(wù)靈活定制、擴(kuò)展。
3.性能至上，效率優(yōu)先。
TinyUI在設(shè)計(jì)初期就考慮組件性能問題，目標(biāo)是接近原生態(tài)頁面；其次，UI框架完全開源，開發(fā)人員只要熟悉模板語言，就可以輕松上手，避免因?yàn)閷W(xué)習(xí)曲線過高影響開發(fā)效率。
在上述原則的指定下，TinyUI具有如下特性：

特性
1.TinyUI是基于JQueryUI，相較于Dojo來說，JQueryUI更容易上手，使用也更簡(jiǎn)單；相對(duì)于ExtUI來說，它更輕量，速度響應(yīng)也更好；同時(shí)它也是可胖可瘦，即可以實(shí)現(xiàn)比較大的控件，也可以用少量代碼就使得界面更加靈動(dòng)。
2.布局與界面分離。TinyUI引入模板引擎，頁面采用模板+組件的方式進(jìn)行渲染，可以大幅簡(jiǎn)化頁面。
3.采用了多重布局方式，每一級(jí)目錄當(dāng)中都可以編寫一個(gè)布局。項(xiàng)目經(jīng)理可以根據(jù)業(yè)務(wù)需求按不同層級(jí)定義不同的布局。
4.采用了pagelet方式，可以把頁面區(qū)塊獨(dú)立提供或者被別的頁面進(jìn)行引用。
5.提供了UI組件模式，用戶可以方便的編寫UI組件，并發(fā)布到應(yīng)用當(dāng)中，同時(shí)提供了資源加載機(jī)制，如果UI組件包含有JS或CSS文件，不用特別指定，也不用進(jìn)行首頁合并，可直接被使用。
6.提供了BigPipe機(jī)制，可以大大提供模板的處理速度及提升用戶界面的使用體驗(yàn)。
7.通過組件方式開發(fā)界面，封裝了組件的實(shí)現(xiàn)細(xì)節(jié)，可以平滑切換到其它實(shí)現(xiàn)。
8.與各種開源組件或代碼段集成更容易，利用一個(gè)已經(jīng)實(shí)現(xiàn)的開源組件封裝成UI組件，只要幾分鐘。接口的擴(kuò)展可以循序漸進(jìn)，隨用隨包裝。
9.資源自發(fā)現(xiàn)。框架會(huì)自行加載新增加的組件，所有的css/js文件都會(huì)自動(dòng)進(jìn)行添加。

TinyUI實(shí)際上并不是一個(gè)具體的UI展現(xiàn)組件，它只是一個(gè)UI構(gòu)建體系。它可以適應(yīng)于各種Html+CSS+JS的體系架構(gòu)中，提供以UI方式開發(fā)界面的技術(shù)方案。

組件規(guī)范
TinyUI認(rèn)為界面所有公用的內(nèi)容都可以由UI組件包(UIComponents)概括。UI組件包包括一個(gè)或者多個(gè)組件(UIComponent)，UI組件包中包含了其所需的css/js/gif/htm等等各種資源。同時(shí)有一個(gè)UI組件包描述文件(*.ui.xml)，描述對(duì)UI組件包的結(jié)構(gòu)、內(nèi)容、以及對(duì)其它UI組件包的依賴關(guān)系。
開發(fā)時(shí)，UI組件包以獨(dú)立的maven工程為單位，最后以Jar包為單位進(jìn)行發(fā)布。
舉例：我們要復(fù)用JQuery，實(shí)際上非常簡(jiǎn)單。在Maven工程結(jié)構(gòu)中，在resources目錄中，放置所有的JQuery資源進(jìn)來，然后編寫一個(gè)ui組件包描述文件。UI組件包就算開發(fā)完畢了。

TinyUI框架的組件管理器會(huì)根據(jù)包描述文件自動(dòng)加載、引入相關(guān)資源，而這些都無需程序人員干預(yù)。

頁面規(guī)范
TinyUI推薦采用模板語言,如：tinyTemplate,FreeMaker等作為展現(xiàn)層，這樣可以充分發(fā)揮組件包的優(yōu)勢(shì)。Tiny內(nèi)部實(shí)現(xiàn)復(fù)用了tinyTemplate模板語言，但是實(shí)際上并沒有限制，你完全可以用其它模板語言做同樣的事情。

具體頁面開發(fā)時(shí)，組件開發(fā)人員采用宏定義具體的函數(shù)接口，普通開發(fā)人員直接調(diào)用宏接口就可以了。
 
舉例：

 這樣寫頁面多簡(jiǎn)單，采用Tiny框架的前臺(tái)開發(fā)，基本上幫助你解決了上述難題，但是對(duì)你的工作沒有任何限制。

小貼士
Dojo簡(jiǎn)介：
Dojo是一個(gè)用javascript語言實(shí)現(xiàn)的開源DHTML工具包。利用它的低級(jí)API和可兼容的代碼，能夠?qū)懗鲚p便的、單一風(fēng)格（復(fù)雜）的JavaScript代碼，它能提升你的web應(yīng)用程序可用性、交互能力以及功能上的提高。

ExtUI簡(jiǎn)介：
它是一種主要用于創(chuàng)建前端用戶界面，是一個(gè)基本與后臺(tái)技術(shù)無關(guān)的前端ajax框架。組件豐富，功能強(qiáng)大，可惜現(xiàn)在收費(fèi)了。

三、TinyUI的設(shè)計(jì)思路

常見問題
1.UI中JS的引入與順序，JS合并的問題 。
2.UI中css的引入與順序，CSS合并的問題 。
3.重復(fù)代碼的問題。同樣的內(nèi)容在許多地方都有，如果要改動(dòng)就要改動(dòng)許多個(gè)地方，修改時(shí)萬一遺留了，將來就是一個(gè)坑。
4.整體布局調(diào)整困難的問題。
5.開發(fā)效率的問題，項(xiàng)目經(jīng)理總是期望界面開發(fā)越快越好。
6.執(zhí)行效率的問題，前臺(tái)響應(yīng)要求速度更快。
7.國(guó)際化問題。

     ......
 
 下面，筆者依次講解TinyUI是如何處理上述問題：

Js和Css的引入與順序以及合并的問題

1.JS和CSS的引入問題。
傳統(tǒng)界面開發(fā)，程序員需要在頁面配置引入js和css的路徑，既麻煩又容易出錯(cuò)。TinyUI采用組件封裝了JS和CSS，這份工作統(tǒng)一交給組件設(shè)計(jì)者處理，程序員開發(fā)頁面時(shí)根本不用關(guān)心需要引入哪些JS和CSS，只要知道要用哪些宏接口就行了。
2.JS和CSS的順序問題。
這個(gè)問題也是傳統(tǒng)界面開發(fā)之間的難點(diǎn)，JS和CSS之間的順序搞錯(cuò)，通常會(huì)導(dǎo)致頁面出現(xiàn)亂七八糟的問題，定位問題也是異常復(fù)雜。TinyUI將順序問題交給組件管理器處理，它會(huì)依次檢查組件的依賴關(guān)系，如果有UI組件的依賴關(guān)系配置錯(cuò)誤，組件管理器會(huì)記錄異常日志，這些不正常組件不會(huì)被加載到正常組件列表。組件間的依賴關(guān)系理順后，組件內(nèi)部包含的JS和CSS的關(guān)系也就理順了。TinyUI按如下順序加載JS和CSS：
a.  父組件的資源比子組件優(yōu)先加載。比如組件A依賴組件B，那么框架先加載組件B資源，再加載組件A資源。
b. 同一組件的資源，順序靠前的優(yōu)先加載。組件的js和css路徑都可以配置多個(gè)，同一組件框架按配置順序依次加載資源。
3.JS和CSS的合并問題。
在傳統(tǒng)界面開發(fā)，性能調(diào)優(yōu)往往涉及到j(luò)s和css的合并，頁面的IO少了，性能自然能提高，但是對(duì)程序員來說這就很困難，改動(dòng)js和css意味著很多相關(guān)頁面都要修改。TinyUI從框架層面支持js和css的合并，程序員無需手工調(diào)整，框架提供了UiEngineTinyProcessor這個(gè)適配器處理上述合并問題。

UiEngineTinyProcessor合并JS
 a. 適配器通過組件管理器獲得全部正常的UI組件，并依次遍歷每個(gè)組件
 b. 調(diào)用組件的getComponentJsArray方法，獲得該組件引用的全部js路徑，并依次遍歷每個(gè)路徑
 c. 根據(jù)路徑通過VFS獲得js的內(nèi)容，合并到outputStream
 d. 合并完每個(gè)組件的引入JS內(nèi)容，最后合并該組件需要調(diào)用JS代碼

UiEngineTinyProcessor合并CSS
 a. 適配器通過組件管理器獲得全部正常的UI組件，并依次遍歷每個(gè)組件
 b. 調(diào)用組件的getComponentCssArray方法，獲得該組件引用的全部css路徑，并依次遍歷每個(gè)路徑
 c. 根據(jù)路徑通過VFS獲得css的內(nèi)容，合并到outputStream
 d. 合并完每個(gè)組件的引入css內(nèi)容，最后合并該組件需要調(diào)用CSS代碼
 
重復(fù)代碼的問題

仔細(xì)分析頁面重復(fù)代碼的由來，主要可以分為以下幾塊：
1.無用的資源引入。寫過頁面的人都知道，程序員最喜歡把一段段的js、css到處粘，而不分析是否有用，導(dǎo)致大量不必要的資源引入，降低頁面性能。TinyUI通過組件管理器管理資源，最終輸出到頁面的引用，絕對(duì)跟組件包的資源一致，只要組件設(shè)計(jì)者設(shè)計(jì)組件包時(shí)保證沒有引入無用的資源。
2.重復(fù)的業(yè)務(wù)邏輯。TinyUI采用模板語言渲染頁面，通過宏定義解決重復(fù)業(yè)務(wù)邏輯。因?yàn)楹晔强梢郧短缀甑模岳碚撋显購(gòu)?fù)雜的頁面都可以通過宏搞定，宏如果使用得當(dāng)，可以大幅度減少頁面代碼。
3.相同的功能片段。 有些業(yè)務(wù)場(chǎng)景需要引入統(tǒng)一功能片段，界面相同，TinyUI可以采用模板命令include完美處理這種場(chǎng)景。
 
整體布局調(diào)整困難的問題

傳統(tǒng)界面開發(fā)，頁面布局與邏輯代碼是混在一起的，特別是復(fù)雜頁面，調(diào)整起來自然困難。TinyUI的設(shè)計(jì)時(shí)一開始就將布局與頁面邏輯徹底分成兩個(gè)文件，當(dāng)然你要用TinyUI推薦的模板組織。

Tiny的模板體系組織方式如下：
?支持多層文件結(jié)構(gòu)
?布局文件統(tǒng)一用.layout擴(kuò)展名結(jié)尾
?頁面文件統(tǒng)一用.page擴(kuò)展名結(jié)構(gòu)
?只有.page文件可以被外部訪問，訪問方式有兩種.page或.pagelet
?訪問.pagelet，實(shí)際上相當(dāng)于訪問同名page，模板引擎只會(huì)做頁面渲染；訪問.page，模板引擎除了頁面渲染還要進(jìn)行布局渲染
 

也許有些人看到這里問：將一個(gè)文件內(nèi)容拆分成兩塊，還要定義兩者間的聯(lián)系，是不是太復(fù)雜了？其實(shí)一點(diǎn)也不復(fù)雜，用戶根本不需要定義布局文件和頁面文件的聯(lián)系，請(qǐng)參考以下規(guī)范設(shè)計(jì)你的頁面布局結(jié)構(gòu)：

查找布局文件規(guī)則
1.匹配當(dāng)前目錄同名的布局文件。
2.匹配當(dāng)前目錄默認(rèn)的布局文件。
3.若某一級(jí)目錄無法滿足匹配條件，則向該目錄上一級(jí)目錄進(jìn)行匹配，直到根目錄為止。
 
比如：aa.page所中的路徑是/a/b/c/aa.page，布局的渲染過程如下：

查找/a/b/c/aa.layout是否存在？如果存在，則渲染，否則查找/a/b/c/default.layout，如果存在，則渲染。

查找/a/b/aa.layout是否存在？如果存在，則渲染，否則查找/a/b/default.layout，如果存在，則渲染。

查找/a/aa.layout是否存在？如果存在，則渲染，否則查找/a/default.layout，如果存在，則渲染。

查找/aa.layout是否存在？如果存在，則渲染，否則查找/default.layout，如果存在，則渲染。

通過上面的渲染機(jī)制，程序員有可能只寫了非常少的內(nèi)容，但是通過分層布局渲染，最后出來的效果也會(huì)非常豐富多彩。

開發(fā)效率的問題
采用TinyUI框架對(duì)開發(fā)效率提升，至少有如下兩點(diǎn)：
1.重復(fù)代碼大幅減少，工作效率自然就提升了。
2.學(xué)習(xí)曲線降低。采用組件+模板的頁面開發(fā)模式，對(duì)普通開發(fā)人員基本可以屏蔽JS和CSS，這兩者的技能要求程度就可以大大降低；額外增加的學(xué)習(xí)成本是模板語言，對(duì)程序員而言，模板語言達(dá)到使用程度，一天足矣。
 
執(zhí)行效率的問題
TinyUI框架采用如下技術(shù)手段，加快頁面的訪問速度：
1.合并頁面的JS和CSS。通過減少網(wǎng)絡(luò)IO請(qǐng)求，特別是在原頁面涉及很多資源時(shí)，提速效果就會(huì)比較明顯。
2.緩沖功能。用戶可以設(shè)定哪些頁面進(jìn)行緩沖，緩沖多長(zhǎng)時(shí)間。
3.支持BigPipe方式渲染頁面。前文說過TinyUI框架支持將大頁面拆分成一個(gè)個(gè)pagelet，讓瀏覽器可以多線程同時(shí)渲染，從而提升性能。
 
普通的web頁面，一般來說是頁面生成，網(wǎng)絡(luò)傳輸，前面頁面渲染，這三部分的時(shí)間加起來就是操作人員從點(diǎn)擊鼠標(biāo)到最后看到頁面的時(shí)間。

舉例來說，一個(gè)頁面有主頁面框架，共有4個(gè)部分的內(nèi)容顯示。為了便于分析，簡(jiǎn)化一下模型，假設(shè)主頁面框架生成需要0.2S，4個(gè)部分的內(nèi)容生成各自需要0.2S，網(wǎng)絡(luò)傳輸與瀏覽器渲染也各計(jì)成0.2秒，這樣，在傳統(tǒng)的方式下，需要的時(shí)間就是0.2*5+0.2*5+0.2*5=3秒。

那么換成BigPipe方式，時(shí)間的執(zhí)行分布大概是如下圖：

所以換成BigPipe方式，時(shí)間大概就是1.4秒的樣子。節(jié)省的時(shí)間大概是50%強(qiáng)一點(diǎn)的樣子。

當(dāng)然，這個(gè)時(shí)間是在各自三段時(shí)間都是0.2秒的情況，實(shí)際運(yùn)行過程中，網(wǎng)絡(luò)傳輸?shù)臅r(shí)間在局域網(wǎng)中的時(shí)間會(huì)更快，后臺(tái)頁面的處理，也可以采用多線程處理的方式來進(jìn)行，這樣，后面頁面處理時(shí)間可以縮短到0.4S，網(wǎng)絡(luò)傳輸時(shí)間有0.2S也可以了。由于采用了BigPipe方式，在0.6S的時(shí)候，就可以看到最頁面框架，后面的時(shí)間就是一塊塊出來，當(dāng)后面出來的時(shí)間比較快的時(shí)候，給使用的感受就是在0.6S+界面就可以出來。這個(gè)與最初的3S，用戶體驗(yàn)上明顯是有天壤之別的。

國(guó)際化的問題
對(duì)于小項(xiàng)目而言，可能不關(guān)心這個(gè)問題。但是TinyUI好歹是技術(shù)框架，目標(biāo)是大型項(xiàng)目，如果不能支持國(guó)際化，那也說不過去。

TinyUI提供兩種國(guó)際化方案，任君選擇：
1.國(guó)際化資源標(biāo)簽。國(guó)際化資源就很容易理解了，工程添加國(guó)際化資源文件，頁面用國(guó)際化標(biāo)簽進(jìn)行引用即可。
2.國(guó)際化頁面。 國(guó)際化頁面是指訪問某頁面時(shí)，模板引擎會(huì)優(yōu)先使用與訪問者相同的語言的頁面文件進(jìn)行渲染。譬如：存在aa.page，aa.zh_CN.page，如果非zh_CN語言的人來訪問，渲染的是aa.page，zh_CN語言的人來訪問，渲染的是aa.zh_CN.page。