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