UI開發的新時代----認識迅雷界面引擎

?

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

轉載于:https://www.cnblogs.com/Bonker/p/3286773.html

總結

以上是生活随笔為你收集整理的认识迅雷界面引擎的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。