最近的工作是給開源的DUILib支持Accessibility， 一些經驗記錄并分享下。
微軟的Accessibility其實Windows平臺上一個挺重要的東西， 盡管在國內不受重視，但是如果你的軟件要出口歐美，Accessibility是必須的， 不然國外正規單位（政府，學校，大公司等）是禁止采購的。
如果我們的軟件用的是Winodws標準控件，一般Accessibility是系統默認內置支持的 （當然這也不是一定的，據我測試系統的Date Time Picker控件是不支持MSAA的）。因為系統標準控件在展現和行為上的一些限制以及自繪的復雜性，越來越多的軟件使用DirectUI技術，關于使用DirectUI的理由，更多參見<<如何讓窗口控件半透明>>和<<軟件換膚的原理>>.
國內最有名的的DirectUI界面庫當然是開源的DUILib （盡管這套庫已停止更新）， 實際上我以前在自己業余寫點東西時， 也參考過它， 具體參見<<開源一套DirectUI界面庫>>。對于開源的DUILib， 個人覺得它有挺多優點， 也有挺多缺點， 我們重點說缺點， 因為這是我們改進的方向。
1。擴展性差
DUILib只實現了一些基本的控件，好的DirectUI庫可以通過基本控件組合來輕松實現復雜控件，而要達到這個效果， 很多時候我們需要攔截子控件的消息， 盡管DUILib提供了delegate機制來子類化子控件， 但是這樣消息攔來攔去實在太不方便了，很多時候自己都轉暈了。個人覺的這里我們可以引入WPF的隧道和冒泡機制， 這個東西對DirectUI界面庫實在太重要了。
2。不支持Layered窗口
要完美支持Layered窗口，意味著所有的Render全都要支持Alpha通道， DUILib使用GDI， 如果沒有特殊處理，意味著沒法完美支持Layered窗口， 我這篇也談到過這個問題<<如何基于純GDI實現alpha通道的矢量和文字繪制>>。
3。大數據時性能不行
DUILib很多時候只適合做些簡單的界面，本身控件基類很龐大，數據量方面對于幾百條數據還行，但是對于成千上萬條數據就吃不消了，這時我們需要引入WPF的虛表機制。
4。不支持圖文排版
盡管DUILib支持簡單的HTML排版， 但是畢竟太簡單，如果我們要在QQ那樣的聊天窗口里引入就吃不消了， 另外它渲染HTML那個代碼我是吃不消看的。
5. 基本不支持Accessibility
6。其他
接口和屬性定義太隨意， 采用導出類的方式也不好擴充， 渲染方面最好能在GDI/GDI+/Direct2D方面進行切換，最好將核心控件和擴展控件分離開， 編輯器也太簡陋。
今天我們重點說Accessibility，一個界面庫要完整支持Accessibility, 要包括太多東西 （具體可以參見控制面板里的"輕松訪問中心"），我估計只有微軟自己做的到（比如WPF），這也是很多人推薦系統標準控件而排斥DirectUI的理由。我們說的Accessibility很多時候只是簡化版， 下面我們說重點的幾條。
1。鍵盤支持
鍵盤支持簡單來說就是即使我沒有鼠標， 我也能通過通過鍵盤完成所有操作。它主要包括鍵盤導航和控件的鍵盤支持。鍵盤導航主要是指我可以通過一些熱鍵（如F6）可以在不同窗口(Panel)之間進行焦點切換， 我可以通過Tab/Shift+Tab在窗口內不同控件之間進行焦點導航?？丶逆I盤支持也是很多國內DirectUI庫所缺失的，比如：
Dialog： Enter執行默認， ESC退出并關閉
Button：空格執行
CheckBox：空格取反
Radio：空格取反，上下左右鍵切換選中項
TabCtrl：焦點選中時上下左右切換， 焦點沒選中時Ctrl+Tab/Ctrl+Tab+Shift切換Tab頁
....
總之，DUILib在鍵盤支持這塊已經做了不少工作，但是還有挺多事要做，每個控件都要完整支持鍵盤是個很精細的活。
2。讀屏軟件和自動化測試的支持。
ScreenReader(讀屏器)主要是給盲人用的， 程序可以實時的把獲得焦點的控件和系統發生的事件播報出來， 很多讀屏軟件都需要收費，還好Win7之后系統已自帶讀屏軟件(控制面板\輕松訪問\輕松訪問中心\啟動講述人)。自動化測試時也需要工具能夠理解我們界面中包含的元素類型和位置， 以及模擬操作事件等。
DirectUI要支持讀屏和自動化測試一般有2種方式， MSAA和UI Automation。 MSAA是比較古老的方式，主要就是實現IAccessible接口；UI Automation是微軟特意給WPF新增加的。MSAA出來的時候還是Win95， 因為歷史原因有一些限制， 比如不支持Text控件，沒法描述復雜控件等， 所以微軟后來引入了UI Automation， 具體參見<<Windows GUI自動化測試技術的比較和展望>>。
MSAA最大的優點是穩定， 所以我在DUILib里采用MSAA來實現ScreenReader的支持。簡單說下幾個關鍵點：
(a) 每個控件啊實現IAccessible接口的Proxy對象盡量獨立，里面保存一個控件指針的引用，這樣即使控件銷毀了，Proxy對象可以依舊存在(系統仍可能會訪問這個對象)。
(b) 按照控件的層次體系，實現每種控件的Proxy類(實現IAccessible接口)。
(c) WM_GETOBJECT請求OBJID_CLIENT時返回根節點的Proxy對象， 焦點變化時通知觸發事件NotifyWinEvent(EVENT_OBJECT_FOCUS, m_hWndPaint, (LPARAM)m_pFocus， CHILDID_SELF), 窗口收到WM_GETOBJECT消息時根據ObjectID(這里是控件指針)找到該控件， 然后返回該控件的Proxy。 (這是關鍵，這個問題郁悶了我好久的...)
3。高對比(high contrast)的支持
高對比，主要是給色盲用，這個東西一般自繪程序都不會支持， 即使你是用標準控件，因為一般會用自己漂亮的圖片和色彩來表現界面， 高對比實現的關鍵點是你在畫每個元素時要通過GetSystemColor來獲取顏色。據我測繪除了微軟自己的程序， 其他越是漂亮的軟件越是不支持高對比（即使如QQ和Chrome）。
4。高DPI的支持
隨著Surface Pro和高分辨率設備的流行，程序對高DPI的支持正變得越來越重要， 具體參見<<關于Windows高DPI的一些簡單總結>>。傳統的基于標準控件的程序要支持高DPI是在太難了，所以微軟才有了DWM虛擬化。但是DirectUI對高DPI的支持有著天然的優勢， 我們完全可以在界面庫這層讓程序完美支持高DPI， 界面的渲染主要是文字，矢量和圖片， 文字和矢量完全可以通過無損縮放繪畫實現，圖像可以通過適當縮放和換圖來實現。
總結下，盡管我N次吐槽基于GDI的DirectUI界面庫會隨著XP的淡出而逐漸失去市場， 但是實際工作中還是要經常和GDI打交道，外面招聘單位還是有不少Windows客戶端的開發崗位。 在這"移動互聯和"Web前端"橫行的"大數據"時代，很多同事開始向移動App和大數據轉型， 盡管這幾年PC客戶端的開發人員是只出不進， 但是只要Windows存在一天，我們的工作就還是有價值的..
浙公網安備 33010602011771號