前言

本文全部是作者的个人经历，不是从官网随便抄袭的。

Qt

它几乎是C++领域最流行的跨平台桌面软件开发框架。

这个框架是由两位挪威人于1995年创建的，历史悠久，稳定性有保证。

很多大公司都在用它来做界面，比如金山的WPS。

它内置了自绘制引擎，也就是说界面上的一个按钮、一个文本框都是由Qt引擎自己绘制的。 这保证了基于Qt开发的软件界面在不同的操作系统上看起来完全一样。

它提供了大量与接口无关但与软件开发密切相关的API，如网络、文件系统、剪贴板等，并使这些API在不同操作系统下有效，极大地节省了开发者的开发成本。时间。 时间。

但它也有一些缺点，比如处理一些特殊需求非常不方便。 例如：Qt目前对于在高分辨率屏幕上缩放显示有更好的解决方案吗？ ，Qt难道没有真正完美的无边界解决方案吗？ 等待，

一些组件的渲染也会存在一些隐藏的、深层的问题（），一旦遇到就很难解决。

Qt这几年已经不太具体了，开发了很多qml等，而这些新东西却一直不温不火。 有些模块开发了然后就废弃了，比如：qt，开发了一遍又一遍，开发的模块众多且复杂。 ，使用起来不是很舒服。

Qt有界面描述语言（XML描述界面），通过设计器拖拽空格即可设计。 接口描述语言在编译时转义为C++代码，因此性能没有损失。

Qt的商业许可并不友好，因此开发商业应用程序时必须谨慎。 听说有些公司为此支付了高额专利费。 个人开发者可以免费使用。

免费版本的Qt不允许静态链接，并且会有版权限制，但开发者仍然可以通过一些特殊的编译方法静态链接Qt库。

除了使用C++来开发Qt应用程序之外，开发人员还可以使用其他语言来开发Qt应用程序。

最流行的一种是使用 PyQt 制作 Qt 应用程序。 对其他语言的绑定还不是很成熟，但PyQt仍然存在版权问题。

