《開源框架那些事兒22》：UI框架設計實戰

UI是User　Interface的縮寫，一般被認爲是MVC中View的部分，做用是提供跟人機交互的可視化操做界面。MVC中Model提供內容給UI進行渲染，用戶經過UI框架產生響應，通常而言會由控制層調用業務邏輯進行處理，並把處理結果以Model方式返回View，再次渲染。UI框架的大體過程就是如此，按實現方式能夠分爲RIA和瘦客戶端方式，目前基於B/S的瘦客戶端方式比較流行。 UI框架套路上很簡單，可是想要作好可就不容易了。目前基於MVC的框架燦若繁星，不客氣的說是個軟件公司就有本身的技術框架，技術厲害的公司可能還有幾套。筆者也經歷過多家互聯網公司，也用過很多框架，界面開發始終是短板所在。

 

1、新UI框架的需求由來

1. 場景A UI框架對View層沒有封裝或者支持有限。View層的代碼所有須要開發人員手動完成，框架沒有提供代碼封裝或者相關代碼生成工具，致使項目開發流程中，出現大量Ctrl+C、Crtl+V，進而影響界面代碼質量。 筆者曾和IT業界比較有名的外包公司合做過項目，一個JSP頁面4、五千行代碼，Java業務邏輯、html佈局和css樣式糅合在一塊兒，不要說修改了，就是看明白頁面也是異常艱難。跟開發人員溝通了解到，團隊採用界面實現方式是jsp，框架提供的樣式不知足客戶需求，迫使團隊自行開發不少框架層面的功能。常常一個需求變更，致使開發人員修改十幾處地方，頁面的混亂就可想而知了。

2. 場景B 技術框架分層嚴格，界面徹底組件化。View層和Model層徹底分離，開發人員編寫頁面須要額外學習組件，訪問後臺成本巨大，不少業務需求須要經過框架升級方式才能解決，時間浪費嚴重。 這是從一個極端走到另外一個極端，以嚴格的框架完全限制死開發人員。筆者參與過的銀行項目，就是採用這種方式：開發人員寫的頁面全是組件模板，沒法靈活定義一些功能，致使所有業務需求徹底經過組件體現，並且開發人員自己沒法修改組件，組件存在Bug或者沒法實現某些業務場景，那開發人員還要在組件團隊、項目領導之間扯皮，搞得全部人身心俱疲。

3. 場景C 框架性能問題。框架設計人員追求華麗的頁面效果，完美的層次封裝就容易致使這種後果，特別是在頁面複雜或者頁面嵌套多時，很容易發生這種問題。 開發人員最怕遇到這種問題，這意味着項目要傷筋動骨。還以銀行項目作例子：原先框架版本是3.0，業務領導認爲界面太土，不美觀，通過框架團隊一年多的努力，框架4.0對界面作了大幅度的美化處理，提供了複雜的封裝，結果形成嚴重的性能問題。由於銀行項目頁面複雜，有些表單要展現幾百個字段，用框架4.0開發後要10多秒，根本沒法被接受。最後這一系列的代價由開發人員買單，用html原生語法從新開發這個複雜頁面。

4. 場景D 升級維護問題。有些框架設計時，設計人員迫於團隊或者領導壓力，框架集合太多業務邏輯，致使後期團隊面臨兩難選擇：不升級，Bug沒法解決；升級界面產生各類問題，須要花費大量精力去糾正。 這種場景也很多見，特別是框架包含多個項目的業務需求時，衝突由爲明顯，筆者經歷過一個項目：每次升級，代碼須要對比幾百處，浪費2-3天的時間，就這樣還不能保證徹底正確；最可怕的是，每次升級都要如此。

概括一下，對UI框架有以下需求： 1.提高開發效率，減小重複代碼。對於開發人員而言，開發時，界面寫得代碼越短越好；維護時，修改的地方越少越好。 2.清楚的UI層次，框架能夠分離業務邏輯、佈局和樣式，讓頁面結構清晰明瞭，讓開發人員集中更多精力在業務邏輯，而不是頁面佈局、js、css等技術細節。 3.豐富的組件支持，項目團隊大部分業務場景應該能夠被框架組件涵蓋，而無需從新開發。 4.靈活的擴展能力，項目團隊能夠根據框架規範自行擴展展現組件，實現個性化需求。 5.優異的性能，UI界面展現時的響應時間應該和原生態語言接近。框架能處理JS、CSS加載及合併的問題。 6.框架升級不影響業務代碼。

