作者：ayuliao
前言
因个人兴趣，想着开发一个桌面应用软件，其具体定位是：RPA，相关的商业软件有很多，我了解使用过的几个：UiPath、UiBot、影刀 RPA。
什么是 RPA?其全称为 Robotic Process Automation(机器人流程自动化)，简单而言就是让计算机帮助我们执行各种重复性高的工作，对于行政、金融、政府等人力密集型部门，RPA 是很好的助力。
最近几年，RPA 相关赛道的公司融资都很猛，通常都是亿级的融资，因为我之前在公司负责过自动化工具相关的工作，所以一直有关注自动化相关的各种技术，其中 RPA 是我关注的重点，观察下来，各种 RPA 商业应用其技术实现难度不算特别大，虽然其功能很多，但感觉慢慢从基础功能搞，还可以够得着，所以一直有打算开发一个的想法。
这篇文章是第一步，对比一下目前桌面端技术栈，做技术选型。
PS: 熟悉我的朋友知道我之前使用 Electron Vue 开发过抖直播这个应用，但 RPA 软件需要更多系统层的支持，我在调研前，会疑惑 Electron 对系统 API 的兼容情况以及是否有更好的方案，所以还是花时间调研了一下。
当然，做事情前先明确目标：
- 我希望可以构建出一个跨平台的 RPA 桌面应用，目前多数商业 RPA 软件都局限在 Windows 平台(即只有 exe 安装包)。
- 因为 RPA 需要很多系统级的功能，所以我希望可以比较轻松的试验系统 API。
- 因为时间、精力和能力的问题，我希望可以基于自己已有技术栈之上来开发。
常见桌面端开发技术栈
通过微信、QQ 等各种桌面端应用，可以了解目前开发桌面端的主流技术栈，简单总结一下：
1.使用 C# WPF 依旧是开发 Windows 桌面应用的主流选择，其优点是：比较成熟，参考资料比较多，其缺点是：性能一般，需要用户主动安装 net 库，虽然很多软件会直接提供下载，然后让用户安装，但依旧是一个坎，此外 WPF 只支持 Windows 平台，与目标不符。
2.C QT 也是很多人的选择，QT 是否成熟，但比较重，适合开发大型应用，对于个人开发者而言，效率不高，此外我除了大学时用 C 参加过算法比赛外，很少再使用过。
3.在 Windows 平台下，国内多个大众应用，如微信、QQ、百度网盘都使用了 C 类duilib 的形式进行开发(类 duilib 的意思是，基于开源的 duilib 这个 Windows GUI 进行了二开)，这种方式出的桌面应用，性能较高而且包的体积下，是专业团队比较好的选择，但不适合我这个项目，因为 RPA 并不要求太高的性能，而且我希望一份代码可以跨平台使用。
4.影刀等商业 RPA 软件使用了 C CEF 的形式开发，CEF(Chromium Embedde FrameWork)与 Electron 定位类似，基于 Chromium，让开发者可以使用前端技术栈来构建桌面应用，跨平台，就是 CEF 资料比较少，还需要 C 等知识，因为是对标软件使用的技术，所以加入候选技术栈。
5.VScode、Github 桌面端等使用 Electron 开发，与 CEF 类似，Electron 让我们使用前端技术便可以开发桌面应用，其优点是：资料很多、开发效果比较 OK，缺点是慢，而且对于需要比较多系统 API 的兼容因没有对标软件，所以不太好确定。
6.Flutter 是 Google 推出了全平台开发框架，支持 windows、macos、android、ios 甚至是汽车中的系统，调研下来的结论是，Flutter 对跨平台的支持还非常早期，很多系统层的 API 并不支持，生态也刚起步，与 npm 比不了，很多东西可能要自己造，所以也不考虑。
CEF 与 Electron 的比较
CEF github: https://github.com/chromiumembedded/cef (1.6k star) Electron github: https://github.com/electron/electron (101k star)。
从 Github 上看，Electron 的活跃度远高于 CEF，包括：版本更新频率(解决 issue 的速度、新功能的开发速度)、社群活跃度(资料丰富度)。
那为啥有些商业产品要选择 CEF 呢?其优势在哪?对目前想开发的项目来说，是否重要?
相比于 Electron，CEF 支持 Windows XP 系统，提供的很多比较底层的 C API 方便你使用系统级能力，而且也很方便与 Native UI 框架融合使用，实现更近似本地应用的应用。
简单而言，使用 CEF，相比于 Electron 可以更轻松的做的更像原生软件，除了不支持 Windows XP 这个硬伤，Electron 其实可以通过 C 的方式调用更多系统级的原生能力，但这要求你对 Electron 框架源码比较熟悉，当然也要会写 C 代码。
那 Windows XP 系统目前占用量大吗?查阅了一下，Windows XP 在 2020 年，市场占有率已经低于 1%，所以我还是偏向于选择 Electron 进行 RPA 桌面应用的开发。
所以剩余的问题，便是加强对 Electron 的把控感。
Electron 开发需要考虑的问题
1.因为 Electron 本身架构的原因，Electron 打出来的包会比较大，但就目前个人电脑的性能而言，也不算什么特别大的问题，就像现在手机游戏一样，反正手机性能过剩，一些比较难搞的优化直接就放弃了，但在开发时，还是尽量精简 require，从而让 Electron 打出的包小一点。
2.Electron 对源码是没有保护的，即你开发的软件，很容易别人逆向分析，有几个解决方案，除了方案 c，都可以逆向破解，这些操作只是让可破解的人少一点而已(当然，最安全的方式是你的软件没有任何价值，放到 Github 都没人 fork)。
- a. 使用 C 编写核心逻辑，发布时，C 是编译后的二进制文件
- b. 使用 wasm 编写核心逻辑，发布时，也是二进制内容
- c. 核心逻辑放在后端
- d. 使用 bytenode 将代码转成字节码
3.Electron 对系统层能力的使用可能比较弱，此时需要求助 Python、C 、C# 等语言，通过 ffi-napi 库可以让 Node.js 使用 C dll，通过 electron-edge-js 库可以让 Node.js 使用 C# dll。
参考
- 开发桌面应用是用 flutter 还是用 electron
https://www.zhihu.com/question/390186321
- macOS 上 Flutter Desktop 与 Electron 的性能对比
https://juejin.cn/post/7018450473292136456
- 对比跨平台客户端方案：Electron 和 CEF
https://blog.csdn.net/caperxi/article/details/115901659
- 桌面端框架 Electron 使用问题整理和总结
https://juejin.cn/post/6844904072743501831
来源： 懒编程
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。