原文鏈接-決戰(zhàn)客戶端技術(shù)

　　最近經(jīng)常有小伙伴問我要做一個客戶端, 該怎么弄. 這個問題問得很粗獷, 但是實際上客戶端的選型是一個很細(xì)的問題. 從大學(xué)到現(xiàn)在, 也弄了不少的客戶端, 從公司主營炒股專業(yè)客戶端, 到內(nèi)部項目使用的OA客戶端, 還有大學(xué)的時候為了畢業(yè)而弄的QT, 各式各樣, 這里就給大家講解一下, 我所了解的幾種客戶端的選型(這里主要針對windows，也會提及一些跨平臺技術(shù)).

　　windows下的客戶端都是基于win32, 在這基礎(chǔ)上, 我們可以細(xì)分為, 原生win32, MFC, C#(語言封裝), 高級win32-duilib, QT, CEF, electron(nwjs) 大體就這幾種了, 其中很多是重合的, 下面我們就每個都講一講優(yōu)劣.

原生win32

• 優(yōu)點 　　

　　上面也說了, windows下所有的東西, 都是win32的, 它就像建房子用的磚一樣, 可以用它做出任何我們想要的東西, 幾乎是無所不能, 而且它是基于消息驅(qū)動的, 性能非常高.

• 缺點 　　

　　優(yōu)點很好, 缺點也非常明顯, 太底層了, 全部都是C的接口, 如果要實現(xiàn)復(fù)雜的效果, 所有的東西都要自己寫, 會把代碼寫得非常復(fù)雜, 不是簡簡單單就能弄好的, 而且維護成本巨大, 非常不建議使用, 如果是中小公司, 要做客戶端, 沒有一定的實力, 千萬不要去踩這個坑.

MFC

　　MFC是微軟自己開源的一套UI框架, 大多是基于自己做的東西，給出了一套通用的解決方案. 優(yōu)點 　　封裝度高, 大多我們要的組件, 都有現(xiàn)成的使用, 修改起來也方便, 而且也是用的消息驅(qū)動型, 性能高. 缺點 　　雖然說是C++的, 但是里面C和C++混著用, 腦子有點不好使, 而且除開那些共有組件之外, 其他的組件, 寫起來也是很麻煩, 對程序員的要求也是比較高的, 現(xiàn)在很少有人再使用MFC了, 至少我身邊算是比較少的.

csharp

　　這個就不能說優(yōu)缺點了, 語言級別的不一樣, 雖然底層都調(diào)用win32的東西, 但是已經(jīng)是完全面向?qū)ο蟮姆庋b了, 這個運行機制也不一樣, 消息已經(jīng)都被封裝了, 更多的是回調(diào)和反射. 整體來說對程序員友好, 文檔齊全, 寫起來很流暢. csharp是一門非常優(yōu)雅的語言, 用它來寫客戶端也是很流暢的, 而且csharp有很多第三方組件, 收費的, 不收費的, 國內(nèi)的, 國外的都可以做到開箱即用, 方便極致. 當(dāng)然也有不好的地方, 就是依賴于.net, 所有的用戶必須安裝.net, 而且還有不同版本的兼容問題, 如果用戶的環(huán)境是不受你控制的, 建議還是不要用的好.

高級win32-duilib

　　duilib是我特別想向大家推薦的一個C++UI庫, 做的非常的好, 提供了類似于html, css類似的封裝, 當(dāng)然它是基于xml的, 我司的主營炒股軟件就是自己維護的一個duilib庫. 而且許多像騰訊, 網(wǎng)易都有使用. 現(xiàn)在主流的方案都是duilib + CEF, 或者win32 + CEF這種混合的解決方案.

• 優(yōu)點 　　

　　高度封裝, 類html的文件, 我們可以在上面快速實現(xiàn)復(fù)雜的效果, 同時它支持自繪, 可以擴展我們想要的功能, 消息驅(qū)動型, 性能高, 如果是中小企業(yè), 并且對UI的性能以及效率要求非常高, 這里強烈推薦此方案.

• 缺點 　　

　　文檔缺失, 幾乎各個大的公司都維護了一套自己的duilib版本, 缺少統(tǒng)一的標(biāo)準(zhǔn), 在接觸第一版本的duilib的時候, 幾乎都是看代碼查特性. 對開發(fā)者要求也是挺高的, 如果想要重度使用, 幾乎要通讀整個庫的代碼的, 不過這個庫封裝的非常好, 也很簡潔, 讀懂不是什么難事.

QT

• 優(yōu)點 　　

　　跨平臺, 面向?qū)ο? 性能高, 非常良好的文檔, 類html的布局, 幾乎能實現(xiàn)你想要的所有的東西.

• 缺點 　　

　　學(xué)習(xí)路徑比較陡峭, 而且重, 編譯出來的東西會比較大, QT的東西都是自成體系的, 如果以前沒有用過QT, 學(xué)習(xí)起來會比較難以接受.

CEF

　　與其說它是一門獨立的技術(shù), 其實它更像一個組件, 一個網(wǎng)頁的組件, 但是它太強大了, 以至于光用這個組件, 就可以實現(xiàn)所有的功能了. 　　CEF全稱Chromium Embedded Framework, 是一款基于Chromium瀏覽器的嵌入式框架, 說白了就是一個dll, 它提供了一套接口, 使用這套接口, 你可以控制整個網(wǎng)頁, 以及里面幾乎所有的東西, 整個頁面交互都由你控制, 效果非常好.