只有知足上述要求的UI框架，對開發人員和項目團隊纔是真正有幫助的UI框架。

 

2、TinyUI的解決方案

  Tiny團隊對UI框架也有本身的想法，也提出一種UI框架解決方案。TinyUI採用以下設計原則，項目團隊在技術選型時須要考慮清楚。

TinyUI的原則 1.保證界面開發的靈活性，尊重開發人員的開發權利。 Tiny團隊遵照「二八」原則，認爲再完美的UI框架也只能解決80%實際開發過程當中遇到的界面問題，剩下的20%須要開發人員的經驗和智慧才能解決。那種提倡一攬子解決所有界面開發問題的UI框架，只會讓設計者陷入過多技術細節，致使過分設計。所以，TinyUI提供最大程度的靈活：只要遵照必要的框架規範，開發人員能夠自由擴展組件，來知足日益變化的業務需求。 2.技術問題與業務邏輯分離。 TinyUI採用開源協議，做爲開源軟件來提供UI框架，代碼自己不包含任何業務邏輯。避免框架設計者開發業務組件，業務團隊使用的模式。技術問題由設計者解決，而業務邏輯由業務團隊根據自身業務靈活定製、擴展。 3.性能至上，效率優先。 TinyUI在設計初期就考慮組件性能問題，目標是接近原生態頁面；其次，UI框架徹底開源，開發人員只要熟悉模板語言，就能夠輕鬆上手，避免由於學習曲線太高影響開發效率。 在上述原則的指定下，TinyUI具備以下特性：

特性 1.TinyUI是基於JQueryUI，相較於Dojo來講，JQueryUI更容易上手，使用也更簡單；相對於ExtUI來講，它更輕量，速度響應也更好；同時它也是可胖可瘦，便可以實現比較大的控件，也能夠用少許代碼就使得界面更加靈動。 2.佈局與界面分離。TinyUI引入模板引擎，頁面採用模板+組件的方式進行渲染，能夠大幅簡化頁面。 3.採用了多重佈局方式，每一級目錄當中均可以編寫一個佈局。項目經理能夠根據業務需求按不一樣層級定義不一樣的佈局。 4.採用了pagelet方式，能夠把頁面區塊獨立提供或者被別的頁面進行引用。 5.提供了UI組件模式，用戶能夠方便的編寫UI組件，併發布到應用當中，同時提供了資源加載機制，若是UI組件包含有JS或CSS文件，不用特別指定，也不用進行首頁合併，可直接被使用。 6.提供了BigPipe機制，能夠大大提供模板的處理速度及提高用戶界面的使用體驗。 7.經過組件方式開發界面，封裝了組件的實現細節，能夠平滑切換到其它實現。 8.與各類開源組件或代碼段集成更容易，利用一個已經實現的開源組件封裝成UI組件，只要幾分鐘。接口的擴展能夠按部就班，隨用隨包裝。 9.資源自發現。框架會自行加載新增長的組件，全部的css/js文件都會自動進行添加。

TinyUI實際上並非一個具體的UI展示組件，它只是一個UI構建體系。它能夠適應於各類Html+CSS+JS的體系架構中，提供以UI方式開發界面的技術方案。

組件規範 TinyUI認爲界面全部公用的內容均可以由UI組件包(UIComponents)歸納。UI組件包包括一個或者多個組件(UIComponent)，UI組件包中包含了其所需的css/js/gif/htm等等各類資源。同時有一個UI組件包描述文件(*.ui.xml)，描述對UI組件包的結構、內容、以及對其它UI組件包的依賴關係。 開發時，UI組件包以獨立的maven工程爲單位，最後以Jar包爲單位進行發佈。 舉例：咱們要複用JQuery，實際上很是簡單。在Maven工程結構中，在resources目錄中，放置全部的JQuery資源進來，而後編寫一個ui組件包描述文件。UI組件包就算開發完畢了。

TinyUI框架的組件管理器會根據包描述文件自動加載、引入相關資源，而這些都無需程序人員干預。

頁面規範 TinyUI推薦採用模板語言,如：tinyTemplate,FreeMaker等做爲展示層，這樣能夠充分發揮組件包的優點。Tiny內部實現複用了tinyTemplate模板語言，可是實際上並無限制，你徹底能夠用其它模板語言作一樣的事情。

具體頁面開發時，組件開發人員採用宏定義具體的函數接口，普通開發人員直接調用宏接口就能夠了。   舉例：

 這樣寫頁面多簡單，採用Tiny框架的前臺開發，基本上幫助你解決了上述難題，可是對你的工做沒有任何限制。