GTK

](%3A///)

GTK创建于1997年，非常成熟和稳定。

它是用C语言开发的，但是有很多语言绑定，比如官方支持的，Rust等，当然用C++语言操作GTK也很方便。

它还具有自绘图引擎（）并提供了大量系统相关的API。

商业许可也非常友好。 基于GTK开发商业软件时，你不必担心收到律师函。

虽然它是一个跨平台的桌面软件，但它似乎只在操作系统领域流行。 基于GTK开发的桌面软件有很多。

这也直接导致了GTK的维护者们非常重视该领域的发展而忽视了Mac领域。

这个框架提供的很多API只能在Mac下使用，而在Mac下则不可用。 这样的 API 有很多。

即使是编译 GTK 的源代码也比下载困难得多。

而且GTK的渲染引擎的性能也大不如前了。

GTK 不能静态连接到 。 这并不是因为版权问题，而是因为它依赖于一些库。 该库用于模拟上的环境。 这也是GTK在互联网上表现不佳的原因之一。

另外，由于GTK是用C语言开发的，所以开发风格也很C语言，这对于一些开发者来说可能会比较麻烦。

它是英国一位大学教授在1992年创建的跨平台GUI软件，也非常成熟稳定，商业授权也非常友好。

它没有自绘引擎，而是集成封装了不同平台上的接口API。

这样，开发者开发的软件看起来就像风格，开发出来的软件看起来也像风格。

对于某些软件来说，这正是他们想要的，但是要创建一些花哨的特效却不是那么容易的。 它还提供了大量系统相关的API供开发者使用。

它是用C++开发的，所以对C++开发者非常友好，

此外，它还支持静态链接，这意味着您不需要向用户分发大量的dll来开发应用程序。

它会有一些小问题，比如我之前提到的：emit，但总体来说还是很稳定的。

除了开发的界面比较死板之外，没有什么大问题。

FLTK

](%3A///)

FLTK是一个创建于1998年的跨平台开源GUI框架，历史悠久，已获得商业许可，也被C++之父所使用。

它非常轻量级并且支持静态连接。 一个简单的应用程序编译后只需要500K左右，非常不错了。

它有自己的自绘图引擎，它使用：

但它的重画机制是按区域重画的。 如果组件B存在于组件A所在的区域，那么当组件A重绘时，组件B也会被重绘。 开发人员必须编写自己的代码来处理这个问题。 健康）状况。

想象一下，如果要实现A组件同时淡出、B组件同时淡入的效果，那会很麻烦。

FLTK提供的一些组件样式比较死板，绘图API也比较少。

如果你想实现一个更漂亮的圆角按钮（内置圆角按钮的圆角大小不能改变），你就得自己画，而且还得用一些很奇怪的方法（如果你想知道的可以联系我）

它是用C++开发的，但是API不够现代，一般来说用起来很舒服。

它有 Rust 绑定：fltk-rs。 它提供了一些与接口无关的操作系统API，但数量很少，几乎可以忽略不计。

是国内开发者于2010年开发的GUI开发框架。

因为底层是基于开发的，所以只支持平台，不支持跨平台。

开源协议友好，商业使用没有问题（需要额外文件），

国内有很多基于该技术开发桌面应用的主要厂商，如网易、腾讯、百度等。

该框架基于C++开发，对C++开发者友好。

不过框架本身还是存在一些问题，比如对高分辨率屏幕的支持较差，以及特殊控件绘制方面的一些小问题。

除了接口相关的API外，几乎没有提供系统级的API。 作者纯粹使用来开发这个框架，所以更新不是很及时。

相对而言，网易的开发型分支更加完整：增加了高分辨率屏幕支持、多种语言、集成多线程处理支持。

但环境搭建比较麻烦。 如果开发者想要使用这个框架，就必须使用该分支下的代码。 分支下的代码有很多问题。 这个框架似乎是作者一个人努力的结果。

](%3A///)

它是一个2006年创建的跨平台闭源GUI框架，足够稳定。

对商业授权不太友好，但个人开发者可以随意使用（只能使用动态链接库）。 一旦公司规模超过3人，就必须购买版权（并拥有静态链接权）。

它内部密封了浏览器核心，但已经大大精简。 与NW.js轻松达到数百兆大小不同，它只需要6M左右。 我记得底层的绘图引擎是的skia。

开发人员可以使用 HTML、CSS 和 JS 来创建界面。 当然，由于底层是浏览器核心的阉割版，这也意味着一些浏览器功能不被支持。

例如，它不支持CSS3的flex布局（但它提供了自己的flex布局实现）。

过去，它使用的是自行开发的脚本语言（与非常相似）。 自从集成的脚本语言后，就得到了全面的支持。

此外，它还内置了对一些特殊场景的支持，例如渲染大型列表。

它是用C++开发的，对C++开发者非常友好。 它有 Rust、go 等语言的绑定，但都是社区提供的，质量令人担忧。

很多知名厂商的接口都使用这个库，如360、360、等。

另一个库非常相似，可以被认为是一个替代框架，

但这个项目已经有三位作者了，他们都一一放弃了。 不知道新作者会不会放弃。 目前还不是很成熟。 例如，我正在尝试帮助作者解决CJK输入法的问题。 目前还不建议大家使用这个框架。 。

欧洲经济论坛

CEF成立于2008年，基于跨平台GUI框架，稳定且商业许可友好。

CEF被国内很多大厂商使用：如微信桌面、网易云音乐桌面（Win）、QQ桌面、微信桌面、、OBS，安装量过亿（太保守）。

由于它几乎是一个完整的包，因此体积非常大，但它支持所有 HTML\CSS\JS 功能。

它几乎不提供与操作系统相关的API。 创建托盘图标、读写文件等都必须由开发者自己完成。

它是用C/C++开发的，对C++用户非常友好。 它有go\\java等语言的绑定，但都是社区提供的，质量值得担心。

封装得很好，避免了开发者直接处理V8、V8等复杂代码。

许多函数都有默认的实现方法。 由于配置原则，经验丰富的C++开发人员可以轻松控制CEF框架。

由于我是版本哥，所以CEF版本发布非常频繁。 很多标记为稳定的版本仍然会存在一些莫名其妙的问题。 选择一个好的版本非常重要。

像，也分为主进程和渲染进程，所以开发者必须非常熟练的使用跨进程通信技术。

虽然CEF提供了跨进程相关的API，但是复杂度还是有点高，使用时一定要小心。

这是我写的关于掘金队 CEF 的一系列课程：

毛伊岛

这是微软的跨平台GUI框架。 它不仅支持桌面端，还支持移动端。 不过桌面版并没有得到官方支持（黑色问号感觉与微软近年来开放开源的总体政策相悖）。

这个框架太新了，还没有发布稳定版本。

它是.NET平台下的GUI框架。 它具有自绘图引擎，对C#开发人员非常友好。 该接口仍然以 XAML 进行描述。 很多人一听到XAML可能就放弃了。

XAML确实表现力较差。 我认为WPF不受欢迎与XAML有直接关系。

这是我个人的看法，相对而言（弱于HTML/CSS）。 很多人认为XAML很好，很有意义。 我无意与你争论，也无意改变我的原文。 请不要对此问题发表评论。

使用该框架开发桌面应用程序需要用户有.NET框架。 当然，通过.NET框架，应用程序可以访问通用的系统级API。

这是一个跨平台的GUI框架，而且非常新。 1.0.0版本刚刚推出不久。

但这个版本还不是很稳定，至少比第一个稳定版本差很多。 几乎没有人使用它。

它的自绘图引擎使用skia。 这个自绘引擎非常稳定。 两者和...

因此绘图、渲染和其他任务不太可能引起问题。 比Java生态系统中的那些要好得多。

当然，它对开发人员友好。 您可以使用 Java 生态系统中的许多东西。 访问系统级API没有什么大问题。 您还需要考虑阻止用户使用 JRE。

-

这是的跨平台开发框架。 它是开源、免费、文档齐全、需要大量投资且持久的。

桌面版本也很新。 稳定版刚刚发布，Mac版还不稳定。

如果你从来没有做过移动端的事情，却想使用这个框架来开发桌面应用程序，那么意味着你需要学习的东西还有很多。 幸运的是，dart 和入门并不难，而且学习曲线也比较平缓。

由于我在移动端积累了多年的经验，所以界面上的一些东西在移动端上是比较稳定的（skia自画引擎）。

操作系统相关的东西还不太成熟，生态也不是很好。

例如，如果您想自定义窗口的标题栏或访问注册表，您可能必须自己想办法。

不过它有类似FFI的支持，处理C/C++语言非常方便。

开发者直接使用Dart语言来描述界面，这就导致了很多大括号嵌套在一起的问题，很多开发者可能不习惯。

使用-开发的应用程序封装后体积仍然比较大

这是由 Edge浏览器团队推出的跨平台GUI引擎。 它是闭源的。

目前仅支持，对C#和C++开发者友好。

如果使用C#开发，就得考虑将.NET运行时分发给用户。

如果使用C++开发，就得自己处理系统级API的操作，而系统级API本身并没有封装。

这个框架上线时间不长，但是很多API还不稳定。

更让人担心的是这支球队。 他们不久前刚刚放弃了浏览器核心，转而使用浏览器核心。 我想知道他们是否会放弃这个框架。

它的优点是可以复用系统中已经存在的二进制资源。

换句话说，虽然它屏蔽了一个浏览器核心，但如果你能确定客户端的电脑已经开发了应用程序，那么你的安装包的大小就可以足够小。

同样是多进程架构，甚至多了一个进程（为了复用二进制资源），占用的资源也更多。

更详细的介绍，可以阅读我的文章：

该库利用操作系统的浏览器引擎来减小安装包的大小。

在 Mac 上使用 /，在 Mac 上使用 gtk-，在 10 上使用 Edge（上一节提到过），

不支持Win7。 由于不同的操作系统使用不同的浏览器内核，开发者在使用前端代码开发跨平台应用时必须考虑前端代码的浏览器兼容性。

开源免费（MIT）有go、Rust等语言的绑定，但官方支持的是go语言、C和C++。

操作浏览器的API很少，也不支持定制，更不用说系统级的API了。

采用的技术方案与所采用的技术方案类似，因此安装包足够小。 它非常新，尚未发布稳定版本。 它是开源且免费的。 框架遇到的问题都有。

使用 Rust 开发，未来将支持 Deno。 作者表示，未来将直接使用该技术，支持多平台。

西北.js

NW.js最先将其与Node绑定，利用前端知识制作界面，利用Node技术访问操作系统。

它最初被称为node-，创建于 2012 年。

NW.js基于MIT开源，可以无忧使用。

微信小程序开发工具好像是使用NW.js开发的（几年前研究过）。 作者是员工，的一些工具也是使用NW.js开发的。

除了与 Node 的功能外，NW.js 本身也封装了一些系统级的 API，比如托盘图标、剪贴板、系统菜单等，但数量显然要少一些。

NW.js 可以在多个窗口之间共享相同的 Node.js 上下文，还可以配置为混合 Node 上下文和 Dom 上下文，这给开发人员带来了很多便利。 精神负担大大减轻。

这不像要一直考虑进程间通信以及哪些模块不能被当前进程使用。

NW.js虽然起步早，但并没有杀手级应用，周边的生态和工具链也没有发展起来。

使用的人越来越少，维护的投入也没有那么大。 另外，更新非常频繁，导致NW.js的一些API不太稳定，恶性循环愈演愈烈。

作者曾在NW.js团队工作过（对NW.js项目贡献第二大的人就是作者），

后来他跳槽到公司，并于2013年创立。

它也是一个开源且免费的产品。 由于我选择了 、 等国际产品，所以有很多关注者。

生态和周边工具链也更加完善。 虽然开发方式（多进程架构和模块归属流程）存在一些缺陷，但缺陷并没有被掩盖。

每创建一个窗口，就会多一个进程，这使得窗口创建效率低下（以秒为单位）。

NW.js有一个进程重用机制。 即使新窗口从完全不同的域加载页面，也不会创建新进程（毫秒级）。

这就是为什么很多基于开发的应用程序使用Dom来模拟弹出窗口的原因。

无论是浏览器相关的API还是系统级的API，它提供的都比NW.js要多。

这个GUI框架的实现原理和开发方法都是独一无二的。

它无限循环地不断重绘整个界面，

其他 GUI 框架在更新时都会重新绘制。 不管更新不更新，都是一下子重画，而且一直重画。

对于一些不支持GPU的客户端来说，这会导致CPU消耗稍高，但总体来说还不错。

它对于游戏开发者来说非常友好，很多游戏都集成了它来进行用户交互（一些游戏内的设置界面、聊天界面等）

它支持许多绘图引擎，例如，等等。

打包后体积很小，只有几百K。

还有一些小问题，比如：在界面中使用相同的字体不同的字号是很痛苦的。

如果你打算使用这个库，我建议你不要选择一个分支，而是选择一个分支（这个分支下有很多功能）

与这个框架类似的还有：

总结

我们已经介绍了很多框架。 可以说，各有各的特点。 有的成熟稳定，有的运行高效，还有的框架仅凭业务表达能力取胜。 开发人员在进行技术选择时常常难以做出决策。

这里我总结了判断一个桌面软件开发框架是否优秀的三个底层逻辑，可以帮助我们开发者了解真相，做出最优选择。

第一，是否有独立的界面描述语言（UI DSL）。

这个非常重要，是一个框架表达业务的重要能力。

类似于WPF的XAML、qt ui文件中的XML、HTML+CSS都属于界面描述语言，都是通过专门的XML来描述界面的方法；

还有一种通过代码来描述接口的方式。 、qml和qml都是使用这样的接口描述语言来描述接口。

下面的伪代码是接口描述形式：

panel {
  row {
    checkBox(...)
    row {
      textField(...) 
    }
  }
}

但无论如何，很明显没有一种界面描述语言能够与HTML+CSS的组合相媲美。

想一想：HTML中的各种语义标签和DOM操作技术，布局方法，伪元素，CSS中的动画描述等等，你就会明白这一点。

其次，是否具有强大的事件处理机制。

作为 GUI 应用程序，与用户和设备的交互至关重要。

这涉及到多种事件，比如设备相关的鼠标事件、键盘事件、触摸屏事件、网络状态变化事件等。

与界面元素状态相关的界面加载完成事件、媒体播放结束事件、元素大小变化事件等。

另外，仅仅能够接收这些事件还不够。 您还必须处理事件冒泡、事件捕获、事件分发等。

我认为与浏览器核心的集成来处理各种事件也很出色。

而且经过几十年的发展，这个组合赛事系统也相当成熟和稳定。

第三，是否具有强大的异步并行处理机制。

开发者在处理用户业务逻辑的同时，不能阻塞界面渲染工作。

这就需要强大的异步并行处理机制。

如果让开发者创建线程并自己完成这些任务，无疑会很麻烦，增加开发者的精神负担。

虽然它是单线程执行语言，但浏览器核心是多线程（或多进程）的。

因此，与浏览器核心集成后，开发者不必为开发多线程应用程序而烦恼，也不必为没有多线程支持而不知所措。

从以上三方面的技术要求来看，在桌面GUI应用中封装一个浏览器核心还是非常有价值的。

这样，开发者就可以利用HTML+CSS的强大能力来描述界面。

利用强大的事件处理机制和异步处理机制完成用户交互。

Web相关技术之所以盛行，并不是因为这些技术的设计者有多强大，而是因为在过去的20年里，大量的人涌入了这个领域，并一直在推动着它向前发展。

在任何其他领域都没有这样的兴奋。 我建议你看看我的另一个回答：

【现在整个Web前端都是“狗屎山”了吗？

]()

