决战客户端技术

原文连接-决战客户端技术     

  最近常常有小伙伴问我要作一个客户端, 该怎么弄. 这个问题问得很粗犷, 可是实际上客户端的选型是一个很细的问题. 从大学到如今, 也弄了很多的客户端, 从公司主营炒股专业客户端, 到内部项目使用的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, 咱们平常用的这几大软件, 几乎都是这么个架构, 好像也没什么太多选择.

后记

  写完这篇文章以后, 经同事指正, 认为写的太泛, 应该把每一类拆出来, 单独为一篇, 而后从技术路线, 实现效果, 运维成本, 以及总体企业成本等方面展开描述. 若是真这样的话, 要写的内容就多了, 后面就在微信公众号里面更新这个系列吧, 欢迎关注公众号-雀观代码.

  以上纯粹一本正经, 胡说八道, 喜欢的人欢迎关注公众号, 若是以为我说的不对, 想要跟我理论一番的同窗, 也欢迎关注公众号, 私信我.