小貼士 Dojo簡介： Dojo是一個用javascript語言實現的開源DHTML工具包。利用它的低級API和可兼容的代碼，可以寫出輕便的、單一風格（複雜）的JavaScript代碼，它能提高你的web應用程序可用性、交互能力以及功能上的提升。

ExtUI簡介： 它是一種主要用於建立前端用戶界面，是一個基本與後臺技術無關的前端ajax框架。組件豐富，功能強大，惋惜如今收費了。

3、TinyUI的設計思路

 

常見問題 1.UI中JS的引入與順序，JS合併的問題 。 2.UI中css的引入與順序，CSS合併的問題 。 3.重複代碼的問題。一樣的內容在許多地方都有，若是要改動就要改動許多個地方，修改時萬一遺留了，未來就是一個坑。 4.總體佈局調整困難的問題。 5.開發效率的問題，項目經理老是指望界面開發越快越好。 6.執行效率的問題，前臺響應要求速度更快。 7.國際化問題。

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

 

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

1.JS和CSS的引入問題。 傳統界面開發，程序員須要在頁面配置引入js和css的路徑，既麻煩又容易出錯。TinyUI採用組件封裝了JS和CSS，這份工做統一交給組件設計者處理，程序員開發頁面時根本不用關心須要引入哪些JS和CSS，只要知道要用哪些宏接口就好了。 2.JS和CSS的順序問題。 這個問題也是傳統界面開發之間的難點，JS和CSS之間的順序搞錯，一般會致使頁面出現亂七八糟的問題，定位問題也是異常複雜。TinyUI將順序問題交給組件管理器處理，它會依次檢查組件的依賴關係，若是有UI組件的依賴關係配置錯誤，組件管理器會記錄異常日誌，這些不正常組件不會被加載到正常組件列表。組件間的依賴關係理順後，組件內部包含的JS和CSS的關係也就理順了。TinyUI按以下順序加載JS和CSS： a.  父組件的資源比子組件優先加載。好比組件A依賴組件B，那麼框架先加載組件B資源，再加載組件A資源。 b. 同一組件的資源，順序靠前的優先加載。組件的js和css路徑均可以配置多個，同一組件框架按配置順序依次加載資源。 3.JS和CSS的合併問題。 在傳統界面開發，性能調優每每涉及到js和css的合併，頁面的IO少了，性能天然能提升，可是對程序員來講這就很困難，改動js和css意味着不少相關頁面都要修改。TinyUI從框架層面支持js和css的合併，程序員無需手工調整，框架提供了UiEngineTinyProcessor這個適配器處理上述合併問題。

UiEngineTinyProcessor合併JS  a. 適配器經過組件管理器得到所有正常的UI組件，並依次遍歷每一個組件  b. 調用組件的getComponentJsArray方法，得到該組件引用的所有js路徑，並依次遍歷每一個路徑  c. 根據路徑經過VFS得到js的內容，合併到outputStream  d. 合併完每一個組件的引入JS內容，最後合併該組件須要調用JS代碼

UiEngineTinyProcessor合併CSS  a. 適配器經過組件管理器得到所有正常的UI組件，並依次遍歷每一個組件  b. 調用組件的getComponentCssArray方法，得到該組件引用的所有css路徑，並依次遍歷每一個路徑  c. 根據路徑經過VFS得到css的內容，合併到outputStream  d. 合併完每一個組件的引入css內容，最後合併該組件須要調用CSS代碼   重複代碼的問題

仔細分析頁面重複代碼的由來，主要能夠分爲如下幾塊： 1.無用的資源引入。寫過頁面的人都知道，程序員最喜歡把一段段的js、css處處粘，而不分析是否有用，致使大量沒必要要的資源引入，下降頁面性能。TinyUI經過組件管理器管理資源，最終輸出到頁面的引用，絕對跟組件包的資源一致，只要組件設計者設計組件包時保證沒有引入無用的資源。 2.重複的業務邏輯。TinyUI採用模板語言渲染頁面，經過宏定義解決重複業務邏輯。由於宏是能夠嵌套宏的，因此理論上再複雜的頁面均可以經過宏搞定，宏若是使用得當，能夠大幅度減小頁面代碼。 3.相同的功能片斷。 有些業務場景須要引入統一功能片斷，界面相同，TinyUI能夠採用模板命令include完美處理這種場景。   總體佈局調整困難的問題

