Error

既然客戶端都有網(wǎng)絡(luò)功能，就會(huì)涉及到通訊方式和數(shù)據(jù)格式以及協(xié)議， 這三者不是完全獨(dú)立，而是有機(jī)統(tǒng)一的。

首先說(shuō)通訊方式，常見(jiàn)的通訊方式包括TCP，UDP， P2P和http(s), 很多時(shí)候我們不會(huì)用單一的通訊方式，而是多種通訊方式的結(jié)合。比如說(shuō)TCP端口被封，走不通時(shí)，我們會(huì)轉(zhuǎn)成嘗試http(s)。IM中聊天文本走的是TCP， 由服務(wù)器轉(zhuǎn)發(fā)，但是2個(gè)客戶端之間的文件傳輸我們可能走的又是P2P了， 多個(gè)人之間的語(yǔ)音聊天， 我們走的又是UDP了。

其次說(shuō)數(shù)據(jù)格式，常見(jiàn)的數(shù)據(jù)格式包括二進(jìn)制編碼，開(kāi)源序列化協(xié)議和文本格式。
二進(jìn)制一般是自定義的私有格式，通常對(duì)數(shù)值，我們會(huì)轉(zhuǎn)成大頭端，對(duì)字符串我們會(huì)用UTF8 編碼，因?yàn)闆](méi)有冗余數(shù)據(jù)，它的優(yōu)點(diǎn)是不會(huì)浪費(fèi)帶寬；主要缺點(diǎn)是有硬編碼的味道，不好擴(kuò)充。
開(kāi)源序列化協(xié)議這里主要是指google的protocal buffer,  現(xiàn)在很多公司都在用， 很多人基于它開(kāi)發(fā)了自己的RPC框架。主要優(yōu)點(diǎn)是數(shù)據(jù)小，使用簡(jiǎn)單而高效。
文本格式主要是指xml和json. 相對(duì)來(lái)說(shuō)xml比較清晰和容易擴(kuò)充，但是冗余數(shù)據(jù)比較多。json借助javascript對(duì)它語(yǔ)言層次的支持，感覺(jué)主要是前端人員使用的比較多。

最后再說(shuō)協(xié)議,  協(xié)議和我們的應(yīng)用相關(guān)聯(lián)。比如郵件客戶端，當(dāng)然是走SMTP和POP3了; IM客戶端的話，一般走XMPP了;  網(wǎng)絡(luò)會(huì)議的話，可以走ITU的T.120協(xié)議， 也可以RFC 6501定義的XCON， 信令走SIP， 數(shù)據(jù)走RTP等。

通信協(xié)議層是整個(gè)客戶端網(wǎng)絡(luò)事件驅(qū)動(dòng)的引擎，它可能會(huì)比較簡(jiǎn)單，也可能會(huì)很復(fù)雜。如果是基于XMPP的IM， 它可能會(huì)比較簡(jiǎn)單，因?yàn)榛旧现恍枰粚游谋緟f(xié)議的封包和解包就可以了。 當(dāng)如果是基于T.120網(wǎng)絡(luò)會(huì)議客戶端，就會(huì)比較復(fù)雜，它數(shù)據(jù)包走的自定義的二機(jī)制格式，按照T.120協(xié)議的建議， 在通訊協(xié)議層又分了3層：TP, MCS和GCC。TP層主要封裝數(shù)據(jù)傳輸?shù)姆绞? 可以讓上層無(wú)差別的區(qū)分TCP和http(s)。 MCS層主要提供多點(diǎn)傳輸功能， 它抽象出通道(channel)這個(gè)概念， 讓不同session的數(shù)據(jù)進(jìn)行邏輯隔離， 上層用戶可以同時(shí)加入不同的通道來(lái)進(jìn)行一對(duì)一和一對(duì)多的數(shù)據(jù)收發(fā)，并且通道中的數(shù)據(jù)有不同的優(yōu)先級(jí)， 還有令牌這個(gè)機(jī)制。我們也可以在MCS層對(duì)數(shù)據(jù)進(jìn)行加密和壓縮， 還可以對(duì)上層的大數(shù)據(jù)包進(jìn)行切包等。 GCC層主要封裝會(huì)議的最基本邏輯，比如創(chuàng)建會(huì)議和加入session數(shù)據(jù)包的格式封裝等， 讓上層可以通過(guò)API調(diào)用而不用關(guān)心協(xié)議要求的數(shù)據(jù)包格式。不同的數(shù)據(jù)包會(huì)工作在不同的層次， 比如心跳包可能在底層TP層就被攔截了，它不要再往上層發(fā)，因?yàn)樯厦娌挥藐P(guān)心這個(gè)； 而有些數(shù)據(jù)包，則需要從底層往上層按照整個(gè)協(xié)議棧層層轉(zhuǎn)發(fā)，當(dāng)然每層都會(huì)剝離掉自己的協(xié)議頭， 直至上層用戶數(shù)據(jù)到達(dá)它的最終用戶。

