認(rèn)識(shí)迅雷界面引擎
作者：劉智聰
UI開(kāi)發(fā)的新時(shí)代----認(rèn)識(shí)迅雷界面引擎
第一部分：交互開(kāi)發(fā)技術(shù)概述
軟件產(chǎn)品的交互開(kāi)發(fā)一直以來(lái)都不是一件令人愉悅的事情。首先，由于每個(gè)人編寫(xiě)的第一個(gè)圖形應(yīng)用程序就已經(jīng)使用了一些交互開(kāi)發(fā)技術(shù)，而且由于IDE工具的強(qiáng)大,容易總結(jié)出交互開(kāi)發(fā)就是“拖拖控件，改改屬性，寫(xiě)寫(xiě)響應(yīng)”的經(jīng)驗(yàn)，所以很容易被認(rèn)為是沒(méi)什么技術(shù)含量的工作。但實(shí)際上，這是一個(gè)特別不容易的工作：因?yàn)樽鳛檐浖a(chǎn)品的臉面，上至公司老板，下至任意一個(gè)普通用戶(hù)，大家都可以對(duì)你的工作成果拼頭論足，并提出修改意見(jiàn),而這些修改意見(jiàn)反應(yīng)到產(chǎn)品的方案修改上，總是會(huì)讓修改成本與項(xiàng)目的修改復(fù)雜度不呈線(xiàn)性關(guān)系。很多剛剛從事這一行的項(xiàng)目經(jīng)理總是不能理解，為什么按一個(gè)方案修改交互，需要1天，而另一個(gè)看起來(lái)似乎差不多的方案，卻要改上一個(gè)月？
從另一個(gè)角度也可以發(fā)現(xiàn)這里的技術(shù)門(mén)檻不易：其它領(lǐng)域的設(shè)計(jì)模式，經(jīng)驗(yàn)總結(jié)文章已經(jīng)汗牛充棟，各種各樣的新思路和在這些思路上建立起來(lái)的各種開(kāi)源庫(kù)，每過(guò)幾年基本就要洗上一輪，但在交互開(kāi)發(fā)上，除了各個(gè)廠(chǎng)商提供的平臺(tái)開(kāi)發(fā)方法，幾乎沒(méi)有被公認(rèn)和被廣泛使用的界面開(kāi)發(fā)庫(kù)，更不要提相關(guān)方法論和模式的升華，總結(jié)與創(chuàng)新了。
但是，軟件產(chǎn)品的交互體驗(yàn)，特別是互聯(lián)網(wǎng)產(chǎn)品的交互體驗(yàn)，如今越來(lái)越多的受到人們的重視。從過(guò)去能實(shí)現(xiàn)功能完成交互,到后來(lái)提供一致的操作習(xí)慣，流暢的實(shí)現(xiàn)整個(gè)交互流程，如今還渴望交互體驗(yàn)?zāi)芑谟脩?hù)的使用心理設(shè)計(jì)，更加美觀(guān)，并提高產(chǎn)品的整體品味。如今全球市值最高的Apple公司，正是靠著其ipod,iphone,ipad系列產(chǎn)品的優(yōu)秀交互體驗(yàn)和近乎完美的工業(yè)設(shè)計(jì)，征服了廣大用戶(hù)。
迅雷作為中國(guó)非常流行的一款Windows平臺(tái)下的客戶(hù)端產(chǎn)品，對(duì)于改進(jìn)產(chǎn)品的交互體驗(yàn)有著強(qiáng)烈的愿望。迅雷5.8完成了工具軟件的關(guān)鍵功能提升，隨后的版本進(jìn)化，希望能進(jìn)一步改進(jìn)產(chǎn)品的交互體驗(yàn)： 更美觀(guān)也更現(xiàn)代。迅雷5.9（迅雷6）是基于傳統(tǒng)Windows界面開(kāi)發(fā)技術(shù)改進(jìn)交互體驗(yàn)的結(jié)果，這個(gè)結(jié)果雖然還不錯(cuò)，但帶來(lái)了另一個(gè)問(wèn)題：開(kāi)發(fā)成本的提高。迅雷作為一款由多個(gè)部門(mén)合作開(kāi)發(fā)的（包括合作開(kāi)發(fā)交互）客戶(hù)端產(chǎn)品，傳統(tǒng)的開(kāi)發(fā)技術(shù)不能很好的組合各個(gè)部門(mén)開(kāi)發(fā)的模塊，開(kāi)發(fā)成本與穩(wěn)定性都有問(wèn)題。公司迫切的需要一個(gè)能解決這些問(wèn)題的下一代界面引擎，并在多個(gè)方面使用各種方式開(kāi)始了勇敢的嘗試。
第二部分 過(guò)去我們?nèi)绾伍_(kāi)發(fā)按鈕
現(xiàn)在我將通過(guò)一個(gè)經(jīng)典的windows下”自畫(huà)按鈕”的工程實(shí)例,和大家一起觀(guān)察UI開(kāi)發(fā)的過(guò)程?！弊援?huà)按鈕”是一個(gè)非常常見(jiàn)的產(chǎn)品需求,相信不少讀者都有過(guò)相似的經(jīng)歷（下列故事純屬虛構(gòu)，如有雷同，真是巧合）.
那年正是Windows XP最流行的時(shí)候，我們的產(chǎn)品也跟進(jìn)時(shí)代的發(fā)展,將界面風(fēng)格升級(jí)到了XP Style,同時(shí)我們的產(chǎn)品還兼容Windows2000,設(shè)計(jì)和產(chǎn)品都希望我們的軟件在兩個(gè)系統(tǒng)下都能有一致的外觀(guān)表現(xiàn)。于是,我就需要開(kāi)發(fā)一個(gè)能在兩個(gè)平臺(tái)下都長(zhǎng)得一樣的按鈕。這個(gè)活并不困難,我們先看看需求:
看了需求之后，作為一個(gè)合格的Windows開(kāi)發(fā)工程師，很快就完成了。實(shí)現(xiàn)代碼大致如下:
CButton::OnPaint() {
DrawBkg(m_state,0,0,width,height);
DrawText(m_state,m_btnText,width/2-textWidth/2,height/2-textHeight/2);
if (isFocus)
{
DrawFocusRect(2,2,width-2,height-2);
}
}
CButton::OnLButtonDown(){
ChangeState(BTN_STATE_DOWN);
}
CButton::OnLButtonUp(){
ChangeState(BTN_STATE_NORMAL);
FireEventOnClick();
}
分析實(shí)現(xiàn)代碼,大家可以看到基本思路是這樣的
1. 確定按鈕有幾個(gè)狀態(tài)，然后根據(jù)這些狀態(tài)下按鈕的外觀(guān)，確定如何實(shí)現(xiàn)OnPaint函數(shù)。
2. 處理WM_LBUTTONDOWN,WM_MOUSEMOVE等輸入消息，在這些消息里改按鈕的狀態(tài)
3. 在WM_LBUTTONUP,WM_KEYUP等消息里，F(xiàn)ire一個(gè)按鈕自己定義的OnClick事件
很好，我們的軟件用上了新按鈕，問(wèn)題解決了，產(chǎn)品經(jīng)理和設(shè)計(jì)師都很滿(mǎn)意。咱也結(jié)束了一天的工作，安心回家睡個(gè)好覺(jué)。
又過(guò)了幾天，公司的產(chǎn)品總監(jiān)在產(chǎn)品會(huì)上提到，我們要統(tǒng)一所有產(chǎn)品的交互邏輯，特別是某些按鈕，根據(jù)現(xiàn)在的交互規(guī)范，應(yīng)該加上醒目的圖標(biāo)。會(huì)后設(shè)計(jì)師打開(kāi)PHOTOSHOP，很快就把按新規(guī)范調(diào)整的按鈕發(fā)給了我。如下圖
這次我沒(méi)有立刻開(kāi)始實(shí)現(xiàn)，因?yàn)楣镜牧硪划a(chǎn)品也用到了我實(shí)現(xiàn)的這個(gè)按鈕，我要保證原有的按鈕能繼續(xù)正常工作，我打算和那邊的研發(fā)商量一下怎么改。這里我有兩個(gè)方案。
方案一：
1.定義 CIconButton，繼承CButton
2.CIconButton添加方法SetIcon
3.在CIconButton::OnPaint里添加如下代碼
OnPaint() {
DrawBkg(m_state);
DrawIcon(m_state);
DrawText(m_state);
}
4.使用新的CIconButton完成需求
方案二、
1.在CButton里添加兩個(gè)擴(kuò)展點(diǎn)回調(diào)
OnPaint() {
if(OnDrawBkgCallback())
DrawBkg(m_state);
if(OnDrawItemCallback())
DrawText(m_state);
}
并提供設(shè)置回調(diào)的接口
SetOnDrawBkgCallback()
SetOnDrawItemCallback()
2.產(chǎn)品通過(guò)SetOnDrawItemCallBack完成需求
void OnBtnDrawItemCallback()
{
DrawIcon();
return true;
}
m_button.SetOnDrawItemCallback(OnBtnDrawItemCallback);
在方案的選擇上，大家有了一些爭(zhēng)議：方案一看起來(lái)比較直接，而且實(shí)現(xiàn)起來(lái)也比較快，最重要的是使用我的控件庫(kù)的產(chǎn)品開(kāi)發(fā)工程師特別希望這么改；而方案二實(shí)現(xiàn)需要更多的代碼，并且產(chǎn)品開(kāi)發(fā)工程師需要學(xué)習(xí)和編寫(xiě)更多的代碼才能完成這個(gè)需求，不過(guò)這個(gè)方案的未來(lái)我更看好。最后我們選定了一個(gè)方案(在這里選哪一個(gè)都能完成需求)，加班寫(xiě)好代碼，提交測(cè)試，發(fā)布新的界面控件庫(kù)，制作新的安裝包，一陣忙碌，這個(gè)小小的需求升級(jí)總算是結(jié)束了。
又過(guò)了幾天，公司大老板通過(guò)郵件告訴大家,公司產(chǎn)品的大客戶(hù)比較喜歡Windows Rabbion風(fēng)格。于是產(chǎn)品經(jīng)理再次調(diào)整設(shè)計(jì),要求一些按鈕要改成如下樣式:
很明顯，這次圖標(biāo)跑到按鈕文本上面去了，這就是最新的時(shí)代潮流。雖然很不情愿，但這不就是生活么？隔壁卡位的設(shè)計(jì)師，半個(gè)小時(shí)搞定了所有需要調(diào)整的地方的效果圖，按時(shí)下班回家了，而我們工程師還必須加班! 這次的工作量就和上次修改的方案有關(guān)了：
如果我們上一步使用了方案一，這次我們?nèi)兆記](méi)那么好過(guò)了。我們需要?jiǎng)?chuàng)建一個(gè)新的CIconButton2繼承自CIconButton,再加一個(gè)新接口SetIcon2，可以在設(shè)置圖標(biāo)的同時(shí)調(diào)整圖標(biāo)在文本的什么位置（這次還耍了個(gè)小聰明，這個(gè)接口可以支持圖標(biāo)在文本的上下左右4個(gè)方位） 。
而使用方案二的優(yōu)越性則在這里得到了體現(xiàn)：作為按鈕的開(kāi)發(fā)者，并不需要修改一行代碼，你只要繼續(xù)指導(dǎo)一下需要實(shí)現(xiàn)這個(gè)需求的產(chǎn)品開(kāi)發(fā)工程，調(diào)整一下OnBtnDrawItemCallback的實(shí)現(xiàn)即可。
實(shí)際上，在迅雷，我們有過(guò)一次在方案一這條路上走到頭的經(jīng)歷，迅雷的代碼里有一個(gè)叫 CXLButton的怪物，提供了近200個(gè)接口，有快2萬(wàn)行代碼。當(dāng)編寫(xiě)這個(gè)類(lèi)的哥們走人以后，接手這個(gè)Class的新人發(fā)現(xiàn)這個(gè)按鈕的用途(在最后一個(gè)版本的需求里)只是用來(lái)實(shí)現(xiàn)一個(gè)圖標(biāo)在文字上面的工具欄按鈕，”這垃圾代碼是誰(shuí)寫(xiě)的！”，他逢人就要這么嘲笑一下，然后花了一個(gè)下午的時(shí)間寫(xiě)了一個(gè)新類(lèi) CXLButton2，清晰明了的實(shí)現(xiàn)了這個(gè)需求。但我們都知道，這是另一個(gè)輪回的開(kāi)始。而且，有資格使用方案一還意味著控件開(kāi)發(fā)工程師愿意幫助產(chǎn)品開(kāi)發(fā)工程師修改接口與實(shí)現(xiàn)，如果這兩組工程師不在一個(gè)公司，更大的成本會(huì)花在人與人的溝通上甚至無(wú)法進(jìn)行。
Microsoft提供的標(biāo)準(zhǔn)控件，通過(guò)類(lèi)似方案2的方法提供可擴(kuò)展性。方案二在過(guò)去，都被普遍認(rèn)為是一個(gè)出色的解決可復(fù)用性問(wèn)題的模式（我很少在招聘的時(shí)候能看到有人能在開(kāi)發(fā)控件的時(shí)候通過(guò)這種方式提供可擴(kuò)展性），但其缺點(diǎn)之一就是讓控件的使用有點(diǎn)復(fù)雜，學(xué)習(xí)成本很高。比如我至今都沒(méi)有通過(guò)MSDN 完全搞清楚過(guò)微軟TreeView提供的這種擴(kuò)展事件的細(xì)節(jié)，還好有一份泄漏的Windows源代碼，讓我對(duì)這些回調(diào)之間的關(guān)系能有清楚的認(rèn)識(shí)。而且這個(gè)方案會(huì)讓產(chǎn)品開(kāi)發(fā)工程師學(xué)習(xí)很多高度依賴(lài)控件庫(kù)內(nèi)部實(shí)現(xiàn)的知識(shí)，如果產(chǎn)品更換的底層界面庫(kù)，那么大量的這種經(jīng)驗(yàn)就沒(méi)有意義了。
而且，方案二真的能以不變應(yīng)萬(wàn)變，支持所有的需求變化么？大家可以自行思考。
通過(guò)這個(gè)可擴(kuò)展的按鈕控件的開(kāi)發(fā)實(shí)例,我們總結(jié)了三個(gè)交互開(kāi)發(fā)的經(jīng)驗(yàn):
一、 交互是最易改變的需求
二、 開(kāi)發(fā)一個(gè)可復(fù)用的交互控件的主要工作有
1)根據(jù)最初的需求決定方法，事件
2)根據(jù)最初的需求決定如何實(shí)現(xiàn)OnPaint,如何將原始的OS輸入事件轉(zhuǎn)成邏輯事件
3)在OnPaint里織入擴(kuò)展點(diǎn)。
三、交互開(kāi)發(fā)涉及的技術(shù)點(diǎn)很多，實(shí)現(xiàn)時(shí)注意細(xì)節(jié)，注規(guī)避常見(jiàn)問(wèn)題，當(dāng)繪制特別復(fù)雜的時(shí)候還要仔細(xì)優(yōu)化性能。
第三部分 新的思路
從頭觀(guān)察上面的例子，我發(fā)現(xiàn): 不管怎么修改交互需求，隔壁卡位的設(shè)計(jì)師總是很少加班，他們的工作量似乎能很好的和交互需求的修改量成正比，而且沒(méi)有什么局限。相反，我們的工作總是存在一些天花板，一旦需求改變?cè)竭^(guò)了開(kāi)發(fā)時(shí)預(yù)設(shè)的一些前提條件，需求修改的響應(yīng)時(shí)間會(huì)大幅增加。
不管是通過(guò)那種方法，有限的接口和有限的擴(kuò)展點(diǎn)，理論上滿(mǎn)足不了近乎無(wú)限的需求變化。而我們觀(guān)察所謂的通過(guò)事件擴(kuò)展控件的方案，其核心是希望OnPaint能夠根據(jù)各種參數(shù)，調(diào)整工作流程。而OnPaint里實(shí)現(xiàn)的功能，說(shuō)到底就是 “在指定位置使用適當(dāng)?shù)暮瘮?shù)繪制文本或貼圖”。要想讓一段代碼的流程具有很強(qiáng)的可變性，是非常困難的。從某種意義上說(shuō)，OnPaint函數(shù)就是萬(wàn)惡之源。
明白了問(wèn)題的根源，那么如何解決問(wèn)題就有了方向:我們要在交互開(kāi)發(fā)的過(guò)程中干掉OnPaint。實(shí)際上在這之前已經(jīng)有技術(shù)實(shí)現(xiàn)了這一點(diǎn)：HTML本身并沒(méi)有提供繪制函數(shù)，而實(shí)際上，前端交互開(kāi)發(fā)是目前所有交互開(kāi)發(fā)技術(shù)里流程分工合理，并且需求修改響應(yīng)速度保持線(xiàn)形增長(zhǎng)，容易學(xué)習(xí)，有完善工具鏈條的技術(shù)。我們可以在傳統(tǒng)app開(kāi)發(fā)里使用HTML技術(shù)么？ 很多人回答YES,并做出了開(kāi)創(chuàng)性的嘗試。不過(guò)經(jīng)過(guò)了一些思考之后我們并沒(méi)有選擇HTML（原因我們以后會(huì)在另外的文章里詳細(xì)的介紹）。經(jīng)過(guò)了一些借鑒和總結(jié)，我圍繞這個(gè)問(wèn)題提出了一個(gè)新的概念：可以通過(guò)定義原子UI對(duì)象(UIObject)之間的父子關(guān)系和位置關(guān)系組成對(duì)象樹(shù)(UIObjTree)來(lái)描述界面,UIObject的類(lèi)型是相當(dāng)有限的。而按邏輯構(gòu)建的UIObjTree的實(shí)際上組織了OnPaint里“按什么樣的順序在什么地方畫(huà)什么”的問(wèn)題。
這個(gè)概念有點(diǎn)抽象？還是你已經(jīng)完全明白了？都沒(méi)關(guān)系，還是剛剛例子里的按鈕，按這種方法分析以后，我們會(huì)得到一個(gè)怎樣的UIObjTree呢？
非常直觀(guān)的對(duì)象樹(shù)，只有兩個(gè)UIObject。接下來(lái)的需求修改就變成了修改這個(gè)數(shù)據(jù)結(jié)構(gòu)。而樹(shù)結(jié)構(gòu)的修改接口提供起來(lái)是非常簡(jiǎn)單缺完備的：添加節(jié)點(diǎn)，刪除節(jié)點(diǎn)，查找節(jié)點(diǎn)，修改節(jié)點(diǎn)屬性。我們看看在這個(gè)結(jié)構(gòu)上如何響應(yīng)上面的需求
你會(huì)發(fā)現(xiàn)抽象UI得到的UIOjbTree會(huì)與設(shè)計(jì)師提供的PSD圖結(jié)構(gòu)非常相似，這就非常符合真正的開(kāi)發(fā)情況：開(kāi)發(fā)得到的需求并不直接來(lái)自產(chǎn)品經(jīng)理，而是來(lái)自設(shè)計(jì)師。如果技術(shù)能夠?qū)⒃O(shè)計(jì)師的成果直接轉(zhuǎn)化成App可以使用的數(shù)據(jù)結(jié)構(gòu)，那么這樣的技術(shù)無(wú)疑在實(shí)現(xiàn)能力和開(kāi)發(fā)效率上，能與設(shè)計(jì)師相同。（這個(gè)理論迅雷通過(guò)迅雷7 ，XMP多個(gè)產(chǎn)品的大規(guī)模實(shí)踐，已經(jīng)得到了有效的證明）所以BOLT界面引擎的創(chuàng)新，根本上是提出了一種新的抽象交互的思路。
這里建議您可以考慮將一些常見(jiàn)的控件，或則您現(xiàn)在正在開(kāi)發(fā)的軟件的交互解構(gòu)成UIObjTree，試一試吧。
圍繞這個(gè)概念來(lái)構(gòu)建整個(gè)界面引擎，我們還獲得了一系列進(jìn)一步的好處：
基于同樣的模式分析交互，能輸出近乎一致的結(jié)果。
可以將界面布局從邏輯代碼中獨(dú)立出來(lái)。
對(duì)界面的抽象是平臺(tái)無(wú)關(guān)的。(雖然我們沒(méi)有把跨平臺(tái)作為BOLT界面引擎的關(guān)鍵目標(biāo))
讓對(duì)象的屬性在一段時(shí)間里按規(guī)律變化，就能實(shí)現(xiàn)動(dòng)畫(huà)。開(kāi)發(fā)各種特效也有了一致的思路
基于對(duì)象樹(shù)枝葉嫁接的復(fù)用和界面模塊劃分，易于理解。并提供了統(tǒng)一的可訪(fǎng)問(wèn)性 (所謂的可訪(fǎng)問(wèn)性，是指你可以在控件的開(kāi)發(fā)者不提供實(shí)現(xiàn)的基礎(chǔ)之上，只通過(guò)UIObjTree的樹(shù)操作借口，就能訪(fǎng)問(wèn)并修改其表現(xiàn))
交互開(kāi)發(fā)技術(shù)的變遷
整理上面的思路，我們得到交互開(kāi)發(fā)技術(shù)，或則就是界面庫(kù)的分代標(biāo)準(zhǔn)：
第一代 :SDK開(kāi)發(fā),使用系統(tǒng)默認(rèn)控件
第二代 :基于窗口子類(lèi)化的自繪控件皮膚庫(kù)。繪制通?；贕DI?？丶?lèi)型和系統(tǒng)一致。
第三代 :提供一套完整的體系(窗口,繪制等)，所有的控件都基于這個(gè)體系開(kāi)發(fā)。本身提供很多功能更強(qiáng)的控件，并有統(tǒng)一的方法開(kāi)發(fā)/使用新控件。這一代庫(kù)主要是解決實(shí)現(xiàn)能力問(wèn)題。由于Windows的系統(tǒng)限制，二代庫(kù)有很多功能局限。(比如按鈕發(fā)光這個(gè)需求需要按鈕的實(shí)現(xiàn)代碼可以繪制到按鈕子窗口以外的)
第四代 :布局文件+腳本語(yǔ)言的開(kāi)發(fā)模式，依靠”組合”抽象界面并圍繞這個(gè)概念搭建 。不提供控件但提供易學(xué)易用的控件開(kāi)發(fā)模式。不提供內(nèi)置特效但能讓使用者輕易開(kāi)發(fā)自己的界面特效。
這個(gè)分代標(biāo)準(zhǔn)基本上是參考windows上的界面庫(kù)發(fā)展而制定的，第二代和第三代庫(kù)本身其實(shí)沒(méi)有什么本質(zhì)上的區(qū)別，主要是Windows由于兼容原因，提供的UI相關(guān)API和窗口混和器過(guò)于古典（子窗口與父窗口之間只有遮蓋關(guān)系，沒(méi)有辦法混合，很多GDI函數(shù)都無(wú)視Alpha通道），使得開(kāi)發(fā)一套完整的界面庫(kù)反而還需要自己實(shí)現(xiàn)窗口管理和圖形庫(kù)這些有一定技術(shù)門(mén)檻的基礎(chǔ)設(shè)施。新的OS本身提供的UI框架本身就解決了這些問(wèn)題，所以這些新的OS上的庫(kù)就直接是3代庫(kù)了。
需要指出的是,有一些技術(shù)框架也提供基于組合的方法構(gòu)建界面的方法.比如現(xiàn)在相當(dāng)流行的iOS上的cocoa框架，很多時(shí)候可以只通過(guò)組合各種View的方法來(lái)創(chuàng)建新的控件。但這個(gè)框架我依舊認(rèn)為他是三代庫(kù)，因?yàn)榭蚣苓€是依舊以繪制為核心構(gòu)建，比如你可以組合多個(gè)不同屬性的按鈕構(gòu)成一個(gè)新控件，但你無(wú)法獲得按鈕上文字的SubView,沒(méi)有獲得統(tǒng)一的可訪(fǎng)問(wèn)性。
第四部分 Bolt界面引擎概念介紹
關(guān)鍵概念
· 使用XML文件來(lái)定義UIObjTree，用Lua腳本來(lái)實(shí)現(xiàn)界面邏輯
· 圍繞核心概念建立了一系列輔助設(shè)施
基本工作原理
BOLT界面引擎這里提供了兩個(gè)重要的核心概念HostWnd ,Render。Render可以把一顆構(gòu)建完成的UIObjTree渲染成一張位圖。而HostWnd是界面引擎核心與操作系統(tǒng)之間的橋梁，能把這張位圖通過(guò)系統(tǒng)提供的API畫(huà)到屏幕上，并能轉(zhuǎn)化操作系統(tǒng)的鍵盤(pán)/鼠標(biāo)等事件成為引擎的定義得標(biāo)準(zhǔn)輸入事件(Action)。
這張圖里還提到了我們的UI資源管理模塊和XML布局文件讀取與管理模塊。
Render的基本工作原理
DirtyRect(臟矩形)是驅(qū)動(dòng)Render工作的核心。關(guān)于臟矩形，在很多2D游戲開(kāi)發(fā)的文章里都有詳細(xì)介紹。當(dāng)一顆UIObjTree上的產(chǎn)生了臟矩形，其對(duì)應(yīng)的Render在下次渲染時(shí)就會(huì)開(kāi)始有動(dòng)作，否則就什么也不干。Render會(huì)選取與臟矩形相交的所有UIObject，然后按這些UIObject的z-order排序（從小到大）排序 ，再按這個(gè)順序依次調(diào)用這些UIObject的Draw方法。由于所有的UIObject都是由引擎實(shí)現(xiàn)的，所以這個(gè)Draw方法也是一個(gè)不可見(jiàn)的內(nèi)部函數(shù)，Draw的實(shí)現(xiàn)會(huì)調(diào)用一些我們精心優(yōu)化過(guò)的圖形圖像繪制函數(shù)，這一切就構(gòu)成了Bolt界面引擎的高速渲染引擎。
注:虛線(xiàn)表示的矩形是臟矩形，那么Render只會(huì)渲染與這個(gè)區(qū)域相交的UIObject。
BOLT界面引擎里控件的概念
基于UIObject和UIObjTree，開(kāi)發(fā)控件就是設(shè)計(jì)一個(gè)可復(fù)用的“對(duì)象樹(shù)片斷”，而使用控件就是由界面引擎完成這個(gè)對(duì)象樹(shù)片斷如何嫁接到對(duì)象樹(shù)上。
這里通過(guò)一個(gè)簡(jiǎn)單的例子演示一下這個(gè)過(guò)程
這樣的一個(gè)MessageBox。抽象成UIObjTree
我們可以定義Button的對(duì)象樹(shù)片斷是：
合并以后
而且很明顯，引入控件的概念，能把一顆復(fù)雜的UIObjTree分解成多個(gè)片斷交給團(tuán)隊(duì)開(kāi)發(fā)，而最后合成的UIObjTree依舊保持了各個(gè)節(jié)點(diǎn)的可訪(fǎng)問(wèn)性。
第五部分 未來(lái)展望
Bolt界面引擎的核心概念，是完全創(chuàng)新與獨(dú)立的，并不依賴(lài)任何操作系統(tǒng)。所以BOLT界面引擎的發(fā)展方向之一是把界面引擎移植到各種各樣的平臺(tái)，目前最成熟穩(wěn)定的平臺(tái)是Windows，有工業(yè)級(jí)產(chǎn)品的質(zhì)量。我們?cè)贏(yíng)ndiord平臺(tái)和MacOS平臺(tái)都有初步移植的版本，但我們還需要花費(fèi)很多精力在合適的機(jī)會(huì)完成讓這些平臺(tái)的界面引擎更完美
我們?cè)谝浦驳紸ndiord平臺(tái)時(shí)發(fā)現(xiàn)，界面引擎要想在這些手持設(shè)備上流程運(yùn)行，原有的基于CPU指令集優(yōu)化的高速渲染器是不好的。一是CPU性能達(dá)不到，不夠流暢，二是太耗電，這里迫切需要使用設(shè)備提供的硬件加速功能。得益于界面引擎不希望用戶(hù)編寫(xiě)繪制代碼的核心概念，我們只需要重新調(diào)整高速渲染器就可以實(shí)現(xiàn)硬件加速。目前我們正在嘗試各種各樣的支持硬件加速的框架方案：既能高效使用硬件的能力 ，又能兼顧C(jī)PU算法的靈活性。
我們目前的主要精力都放在引擎本身的完善上，但實(shí)際上，如同HTML與Dreamweaver一樣，界面引擎在設(shè)計(jì)之初就可以讓布局部分由使用專(zhuān)業(yè)工具的專(zhuān)業(yè)人員完成，而不是負(fù)責(zé)編寫(xiě)邏輯代碼的工程師。我們對(duì)我們的布局XML格式的簡(jiǎn)單優(yōu)雅和可擴(kuò)展性都有充分的信心，我們衷心的希望各位同行在理解認(rèn)可了我們的概念后支持我們的標(biāo)準(zhǔn)，這樣大家就能開(kāi)發(fā)各種輔助工具，互相通用，共同改進(jìn)BOLT界面引擎的工具鏈支持。