GUI应用程序使用Web相关技术的好处是，开发人员可以将大部分精力集中在业务本身，而不是处理GUI相关的技术细节。

事实上，所有框架都应该有这个目的，比如ORM框架，应该让开发人员将大部分精力集中在业务和数据之间的关系上，而不是管理关系数据的技术细节上。

当然，损失肯定是有的，性能、稳定性、资源消耗都会有一些下降。

而且，因为框架的存在，开发者很难深入框架做一些特殊的事情。

例如，我们如何修改HTML的布局和渲染机制？

因此，有的框架注重性能，有的框架注重开发效率。 开发者在做选择题时也应该权衡这两个问题。 您的申请对哪些方面要求更高？

如果你要开发一个视频监控系统，业务功能不多，但需要每天24小时记录视频数据，并随时调取一定时间段的视频数据，Qt可能是这个应用的最佳选择。

如果要开发像飞书这样的团队协作应用，业务逻辑就会很乱。

而且，要在短时间内满足更多用户的需求，占领更多的市场。

那么可能是更好的选择（飞书目前已经不用了，他们自己编译了核心，封装了一个类似CEF的框架）

目前，微软、谷歌等公司都非常重视桌面开发框架，也在推广自己的框架产品，这说明桌面应用领域并没有衰落，反而应该受到更多关注。

虽然移动应用很受欢迎，但我相信只有生活、社交、轻娱乐等方向的应用在移动端有良好的发展。

文档协作、大型游戏、开发工具、专业管控软件等应用最好在PC端开发。 毕竟PC端拥有更多样化的输入输出设备、更广阔的显示和交互空间、更强的存储和计算能力。

希望所有桌面软件开发领域的从业者都能幸福。