共计 6386 个字符，预计需要花费 16 分钟才能阅读完成。
* 本文基于海康威视桌面端技术专家刘晓伦在「RTC Dev Meetup • 杭州站丨大前端时代的业务架构和跨端实际」流动中分享内容二次整顿。
以下注释：
明天要与大家分享 19 款桌面软件开发框架，我将它们分了四类，而后别离就每个类别做相应的介绍，心愿通过明天的分享，帮忙大家在开发的过程当中少走一些弯路。
01 传统桌面软件开发框架
首先咱们来聊一聊传统的桌面软件开发框架。这个类别中蕴含大家常见的 Qt、wxWidgets、GTK、FLTK、Swing 和 JavaFX。这六个框架有一些共同点：它们的历史都很悠久，应用的开发者也很多，并且相应的社区也很成熟，其中蕴含了丰盛的材料。此外，它们的性能都很弱小，有大量成熟的案例，框架也很稳固。
然而它们用到的都是 相对来说都是比拟成熟的技术，所以跟新兴技术之间还是有所差距，所以应用起来比拟艰难。
1、Qt
Qt 的长处大家都能够在官网上看到，这里不再赘述，其中有一点是 Qt 对各操作系统都做了很欠缺的封装，比方网络、文件剪切板等，如果要用零碎级的 API，Qt 能够提供的十分丰盛的 API。
对于 Qt 的问题这里介绍一下我的感触，我认为 Qt 目前的问题是 倒退方向不太专一，无奈提供某些较大的模块，在开发过程中可能会逐步发现应用的模块不太适合，进而废除这个模块，包含很多 API 也是这样，我之前用过的 Qt script 当初就曾经被标记为废除了。
另外，Qt 的商业受权是不太敌对的。如果要开发一个商业利用，可能这里要留神一下，有很多国内的公司都是收到过 Qt 的律师函要求免费的。Qt 还提供了很多组件，其中有一些简单的组件对于管制 UI 的细节是比拟难的，这里就不再举例了。
Qt 还有很多的动态链接库，如果要做动态链接也是比拟难的，当然社区中提供了一种方法，就是能够编译 Qt 的源码做动态链接，然而这就又要波及版权的问题了。
2、GTK
GTK 框架比拟偏 Linux，在 Linux 中有很多桌面利用都是用 GTK 开发的，在 Windows 下 GTK 绝对较少，并且在 Windows 零碎下的动态链接也是比拟难的，甚至搭环境都比在 Linux 零碎下要难得多。
另外，GTK 在 Windows 下也做了零碎 API 的封装，然而在 Windows 下的封装比在 Linux 零碎下的封装要少一些。也就是说，有些 API 在 Linux 下能用，而在 Windows 下是不能用的，这样的 API 不在少数。最初 GTK 的商业受权是十分敌对的。
3、FLTK
FLTK 框架是 C++ 之父举荐应用的，它就是一个十分轻量的 GUI 框架，然而 轻量意味着性能是有余的，它的性能比拟少，简直不做零碎 API 的封装，大部分都要开发人员本人用 C++ 编写。这样导致开发人员在每个平台上都要从新编写，比方要凋谢一个跨平台的图片利用，那么在 Windows 下调用一些零碎级的 API 进行实现，在 Mac 下可能又要实现一遍。
FLTK 的长处是它的产物很小，因而 它编译进去的货色能够做到很小，而且性能也十分好（比前两个都好）。FLTK 的商业受权也很敌对，能够反对动态链接。然而 FLTK 有一些有余，就是因为它是一个 GUI 框架，因而在绘制 GUI 组件这方面是不太好的。
我在应用 FLTK 的时候发现，在其中做动画管制、组件叠加（这时用到就是相对定位，就须要对组件的层级进行管制）都会遇到问题。另外，在绘制圆角的时候，尽管 FLTK 提供了相干的性能，然而用户还要管制圆角的非凡大小、某一个圆角呈现等，这些都要写非常复杂的代码。
4、wxWidgets
wxWidgets 跟后面 3 个框架有所区别，它是基于操作系统的 API 来做桌面利用的，也就是说，在 Windows 下开发一个桌面利用时，看起来就像是传统的 Windows 桌面软件的格调，在 Mac 下则是 Mac 的格调，而后面三个都有本人的自绘引擎。
也就是说，在后面三个框架中做一个按钮，不论用什么样的绘制形式，在三个平台下体现都是统一的，然而 wxWidgets 在三个平台上都是依照三个平台本人的 API 来绘制这个按钮的。wxWidgets 提供了十分多的操作系统的 API，并且能够做到动态链接，但小问题比拟多。
5、Swing/JavaFX
Swing /JavaFX 是基于 Java 的技术栈来做桌面利用的，因为要依赖 JVM，所以零碎 API 比拟多，但性能会个别，这两个框架可能相对来说用得少一些。
如果大家在这几个桌面软件框架当中做抉择的话，我集体举荐还是用 Qt。
02 新兴桌面软件开发框架
方才咱们说的一些框架可能用的技术比拟古老，大家开发起来比拟麻烦。新兴的框架，比方微软的 MAUI、谷歌的 Flutter Desktop 和 JetBrains 公司的 Compose Multiplatform，都是采纳十分新的技术来做的，开发起来很容易，开发体验也十分好。
然而因为这几个框架都比拟新，基本上都是往年公布的正式版（最早是 Compose Multiplatform 公布的，而后顺次是 lutter Desktop 和 MAUI），所以 社区相对来说不如后面几个框架成熟，材料和胜利案例也相对来说少一些。
1、MAUI
MAUI 是用 XAML 是写界面和逻辑的，大家如果用 WPF 写过软件的话，应该会对这项技术很相熟。MAUI 用 C# 编写业务逻辑，只兼容 Windows 操作系统和 Mac 操作系统。MAUI 在 Linux 下是社区提供的一套反对体系，可能会有一些问题。另外，MAUI 是依赖 .NET 框架的，API 比拟多，并且反对挪动端（这三个框架都是反对挪动端的，新兴的开发框架都兼容挪动端的开发）。
2、Flutter Desktop
Flutter Desktop 是应用 dart 编写界面逻辑的，它的组件比拟丰盛，并且反对 Win 10 操作系统（之前的操作系统就不太反对了），API 是比拟少的，须要开发人员本人来写。
3、Compose Multiplatform
Compose Multiplatform 依赖 JVM，是用 Kotlin 编写逻辑的界面和逻辑的，有音讯说未来可能会推出 Kotlin/native*，这样就能够不必依赖 JVM 了，然而这可能还比拟边远的事件。Compose Multiplatform 的组件也是比拟丰盛的，大家都晓得 Java 社区中有很多框架、模块等都能够应用，并且也是反对利用端的。
在这几类框架里中我举荐大家应用 Flutter Desktop，尽管它们都是新兴的框架，所以很难说哪一个未来会更受欢迎，然而依据它们的共同点（技术更现代化、更加易用、材料较少、社区不成熟、胜利案例较少、用户较少、不稳固），我还是举荐 Flutter Desktop。
03 基于浏览器的桌面软件开发框架
基于浏览器的桌面软件开发框架绝对较多，比方 Electron、NW.js、CEF、Sciter、WebView2、webview 和 TAURI。其中应用 Electron 比拟多，也曾经十分成熟。它们的共同点是它们能够复用浏览器的技术，比方 html、JS 和 CSS 等一系列生态中的组件。
除此之外，它们还能够做十分壮丽的界面，因为 Web 技术倒退这么年，CSS、html 等在标记和管制界面个性方面的技术都曾经十分成熟，不像方才提到的 FLTK 要做叠加动画成果都十分艰难，如果用这些技术做这些界面会十分从容。但这些框架的性能也是有强有弱。
1、Electron/NW.js
Electron 和 NW.js 这两个框架是十分类似的技术，它们都是把 Chromium 与 Node.js 集成到一起，让开发者能够只应用前端技术开发桌面利用。如果要拜访零碎的 API，就用 Node.js 提供的 API，当然也有一些非凡的 API，比如创立桌面图标、拜访剪切板、管制窗口大小等，是 Electron 框架自身提供的，而不是 Node.js 提供的，也不是传统 HTML 零碎提供的，是在其中做了一些附加的操作，当然 NW.js 也有。
这两个框架的作者都有很深的渊源，这里就不细说了。我集体感觉 NW.js 实现起来相对来说比拟奇妙，对开发者比拟敌对，而 Electron 保护更给力，社区也很宏大。
2、CEF/WebView2
CEF 和 WebView2 框架都是间接基于 Chromium 开发的。CEF 的历史比拟悠久，而且更灵便，大家能够通过这个框架进行自在的管制，API 也更多。
WebView2 是微软的短期团队提供的一个框架，这个框架也是间接基于基于 Chromium 做的封装，它提供了 .NET 和 C++ 的 API，大家能够用 .NET、C++ 或者 C# 语言去操作这个框架，目前还不反对 MAC（未来可能会反对）。
相对来说 CEF 更像作者集体在保护，WebView2 就更像一个团队，然而因为 WebView2 不开源，所以也没法参加。
3、webview/TAURI
webview 和 TAURI 应用操作系统内配置的浏览器外围，比方应该在 Windows 下部署，那么就用 WebView2；如果在 Mac 下部署，就用 WKWebView；如果在 Linux 下部署，就用 webkitgtk 来做渲染，因而这里可能就会有一些兼容性的问题。
在做前端的时候常常会碰到一些兼容性的问题，然而目前来看，因为它们都是比拟古代的浏览器外围了，所以这个问题还没有这么显著。另外，TAURI 是使⽤ Rust 开发的，如果要抉择这个框架，可能还得相熟 Rust 语言。
4、Sciter
Sciter 是一个比拟非凡的框架，这里把它单列进去，Sciter 做了很多的削减，能够把产物的体积缩减到 10M 以内，后面几种框架基本上只有把浏览器外围分发给用户，即便压缩过后也得 60M。
Sciter 以前有一个本人的脚本叫 TIscript，当初用的是 QuickJS，它的性能十分弱小，而且集成了 skia 的外围版本。我不晓得大家有没有关注过一个叫作 rustdesk 的我的项目，之前它抉择的就是 Sciter 框架，当然这个框架的小问题也会比拟多。
如果大家抉择这类框架，我举荐应用 Electron/CEF 框架。如果团队中没有 C++ 开发人员，或者不易于应用 C++ 进行开发利用，就抉择 Electron；如果有 C++ 开发人员，而且利用十分重视性能，就抉择 CEF。
04 即时渲染桌面软件开发框架
即时渲染绝对利用的是放弃模式的桌面利用框架，个别做桌面利用都是哪里须要更新，就更新哪里，框架会进行渲染。然而即时渲染是不一样的，它是每刷新一帧，就会把显示的内容都更新一遍，也就是说每一帧都会全副更新一遍。
所以 这类框架有一个独特的特点，就是它们要耗费 CPU 和 GPU 资源，传统框架的配置都是放弃模式，如果不更新是不会做渲染的。另外，这种框架与游戏利用能够无缝对接，然而传统利用案例比拟少，小问题比拟多，且尚在倒退中。
1、Dear ImGui
即时渲染桌面软件开发框架中，Dear ImGui 比拟风行，最近作者在开发 Dock 模式，预计往年有可能会推出，到时候大家能够去尝试一下。
它的开发方式是比拟特地的，就是每个循环都在做渲染。比方应用 Dear ImGui 做事件开发时，会将某一个变量设置为 true 或者 false, 在这一轮渲染的过程当中是 true，在它下一轮渲染过程当中，我发现变成 false 了，咱们就认为触发了某个事件。而不是像 web 开发畛域中，当呈现一个 event 时，另一个组件就能够接管到它。
2、Nuklear
Nuklear 是使⽤ C 语⾔开发的，更贴近 C 开发者的习惯，⽤户绝对 Dear ImGui 更少、⼩问题更多。
3、RmIui
RmlUi 比拟非凡，它不是即时渲染框架，然而却有即时渲染框架的通病，就是用它开发利用之后会继续耗费 CPU 和 GPU 资源，它能够应用 HTML 和 CSS 形容界面，上手绝对比拟难，开发非常灵活，界面也很灵便，资源耗费绝对更多。
我最近始终在用这个框架，也跟作者进行了深刻的交换。这个框架开发进去的应用程序能够做到 2M 左右，它能够解析你的 HTML，做一些十分非凡的成果，比方暗影、突变之类的动画，然而它很小，不像浏览器一样，即便压缩也得 60 多兆，这也是它的劣势。
这几类框架中我集体举荐 RmlUi，如果到作者的我的项目中进行发问，他基本上隔天就会回复。
05 总结
在做总结之前，我先简述一下这几个框架的比照。
其实咱们在介绍传统的桌面开发框架的时候，Qt 和 wxWidgets 内置的组件也有基于浏览器的，就是 QWebEngin 和 wxWebView，QWebEngin 封装的是 Chromium 的外围，其实与 CEF 和 QWebEngin 挺像的，然而很多人在用 Qt 的时候，是把 CEF 集成到 Qt 中，反而不必 QWebEngin。
他们保持的观点就是 QWebEngin 还不成熟，性能力绝对来较弱，不如 CEF，然而目前来看，我集体认为，在 Qt 6.2 和 Qt 6.3 之后，QWebEngin 的 API 会更多，利用的需要更容易满足。
wxWebView 更像是 webview 和 TAURI，它也是在不同的操作系统上应用操作系统的浏览器外围，这里就不多说了。
再看一下 RmlUi 和 Sciter 的比照。RmlUi 能够用 html 和 CSS，Sciter 也能够用 html 和 CSS，因为 Sciter 集成了 QuickJS，所以它也能够写 JS 代码（然而也得写 C++，因为你不可能不必操作系统的 API，然而它的 C++ 可能会比 RmlUi 的 C++ 代码量要少很多）。两个框架都不反对全副的 html 和 CSS 标准。
如果要选一个桌面软件开发框架，应该确认偏重哪方面的能力，我认为有三方面的能力是须要重视的：
- 界面的形容能力：比方布局、元素定位、圆角、暗影、突变
- 事件处理能力：比方鼠标事件、键盘事件、触屏事件、媒体播放完结、网络状态变更等
- 异步解决能力：解决业务逻辑的时候，界面渲染工作不能暂停
另外，桌面软件开发框架各有各的劣势，比方软件开发逻辑很简单，而且要疾速地实现，那么 BrowserCore 可能是一个不错的形式，因为用前端技术来编写速度更快，然而如果软件须要更少的资源耗费和更快的运行速度，那么就须要思考 Native 形式。
最初，要做桌面利用开发须要理解一些底层常识，比方多线程、多过程的管制；各种通信协议；⽇志收集；版本控制；设计模式与架构准则；本地数据管制；操作系统。
06 问答环节
1、用 Electron 怎么解决 crash？
Electron 也有十分多问题，它也会解体，并且有解体报告的收集形式，收集这些报告之后还要进行剖析，然而剖析进去的解体报告实并不能很明确地反映到底是哪一行代码、哪一段业务出了问题。很多时候解体报告中可能更多的是阐明一个指针指向的内存呈现了问题，这时一种办法是尽量分割用户复现问题；第二种形式是做大量的自动化测试，收窄问题的范畴，将其局限在肯定的范畴内再做精细化解决；第三种形式就是做 AB 测试。
2、Electron 开发的利用安装包太大这个问题有没有好的解决办法。另外，开发者该如何开发 Electron 利用的守护过程。
这是两个问题。第一个问题就是包太大的问题，这个其实是挺难解决的，在立项之前就应该跟团队负责人沟通好需要，是要疾速的业务开发，还是更高的性能，更小的体积？如果要更小的体积，那么就放弃业务开发效率。能够应用 C++ 做一些工作，只是会耗费更长的工夫和更多的资源。在打包的时候，要先确认是否用的是 LZMA 压缩格局，这种格局能够压缩得更小一点，然而小不了多少，最低可能还是 60 多兆。
至于怎么做守护过程，这个问题当初有两种方法，一种是写一个独立的利用，在 Electron 启动的时候利用就能够随之启动，而后它守护 Electron 过程。如果 Electron 过程解体的时候，就由它来启动 Electron 过程。
另一种办法是剖析利用为什么解体，是主过程解体了，还是渲染的时候解体了，你如果主过程解体了，尽量还是要找到其解体的起因，因为一旦主过程解体，那么所有渲染都会失败；如果是渲染过程解体了，那么能够在主过程中关上一个其余的过程，来保障将渲染解体的告诉发送给用户，由用户重启渲染过程，或者主动重启。
