好久沒(méi)寫博客,轉(zhuǎn)管理后技術(shù)有些荒廢, 貌似現(xiàn)在流行知乎live和微信公眾號(hào), 博客已經(jīng)有些過(guò)時(shí)了,但關(guān)鍵是你對(duì)技術(shù)的思考和總結(jié), 采用什么方式其實(shí)不重要。
現(xiàn)代大型客戶端軟件,考慮到各種終端類型(Windows, Mac, ios, Android...),大部分采用分層設(shè)計(jì),用C++封裝跨平臺(tái)的SDK/Framework, UI層采用各平臺(tái)Native語(yǔ)言實(shí)現(xiàn)(C++/Java/objective-c),典型的分層如下:









另外對(duì)于復(fù)雜的UI, 我們可能還需要引入U(xiǎn)I Layout Manager的角色, 因?yàn)閺?fù)雜UI在不同的情況下整個(gè)UI layout會(huì)有巨大改變, 比如會(huì)議系統(tǒng)中共享桌面時(shí)你可能需要把整個(gè)主窗口隱藏,在單屏和雙屏?xí)r整個(gè)UI又完全不一樣, 所以我們需要借助UI Layout Manager協(xié)調(diào)多個(gè)窗口的顯示和隱藏。
最近工作要對(duì)UI層進(jìn)行重構(gòu),對(duì)UI層的設(shè)計(jì)進(jìn)行了一些思考,UI層是客戶端直接和用戶交互的那層,它的好壞直接影響到整個(gè) 產(chǎn)品的用戶體驗(yàn), 重要性不言而喻。但是很多時(shí)候我們卻很難將這層代碼寫好,給用戶良好的用戶體驗(yàn), 主要下面一些因素:
(1)邏輯復(fù)雜性, 因?yàn)檫@層是整個(gè)客戶端所有feature的最終集成地
(2)各種屏幕尺寸的適配,這個(gè)Mobile上更明顯
(3)Accessibility的支持: tab導(dǎo)航,高對(duì)比,高DPI, 讀屏...
(4) 換膚和多語(yǔ)言
上面問(wèn)題(2)(3)(4)都是和具體平臺(tái)系統(tǒng)相關(guān)的,這里我們重點(diǎn)關(guān)注如何解決問(wèn)題(1), 也就是如何通過(guò)合理的設(shè)計(jì)降低UI層的復(fù)雜性, 因?yàn)閁I層的代碼往往寫到最后變成了"一坨屎"。
其實(shí)UI層的設(shè)計(jì)已經(jīng)有很多成熟的模式,我們依次看下:
(1) Original MVC

這是最早的的MVC模式, 據(jù)說(shuō)最早的計(jì)算機(jī)鼠標(biāo)鍵盤不是直接關(guān)聯(lián)在view上的, 因此它們的輸入事件會(huì)先到達(dá)contorller端, 然后由controller去修改model, model再通知view更新數(shù)據(jù)(view更新時(shí)會(huì)從Model取數(shù)據(jù))
(2) Modern MVC

這是現(xiàn)在大家對(duì)MVC模式的理解,和上面的original MVC類似, 只不過(guò)鼠標(biāo)鍵盤事件的輸入源轉(zhuǎn)成了View, 這也符合大家對(duì)窗口理解
(3) MVP

MVP模式割斷了Model和View端的直接通訊,讓Controller(Presenter)當(dāng)作中介者,View接收到鼠標(biāo)鍵盤事件后通過(guò)event通知controller, controller把新數(shù)據(jù)更新到model, model數(shù)據(jù)更改后通知訂閱它事件的controller, controller再把新數(shù)據(jù)更新到view端
(4) Dialog MVP

這種方式是簡(jiǎn)化版的MVP, 把View和Controller寫在一個(gè)dialog里面,雖然UI和邏輯寫在了一起,但是使用起來(lái)很簡(jiǎn)單。
(5) MVVM

