決戰客戶端技術

原文連接-決戰客戶端技術     

  最近常常有小夥伴問我要作一個客戶端, 該怎麼弄. 這個問題問得很粗獷, 可是實際上客戶端的選型是一個很細的問題. 從大學到如今, 也弄了很多的客戶端, 從公司主營炒股專業客戶端, 到內部項目使用的OA客戶端, 還有大學的時候爲了畢業而弄的QT, 各式各樣, 這裏就給你們講解一下, 我所瞭解的幾種客戶端的選型(這裏主要針對windows，也會說起一些跨平臺技術).

  windows下的客戶端都是基於win32, 在這基礎上, 咱們能夠細分爲, 原生win32, MFC, C#(語言封裝), 高級win32-duilib, QT, CEF, electron(nwjs) 大致就這幾種了, 其中不少是重合的, 下面咱們就每一個都講一講優劣.

原生win32

• 優勢

  上面也說了, windows下全部的東西, 都是win32的, 它就像建房子用的磚同樣, 能夠用它作出任何咱們想要的東西, 幾乎是無所不能, 並且它是基於消息驅動的, 性能很是高.

• 缺點

  優勢很好, 缺點也很是明顯, 太底層了, 所有都是C的接口, 若是要實現複雜的效果, 全部的東西都要本身寫, 會把代碼寫得很是複雜, 不是簡簡單單就能弄好的, 並且維護成本巨大, 很是不建議使用, 若是是中小公司, 要作客戶端, 沒有必定的實力, 千萬不要去踩這個坑.

MFC

  MFC是微軟本身開源的一套UI框架, 大可能是基於本身作的東西，給出了一套通用的解決方案.

• 優勢

  封裝度高, 大多咱們要的組件, 都有現成的使用, 修改起來也方便, 並且也是用的消息驅動型, 性能高.

• 缺點

  雖說是C++的, 可是裏面C和C++混着用, 腦子有點很差使, 並且除開那些共有組件以外, 其餘的組件, 寫起來也是很麻煩, 對程序員的要求也是比較高的, 如今不多有人再使用MFC了, 至少我身邊算是比較少的.

csharp

  這個就不能說優缺點了, 語言級別的不同, 雖然底層都調用win32的東西, 可是已是徹底面向對象的封裝了, 這個運行機制也不同, 消息已經都被封裝了, 更多的是回調和反射. 總體來講對程序員友好, 文檔齊全, 寫起來很流暢. csharp是一門很是優雅的語言, 用它來寫客戶端也是很流暢的, 並且csharp有不少第三方組件, 收費的, 不收費的, 國內的, 國外的均可以作到開箱即用, 方便極致. 固然也有很差的地方, 就是依賴於.net, 全部的用戶必須安裝.net, 並且還有不一樣版本的兼容問題, 若是用戶的環境是不受你控制的, 建議仍是不要用的好.

高級win32-duilib

  duilib是我特別想向你們推薦的一個C++UI庫, 作的很是的好, 提供了相似於html, css相似的封裝, 固然它是基於xml的, 我司的主營炒股軟件就是本身維護的一個duilib庫. 並且許多像騰訊, 網易都有使用. 如今主流的方案都是duilib + CEF, 或者win32 + CEF這種混合的解決方案.

• 優勢

  高度封裝, 類html的文件, 咱們能夠在上面快速實現複雜的效果, 同時它支持自繪, 能夠擴展咱們想要的功能, 消息驅動型, 性能高, 若是是中小企業, 而且對UI的性能以及效率要求很是高, 這裏強烈推薦此方案.

• 缺點

  文檔缺失, 幾乎各個大的公司都維護了一套本身的duilib版本, 缺乏統一的標準, 在接觸初版本的duilib的時候, 幾乎都是看代碼查特性. 對開發者要求也是挺高的, 若是想要重度使用, 幾乎要通讀整個庫的代碼的, 不過這個庫封裝的很是好, 也很簡潔, 讀懂不是什麼難事.

QT

• 優勢

  跨平臺, 面向對象, 性能高, 很是良好的文檔, 類html的佈局, 幾乎能實現你想要的全部的東西.

• 缺點

  學習路徑比較陡峭, 並且重, 編譯出來的東西會比較大, QT的東西都是自成體系的, 若是之前沒有用過QT, 學習起來會比較難以接受.

