决战客户端技术 决战 服务端

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

后记

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

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