MVVM (Model-View-ViewModel) 是MVP的改進(jìn),它講Presenter改成了支持?jǐn)?shù)據(jù)綁定的ViewModel, 這是WPF特有的一種數(shù)據(jù)模型,依賴語(yǔ)言和庫(kù)對(duì)數(shù)據(jù)綁定的支持。
通過(guò)觀察,我們發(fā)現(xiàn)上面無(wú)論那種模型,都有幾個(gè)基本概念:
a. View, 展示界面
b. Controller, 控制邏輯
c. Model, 廣域的model指的是領(lǐng)域建模的業(yè)務(wù)模型層,因?yàn)槲覀冞@里已經(jīng)將業(yè)務(wù)模型封裝在了Framework(SDK)及其下層, 所以我們這里的model主要指的是UI層的一些數(shù)據(jù)模型。
我們發(fā)現(xiàn)每個(gè)view都有一個(gè)controller來(lái)控制它, 但是很多時(shí)候一個(gè)feature我們需要協(xié)調(diào)多個(gè)controller/view, 比如IM里收到一條消息, 你可能既要在消息窗口中顯示, 同時(shí)也要在右下角像QQ那樣出個(gè)提示, 另外可能還需要播放提示音, 這么多事情需要有人來(lái)協(xié)調(diào), 所以我們需要引入Manager的概念, Manager以feature/模塊為劃分單位。
另外有些view可能會(huì)很復(fù)雜, 所以需要引入sub-view的概念, 也就是說(shuō)一個(gè)復(fù)雜的view可能是一顆樹(shù), 它由很多sub-view和, 甚至grandchild-view組成, 同時(shí)每個(gè)view/child-view/grandchild-view都有自己的controller來(lái)處理它的事件。
另外一個(gè)view是由多個(gè)控件元素(Element Control)組成,很多時(shí)候我們需要對(duì)控件元素進(jìn)行定制, 我想這是大家知道的一個(gè)常識(shí)。
UI層基本的結(jié)構(gòu)大概如下:

另外有些時(shí)候我們需要在Manager, Controller和Data Model之間進(jìn)行一些事件廣播, 因此我們需要引入消息中心(message center)的概念。
這樣最終的層次結(jié)構(gòu)圖大概類似這樣:

這樣最終的層次結(jié)構(gòu)圖大概類似這樣:

我們看下各層的訪問(wèn)規(guī)則:
UI Eelement Control, 是界面的基本組成元素, 它的事件會(huì)通知到自己的view (Windows/Panel);
UI View, 可以完全控制自己的Element control, 它收到控件事件后會(huì)通知到自己的 UI Controller;
UI Controller, 可以完全控制自己的UI View, 并且響應(yīng)UI View的事件消息, UI Controller可以調(diào)用自己的UI Data model存儲(chǔ)數(shù)據(jù), 也可以調(diào)用某個(gè)UI Manager的接口處理事件;
UI Manager, 和底層Framework/SDK打交道,可以完全控制controller, 也可以通過(guò)message center廣播重大事件;
我們可以看到, Manager->Controller->View->Eelement, 我們逐層都是基于類完全訪問(wèn), 反之則是基于接口事件消息, 這也符合設(shè)計(jì)中的單向依賴原則。
另外我們?cè)僬f(shuō)下UI Data Model的設(shè)計(jì), UI Data Model實(shí)際上分成public和private兩種類型, 其中public的數(shù)據(jù)是共享的, 可能是多個(gè)controller/manager都要訪問(wèn)的, private則是某個(gè)controller私有的數(shù)據(jù)。
這樣整個(gè)UI層的層次結(jié)構(gòu)就很清楚了:
首先有個(gè)總的UI Manager, 它下面包含三種角色: UI Manager Manager, UI Controller Manager, UI Data Manager。
(1)UI Manager Manager根據(jù)feature/模塊分成多個(gè)子UI Manager, 子UI Manager根據(jù)需要也可以包含自己的子UI Manager;
(2)UI Controller Manager根據(jù)窗口數(shù)量管理多個(gè)窗口的UI Controller, 其中復(fù)雜窗口的UI Controller可能包含樹(shù)狀的子UI Controller;
(3)UI Data Manager根據(jù)數(shù)據(jù)類型,管理多個(gè)public/Share 的UI Data Model; private的UI Data Model是每個(gè)Controller私有的,外面沒(méi)法直接訪問(wèn),由它的controller暴露接口訪問(wèn)。

另外對(duì)于復(fù)雜的UI, 我們可能還需要引入U(xiǎn)I Layout Manager的角色, 因?yàn)閺?fù)雜UI在不同的情況下整個(gè)UI layout會(huì)有巨大改變, 比如會(huì)議系統(tǒng)中共享桌面時(shí)你可能需要把整個(gè)主窗口隱藏,在單屏和雙屏?xí)r整個(gè)UI又完全不一樣, 所以我們需要借助UI Layout Manager協(xié)調(diào)多個(gè)窗口的顯示和隱藏。
最后我們總結(jié)下上面這種架構(gòu)設(shè)計(jì)的優(yōu)勢(shì):
(1) 界面和邏輯的分離, view和controller可以由不同的人分別實(shí)現(xiàn), 獨(dú)立變動(dòng)
(2) 基于接口分層設(shè)計(jì), 單向依賴且低耦合
(3) UI層數(shù)據(jù)類型的分類,共有共享的還是私有的
(4) 消息中心,同時(shí)支持同步/異步的消息廣播機(jī)制, Manager/Controller/Data Model可以各自訂閱自己感興趣的消息
(5)每個(gè)Manager主要關(guān)注自己的那塊feature, 單一職責(zé)