CEF

  與其說它是一門獨立的技術, 其實它更像一個組件, 一個網頁的組件, 可是它太強大了, 以致於光用這個組件, 就能夠實現全部的功能了.   CEF全稱Chromium Embedded Framework, 是一款基於Chromium瀏覽器的嵌入式框架, 說白了就是一個dll, 它提供了一套接口, 使用這套接口, 你能夠控制整個網頁, 以及裏面幾乎全部的東西, 整個頁面交互都由你控制, 效果很是好.   咱們的客戶端裏面或多或少須要涉及跟網頁的交互, 無論什麼理由, 在CEF以前, 幾乎採用的都是window提供的IE組件, 而後實現一堆的com接口, 可是這種方案有個很大的問題, 就是太依賴用戶的環境, 用戶環境很是惡劣, 各類ghost系統, 閹割版系統, 組件缺失, 環境變量不一致, 最後致使的問題就是程序各類奔潰,更爲噁心的是, 這種奔潰是無法經過代碼解決的, CEF的出現, 簡直就是救星, 自從咱們公司軟件使用CEF以後, 奔潰的機率只有原來的1/10, 極大的提升了用戶體驗.

• 優勢

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

• 缺點

  重, 耗內存, 你們都懂chrome就是內存大戶, 軟件裏面嵌入一個chrome, 內存就蹭蹭蹭的往上漲, 隨隨便便增長個幾百兆的內存是常常的事, 這是個很現實的問題, 由於這個內存問題, 咱們軟件至今維護了一個非CEF的版本, 給那些不肯意升級的用戶使用. 可是我的以爲隨着科技的發展, 硬件的更新迭代, 這種問題都不會是問題, 更況且巨硬加入chromium的陣營, 極可能會解決這種內存問題.

electron(nwjs)

  electron和nwjs是同一類東西, nwjs出得更早, 可是如今electron使用的更普遍. 依稀記得15年剛接觸nwjs的時候的那種心裏的激動, 感受發現新大陸同樣, 它的確就是新大陸, 如今的vscode, atom等等, 都是基於electron的應用.   electron 和 CEF同樣，也是chromium系列的, 可是CEF是經過封裝接口, 而後由chromium回調到本身的程序, 驅動整個程序運行, electron則是在chromium的基礎之上, 再嵌入一了個js執行的v8引擎, 由此v8引擎與chromium內部的v8進行信號的交互, 驅動程序運行, 兩種是大相徑庭的方式. 並且electron是已經一個徹底獨立的客戶端, 不須要像CEF同樣, 寄宿在其餘程序內部.

• 優勢

  跨平臺, 很是良好的交互體驗, 徹底的網頁編程, 起點低, 不須要有任何C++編程的經驗, 就能夠開發一個完整的, 高體驗的客戶端, 支持C++擴展. 各類簡單高效, 簡直就是開發利器.

• 缺點

    重, 內存高, 性能差, 各類黑箱操做, 若是程序掛了, 徹底就是一籌莫展. 早期的版本很是不妥當, 很容易就crash了, 15年在調研了這種技術以後, 咱們在新的項目上使用了nwjs, 奔潰問題太嚴重了, 徹底一籌莫展, 後面咱們拉下來整個nwjs的代碼, 本身編譯整個項目以後, 才略微猜到問題, 前先後後花了兩個C++程序員, 大概半個月的時間, 很是不可控, 以致於咱們放棄了這種方案, 新版的程序, 採用了duilib + CEF的方案. 但如今已通過了好久了, vscode和atom已經幫咱們躺過大部分坑了, 我相信如今electron是很是穩定的.

技術選型

  electron向咱們描繪了很是美好的前景, 大概就是前端統治一切, 前景很美好, 實際上卻不是那麼優雅, electron暫時性能是比較差的, 緣由很簡單, 單線程跑, 你能跑多快啊. 若是徹底沒有C++功底, 無腦推薦electron, 若是有C++功底, 仍是建議使用duilib + CEF. 若是想作跨平臺, QT是最好的選擇, 技術若是不錯就用QT + CEF. 若是是細心的人會發現QQ是用了CEF的, 微信是duilib + CEF, 網易雲音樂前端是全CEF的, 釘釘是duilib + CEF, 咱們平常用的這幾大軟件, 幾乎都是這麼個架構, 好像也沒什麼太多選擇.

後記

  寫完這篇文章以後, 經同事指正, 認爲寫的太泛, 應該把每一類拆出來, 單獨爲一篇, 而後從技術路線, 實現效果, 運維成本, 以及總體企業成本等方面展開描述. 若是真這樣的話, 要寫的內容就多了, 後面就在微信公衆號裏面更新這個系列吧, 歡迎關注公衆號-雀觀代碼.

  以上純粹一本正經, 胡說八道, 喜歡的人歡迎關注公衆號, 若是以爲我說的不對, 想要跟我理論一番的同窗, 也歡迎關注公衆號, 私信我.