總之，通訊協(xié)議層封裝了客戶端和服務(wù)端的通訊方式及協(xié)議格式， 讓上層用戶不用關(guān)心底層的通信機(jī)制， 而只關(guān)注應(yīng)用的接口事件。理論上我們可以在上層應(yīng)用不做大調(diào)整的前提下，直接將網(wǎng)絡(luò)會(huì)議客戶端中的T.120協(xié)議成基于SIP的XCON。

一個(gè)客戶端程序通常是由很多功能模塊組成，模塊按功能來(lái)說(shuō)可以分為基礎(chǔ)組件和應(yīng)用組件。

基礎(chǔ)組件為應(yīng)用組件提供的基礎(chǔ)設(shè)施，基礎(chǔ)組件是可以在不同的項(xiàng)目中重復(fù)使用的(比如界面控件庫(kù)，2D渲染引擎Skia, 跨平臺(tái)的網(wǎng)絡(luò)和線程庫(kù)等)。 
應(yīng)用組件通常和我們當(dāng)前的特定應(yīng)用程序相關(guān)，比如我們的網(wǎng)絡(luò)會(huì)議客戶端包含的桌面共享模塊, 文檔共享模塊，視頻音頻模塊，文本聊天模塊等。

應(yīng)用模塊本身分為帶界面和無(wú)界面兩種情況， 帶界面的情況下我們通常會(huì)給組件提供一個(gè)容器窗口的句柄， 讓組件自己在內(nèi)部組織自己的界面。這種帶界面的組件通常會(huì)為邏輯和界面的分離帶來(lái)麻煩，在Window上實(shí)現(xiàn)一些半透明和動(dòng)畫(huà)效果也很難。 比如我們想提供跨平臺(tái)的SDK來(lái)封裝邏輯，這時(shí)我們會(huì)更傾向讓?xiě)?yīng)用組件采用無(wú)界面的模式，組件在跨平臺(tái)層只封裝邏輯和提供數(shù)據(jù)， 而把數(shù)據(jù)發(fā)到最上層界面層后再統(tǒng)一處理。

對(duì)功能組件我們的設(shè)計(jì)原則是盡量保持獨(dú)立和可復(fù)用，最好能以仿COM方式動(dòng)態(tài)升級(jí)而不用重新編譯， 另外組件之間要保持層次性，避免雙向或是循環(huán)依賴。

客戶端本身是處理和收發(fā)網(wǎng)絡(luò)數(shù)據(jù)， 這里就涉及到對(duì)這些數(shù)據(jù)如何組織和存儲(chǔ)的問(wèn)題。這個(gè)通常會(huì)根據(jù)客戶端的類(lèi)型采用不同的處處理方式:
對(duì)于永久存儲(chǔ)的數(shù)據(jù)，當(dāng)然是保存成文件或是存入數(shù)據(jù)庫(kù)，文件如xml, 數(shù)據(jù)庫(kù)如ACCESS,  SQL server, mysql等。
臨時(shí)數(shù)據(jù)當(dāng)然是存入內(nèi)存了，根據(jù)需要采用不同的數(shù)據(jù)結(jié)構(gòu)， 組織格式如array，list, map, hashmap等。
還有一種是常見(jiàn)的數(shù)據(jù)保存方式是內(nèi)存數(shù)據(jù)庫(kù)，最常見(jiàn)是SQLite了， 內(nèi)存數(shù)據(jù)庫(kù)既能高效的分類(lèi)保存大量數(shù)據(jù)， 又可以直接用基于SQL語(yǔ)句進(jìn)行查詢和處理， 比如foxmail客戶端就是用SQLite存儲(chǔ)的郵件信息。
還有一種是跨進(jìn)程共享的數(shù)據(jù)，我們一般當(dāng)然是內(nèi)存映射文件了。比如我們有一個(gè)實(shí)時(shí)顯示log的工具， 我們通常會(huì)在對(duì)方應(yīng)用程序里分配共享內(nèi)存的內(nèi)存映射文件，所有的log都寫(xiě)到里面，然后在log工具程序里讀取和顯示。
當(dāng)然還有一些數(shù)據(jù)可能存到網(wǎng)上去的， 常見(jiàn)的比如我們的云筆記, 這時(shí)數(shù)據(jù)分服務(wù)端數(shù)據(jù)和本地cache。