傳統界面開發，頁面佈局與邏輯代碼是混在一塊兒的，特別是複雜頁面，調整起來天然困難。TinyUI的設計時一開始就將佈局與頁面邏輯完全分紅兩個文件，固然你要用TinyUI推薦的模板組織。

Tiny的模板體系組織方式以下： ?支持多層文件結構 ?佈局文件統一用.layout擴展名結尾 ?頁面文件統一用.page擴展名結構 ?只有.page文件能夠被外部訪問，訪問方式有兩種.page或.pagelet ?訪問.pagelet，實際上至關於訪問同名page，模板引擎只會作頁面渲染；訪問.page，模板引擎除了頁面渲染還要進行佈局渲染  

也許有些人看到這裏問：將一個文件內容拆分紅兩塊，還要定義二者間的聯繫，是否是太複雜了？其實一點也不復雜，用戶根本不須要定義佈局文件和頁面文件的聯繫，請參考如下規範設計你的頁面佈局結構：

查找佈局文件規則 1.匹配當前目錄同名的佈局文件。 2.匹配當前目錄默認的佈局文件。 3.若某一級目錄沒法知足匹配條件，則向該目錄上一級目錄進行匹配，直到根目錄爲止。   好比：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，若是存在，則渲染。

經過上面的渲染機制，程序員有可能只寫了很是少的內容，可是經過分層佈局渲染，最後出來的效果也會很是豐富多彩。

開發效率的問題 採用TinyUI框架對開發效率提高，至少有以下兩點： 1.重複代碼大幅減小，工做效率天然就提高了。 2.學習曲線下降。採用組件+模板的頁面開發模式，對普通開發人員基本能夠屏蔽JS和CSS，這二者的技能要求程度就能夠大大下降；額外增長的學習成本是模板語言，對程序員而言，模板語言達到使用程度，一天足矣。   執行效率的問題 TinyUI框架採用以下技術手段，加快頁面的訪問速度： 1.合併頁面的JS和CSS。經過減小網絡IO請求，特別是在原頁面涉及不少資源時，提速效果就會比較明顯。 2.緩衝功能。用戶能夠設定哪些頁面進行緩衝，緩衝多長時間。 3.支持BigPipe方式渲染頁面。前文說過TinyUI框架支持將大頁面拆分紅一個個pagelet，讓瀏覽器能夠多線程同時渲染，從而提高性能。   普通的web頁面，通常來講是頁面生成，網絡傳輸，前面頁面渲染，這三部分的時間加起來就是操做人員從點擊鼠標到最後看到頁面的時間。

舉例來講，一個頁面有主頁面框架，共有4個部分的內容顯示。爲了便於分析，簡化一下模型，假設主頁面框架生成須要0.2S，4個部分的內容生成各自須要0.2S，網絡傳輸與瀏覽器渲染也各計成0.2秒，這樣，在傳統的方式下，須要的時間就是0.2*5+0.2*5+0.2*5=3秒。

那麼換成BigPipe方式，時間的執行分佈大概是以下圖：

 

 

 

因此換成BigPipe方式，時間大概就是1.4秒的樣子。節省的時間大概是50%強一點的樣子。

固然，這個時間是在各自三段時間都是0.2秒的狀況，實際運行過程當中，網絡傳輸的時間在局域網中的時間會更快，後臺頁面的處理，也能夠採用多線程處理的方式來進行，這樣，後面頁面處理時間能夠縮短到0.4S，網絡傳輸時間有0.2S也能夠了。因爲採用了BigPipe方式，在0.6S的時候，就能夠看到最頁面框架，後面的時間就是一塊塊出來，當後面出來的時間比較快的時候，給使用的感覺就是在0.6S+界面就能夠出來。這個與最初的3S，用戶體驗上明顯是有天壤之別的。

國際化的問題 對於小項目而言，可能不關心這個問題。可是TinyUI好歹是技術框架，目標是大型項目，若是不能支持國際化，那也說不過去。

TinyUI提供兩種國際化方案，任君選擇： 1.國際化資源標籤。國際化資源就很容易理解了，工程添加國際化資源文件，頁面用國際化標籤進行引用便可。 2.國際化頁面。 國際化頁面是指訪問某頁面時，模板引擎會優先使用與訪問者相同的語言的頁面文件進行渲染。譬如：存在aa.page，aa.zh_CN.page，若是非zh_CN語言的人來訪問，渲染的是aa.page，zh_CN語言的人來訪問，渲染的是aa.zh_CN.page。