　　我們的客戶端里面或多或少需要涉及跟網(wǎng)頁的交互, 不管什么理由, 在CEF之前, 幾乎采用的都是window提供的IE組件, 然后實現(xiàn)一堆的com接口, 但是這種方案有個很大的問題, 就是太依賴用戶的環(huán)境, 用戶環(huán)境非常惡劣, 各種ghost系統(tǒng), 閹割版系統(tǒng), 組件缺失, 環(huán)境變量不一致, 最后導(dǎo)致的問題就是程序各種奔潰,更為惡心的是, 這種奔潰是沒法通過代碼解決的, CEF的出現(xiàn), 簡直就是救星, 自從我們公司軟件使用CEF之后, 奔潰的概率只有原來的1/10, 極大的提高了用戶體驗.

• 優(yōu)點 　　

　　使用網(wǎng)頁支持各種酷炫的效果, 接口精簡, 維護成本算是比較低的, 跟win32或是duilib使用, 簡直就是絕配, 而且跨平臺, 在linux, mac都有對應(yīng)的版本.

• 缺點 　　

　　重, 耗內(nèi)存, 大家都懂chrome就是內(nèi)存大戶, 軟件里面嵌入一個chrome, 內(nèi)存就蹭蹭蹭的往上漲, 隨隨便便增加個幾百兆的內(nèi)存是經(jīng)常的事, 這是個很現(xiàn)實的問題, 因為這個內(nèi)存問題, 我們軟件至今維護了一個非CEF的版本, 給那些不愿意升級的用戶使用. 但是個人覺得隨著科技的發(fā)展, 硬件的更新迭代, 這種問題都不會是問題, 更何況巨硬加入chromium的陣營, 很可能會解決這種內(nèi)存問題.

electron(nwjs)

electron和nwjs是同一類東西, nwjs出得更早, 但是現(xiàn)在electron使用的更廣泛. 依稀記得15年剛接觸nwjs的時候的那種內(nèi)心的激動, 感覺發(fā)現(xiàn)新大陸一樣, 它的確就是新大陸, 現(xiàn)在的vscode, atom等等, 都是基于electron的應(yīng)用. 　　

　　electron 和 CEF一樣，也是chromium系列的, 但是CEF是通過封裝接口, 然后由chromium回調(diào)到自己的程序, 驅(qū)動整個程序運行, electron則是在chromium的基礎(chǔ)之上, 再嵌入一了個js執(zhí)行的v8引擎, 由此v8引擎與chromium內(nèi)部的v8進行信號的交互, 驅(qū)動程序運行, 兩種是截然不同的方式. 而且electron是已經(jīng)一個完全獨立的客戶端, 不需要像CEF一樣, 寄宿在其他程序內(nèi)部.

• 優(yōu)點 　　

　　跨平臺, 非常良好的交互體驗, 完全的網(wǎng)頁編程, 起點低, 不需要有任何C++編程的經(jīng)驗, 就可以開發(fā)一個完整的, 高體驗的客戶端, 支持C++擴展. 各種簡單高效, 簡直就是開發(fā)利器.

• 缺點

　　重, 內(nèi)存高, 性能差, 各種黑箱操作, 如果程序掛了, 完全就是束手無策. 早期的版本非常不穩(wěn)當(dāng), 很容易就crash了, 15年在調(diào)研了這種技術(shù)之后, 我們在新的項目上使用了nwjs, 奔潰問題太嚴(yán)重了, 完全束手無策, 后面我們拉下來整個nwjs的代碼, 自己編譯整個項目之后, 才略微猜到問題, 前前后后花了兩個C++程序員, 大概半個月的時間, 非常不可控, 以至于我們放棄了這種方案, 新版的程序, 采用了duilib + CEF的方案. 但現(xiàn)在已經(jīng)過了很久了, vscode和atom已經(jīng)幫我們躺過大部分坑了, 我相信現(xiàn)在electron是非常穩(wěn)定的.

技術(shù)選型

　　electron向我們描繪了非常美好的前景, 大概就是前端統(tǒng)治一切, 前景很美好, 實際上卻不是那么優(yōu)雅, electron暫時性能是比較差的, 原因很簡單, 單線程跑, 你能跑多快啊. 如果完全沒有C++功底, 無腦推薦electron, 如果有C++功底, 還是建議使用duilib + CEF. 如果想做跨平臺, QT是最好的選擇, 技術(shù)如果不錯就用QT + CEF. 如果是細(xì)心的人會發(fā)現(xiàn)QQ是用了CEF的, 微信是duilib + CEF, 網(wǎng)易云音樂前端是全CEF的, 釘釘是duilib + CEF, 我們?nèi)粘Ｓ玫倪@幾大軟件, 幾乎都是這么個架構(gòu), 好像也沒什么太多選擇.

后記

　　寫完這篇文章之后, 經(jīng)同事指正, 認(rèn)為寫的太泛, 應(yīng)該把每一類拆出來, 單獨為一篇, 然后從技術(shù)路線, 實現(xiàn)效果, 運維成本, 以及整體企業(yè)成本等方面展開描述. 如果真這樣的話, 要寫的內(nèi)容就多了, 后面就在微信公眾號里面更新這個系列吧, 歡迎關(guān)注公眾號-雀觀代碼.

　　以上純粹一本正經(jīng), 胡說八道, 喜歡的人歡迎關(guān)注公眾號, 如果覺得我說的不對, 想要跟我理論一番的同學(xué), 也歡迎關(guān)注公眾號, 私信我.

總結(jié)

以上是生活随笔為你收集整理的vc++ mfc 非客户区 描绘线_决战客户端技术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。