對(duì)于數(shù)據(jù)存儲(chǔ)我們的設(shè)計(jì)原則是根據(jù)需要，選擇簡(jiǎn)單高效的方式。比如我們?cè)谠O(shè)計(jì)網(wǎng)絡(luò)會(huì)議客戶端時(shí)曾討論要不要引入SQLite, 理想情況是引入內(nèi)存數(shù)據(jù)庫(kù)后各個(gè)組件和上層應(yīng)用的數(shù)據(jù)都可以統(tǒng)一存儲(chǔ)，采用數(shù)據(jù)驅(qū)動(dòng)的方式，可以很方便的跟蹤整個(gè)客戶端的運(yùn)行情況。但后來(lái)發(fā)現(xiàn)這種設(shè)計(jì)會(huì)把本來(lái)各自獨(dú)立的組件通過(guò)數(shù)據(jù)庫(kù)耦合在了一起，而且各組件的數(shù)據(jù)格式本身都很不要一樣， 很難統(tǒng)一存儲(chǔ)， 另外很多數(shù)據(jù)實(shí)際也只是臨時(shí)數(shù)據(jù), 沒(méi)必要把簡(jiǎn)單的時(shí)間做復(fù)雜了。

客戶端框架一般有兩個(gè)作用：一是把所有的功能組件組織起來(lái)，進(jìn)行統(tǒng)一的管理和展現(xiàn)； 二是實(shí)現(xiàn)整個(gè)客戶端的主界面?？蛻舳丝蚣茉趨f(xié)調(diào)各個(gè)組件時(shí)， 要注意避免讓組件之間產(chǎn)生雙向依賴， 而是應(yīng)該讓組件把事件通知給框架后由框架統(tǒng)一協(xié)調(diào)和處理， 所以客戶端框架通常是整個(gè)客戶端邏輯最復(fù)雜的部分。 一個(gè)好的客戶端框架，通常會(huì)采用插件方式設(shè)計(jì)，可以動(dòng)態(tài)插拔需要的組件。最好是可以根據(jù)服務(wù)端的配置， 動(dòng)態(tài)下載和更新所需要的插件。

對(duì)于客戶端框架， 我們的設(shè)計(jì)原則是低耦合和可擴(kuò)展?；旧纤邢聦咏M件的改動(dòng)都會(huì)影響到我們的客戶端框架，客戶的很多新需求和新組件也會(huì)導(dǎo)致框架產(chǎn)生壞味道， 這里我們?cè)O(shè)計(jì)時(shí)就要考慮如何讓客戶端框架能及時(shí)的適應(yīng)這些變化。

客戶端肯定會(huì)有界面，在Windows平臺(tái)上，現(xiàn)在的界面大致分為以下幾類(lèi)：
基于Windows原始窗口控件句柄的C++ native 客戶端， 基于.net的winform客戶端，基于.net的WPF客戶端，基于C++的DirectUI客戶端， 以嵌入瀏覽器(如webkit)方式實(shí)現(xiàn)的客戶端， 還有一類(lèi)是基于Xaml的Metro客戶端。

對(duì)于企業(yè)級(jí)大型安裝應(yīng)用，主要考慮的是開(kāi)發(fā)效率，所以客戶端還是以.net為主； 但是對(duì)于互聯(lián)網(wǎng)企業(yè)， 更多的是要求客戶端精簡(jiǎn)而高效， 所以還是以C++為主。 這里就設(shè)及到C++的兩種界面庫(kù)， 一種是基于windows窗口句柄和控件自繪機(jī)制的界面庫(kù)，還有一中是基于DirectUI的界面庫(kù)， 現(xiàn)在大一點(diǎn)的公司基本上都有自己的DirectUI界面庫(kù)?；谛薷腤ebkit方式實(shí)現(xiàn)的界面庫(kù)可以通過(guò)Canvas和SVG動(dòng)畫(huà)等方式實(shí)現(xiàn)一些很炫的效果， 但是它和標(biāo)準(zhǔn)程序的用戶體驗(yàn)還是有一定差距：一來(lái)web實(shí)現(xiàn)的控件跟Windows標(biāo)準(zhǔn)控件有很大不同， 二來(lái)web的流式布局和應(yīng)用程序的網(wǎng)格布局也不一樣。

對(duì)于界面，個(gè)人覺(jué)得這個(gè)東西變化實(shí)在太快了，所以我覺(jué)得應(yīng)該盡量用界面和邏輯相分離的方式組織代碼。

對(duì)于客戶端架構(gòu)設(shè)計(jì)，個(gè)人覺(jué)得最大的原則就分層設(shè)計(jì)， 每層都封裝一個(gè)概念并保持獨(dú)立， 同時(shí)根據(jù)依賴倒置的原則， 站在上層客戶的角度提供接口。軟件工程里面的一條黃金定律:“任何問(wèn)題都可以通過(guò)增加一個(gè)間接層來(lái)解決。