做windows界面，用QT还是MFC？

Posted 2023-04-08

参考技术A

使用Qt吧,前提是在这两者下进行选择。既然提到了Qt和MFC，我想题主肯定是一个C++的开发者。其实，在我看来，Windows下开发界面程序，还有很多其他的选择。下面我就连同Qt、MFC一起来介绍一下几种常用的界面开发框架。

其实选什么学习还得根据自身的需求。语言不分好坏在于人。精通才是正道。当下window下流行的编程语言，有vb，mfc，c sharp，。如果没啥限制，建议第三个吧，简单粗暴上手快，开发效率也高。如果公司或硬件限制必须用mfc或其他语言，那学就是。都是微软的产品，我开发项目都用过，知识通用。至于qt封装是全，相对微软自家的产品，用的人少些。问题多靠自己解决

具体选择QT还是MFC，这要根据题主的需求来决定。如果你入职一家公司，做的是老项目的维护，而原有项目是采用MFC来开发，那么当然，你没得选，只能老老实实的继续MFC，虽然这玩意写起来真的很虐心。如果是一个全新的项目，那么还是首选Qt。

下面根据自己的认识，推荐几款Windows下开发界面开发常用技术。

1）Qt

号称可以跨平台，语法结构简单清晰。面向对象的特性体现的比MFC明显。代码写起来比较优雅，也就是说上手会快一点,最新版本支持的特性QML，可以让我们用JS，CSS来绘制客户端界面，写起来效率也是蛮高的。缺点就是文档可能没有MFC那么齐全，基本只有官方的官网和Demo，而且发布包体积会比较大。

2）MFC

全称Microsoft Foundation Classes（微软基础类库），可以算的上是上古产品了吧，目前除了维护老项目，应该很少有团队使用MFC来开发了吧。基本上MFC == “没饭吃”。建议如果你是初学者，界面开发还是不要选择MFC了。它唯一的好处就是微软的MSDN文档比较齐全，相关论坛和那种问答的资源要多很多，一般初学者遇到的问题都可以看到前辈们的解决方法。不过目前它已经被其亲爹微软抛弃了。

3）Duilib

目前已开源，是一款强大的界面开发工具，可以将用户界面和处理逻辑彻底分离，极大地提高用户界面的开发效率。唯一不足的是原开发者已经停止维护，很多都是个人在维护，出了问题的话，只能自己去摸索，Debug。下面是一款个人使用Duilib开发的迅雷播放器界面效果。

最后附上一些基于Duilib开发的软件不完全列表（欢迎大家补充指正）：

百度： PPS 爱奇艺 百度杀毒 百度卫士 91助手

腾讯： 微信 企业微信

阿里： 钉钉 支付宝安全控件 PP助手

书生云： 书生企业云盘

微软： 微软壁纸

网易： 易信 云音乐 荒野行动PC版

华为： 华为网盘

金山： 金山快盘

京东： 咚咚

cctv： cbox

酷我： 酷我音乐盒

蘑菇街： TeamTalk

火绒： 火绒安全软件

盘古： 盘古越狱工具

顺网： 网维大师 91y

网狐： 网狐经典版

墨迹风云： 墨迹天气

zoomcloud： Zoom 视频会议

搜狗： 搜狗手机助手

沃通： 沃通代码签名工具

驱动人生： 驱动人生 人生日历

维棠： 维棠

深圳市北斗智研 科技 ： 智能办公助手 ERP管理系统

4）Electron

这玩意应该是这几年才火起来的吧，宣城自己可以通过使用javascript、html和CSS构建 跨平台 的桌面应用程序，让人们感觉 JS 真的有一统天下的趋势（Web、移动端、PC客户端）。开发效率真心的高，不过貌似商用上还不是特别的多，典型的成功案例目前知道的有VSCode，Atom。

两者之间二选一的话肯定选Qt了，如果再考虑开发效率与运行效率的话，可以在Python平台上使用Qt的Python绑定库PyQt，再配合C++，主体用Python语言，界面部分用PyQt搭建，核心算法部分用C++封装成动态库DLL文件，在Python里去调用。这样是一个不错的方案，Python部分缩短了开发时间，C++部分保证了运行速度，只是前提是，你要会用C++写DLL，在Python里会调用DLL。

作为做了近2两年windows application的人来说，我直接说Qt！首先我主要做pc和下位机通信的app，如串口、tcpip、总线类等。选qt理由如下：【仅从我的经历来讲】

1、Qt开发效率高。我第一个项目前几个项目用的MFC，平均时长3个月，一个软件80%的时间都放在界面上去了。然后后面开始使用Qt，一个月能做好几个app没压力，界面布局很方便，不用像MFC去一个一个控件拖动。

2、Qt库简单易懂。个人的感觉就是MFC与win api联系太大了，你要玩转MFC，必须要把windowsapi相关知识搞得明明白白的。而Qt库把每一个功能都封装得很好，很容易去使用，不需要没事就百度怎么用。

3、MFC已经在淘汰边缘了。到如今Qt还在不断更新，我目前使用的是Qt5.9。在平时招聘的时候，也很少看到有公司让你专职做MFC，要么Qt，要么C#。

4、Qt跨平台。我当初换Qt的一个原因还是，我以后如果不做windows了可以换linux上位机，Qt可以做到很好的跨平台，而MFC不行。

两者没有好坏之分，需要看应用场景。如果是界面要求不高，稳定性和效率要求高的工业软件，MFC是最好的选择。如果是界面要求美观，跨平台使用，QT是最好的选择。但是要注意的是QT企业用是需要授权费的。另外，windows上的界面还有其他选择wpf，direct ui等。这里着重提一下direct ui，目前可以找到比较好的就是duilib这个界面库，开源稳定易用高效。关注我一起探讨呀！

我们来简单比较一下QT和MFC。

1.开发速度

整体来说可能MFC会快捷一些，因为windows平台的开发工具大多很智能，因为立足于windows的开发人群很广，从菜鸟到专业人士，但是QT由于基于Linux，可用的开发工具不多，大都比较专业，多是第三方产品，而且集成度不大，第三方库也没有MFC得多，从这一点MFC略胜一筹，但是QT自从被Nokia收购后，官方发布了跨平台集成开发环境QTCreator，所以之后走向就不好说了，个人总体感觉QT Creator和VS.net差距比较大，还需改进。

但是从库本身来说QT集成的功能较MFC庞大，而且使用的封装技术信号和槽也是比较受到赞许的，比如QT Script为QT提供嵌入式脚本，QT界面库支持CSS，所以QT做出来的界面比MFC要好，而且比较容易，MFC就需要借助第三方库了。

因为MFC是浅层封装（最新的2008 sp1加入了BCG的高级界面库，可能有所改善）windows SDK，以降低使用windows SDK引起的开发效率的降低，和开发难度的增加。

所以QT库是比MFC优秀的，两个库都经受了时间的考验，稳定性都很高，Bug几乎没有。

2.运行效率

MFC由于其浅层封装的特点，所以运行效率是比较高的，加上vc对windows的针对性优化，整体性能是比较高的，但是如果加入第三方库就不敢保证了。

QT因为库比较庞大，封装层次较深，所以运行效率较MFC为低，但是在现在的机器配置下，C#大家都不介意了，这些会引起人们的介意吗？

3.学习难度

QT的封装哲学比较明晰，和系统隔离得比较好，门槛不高；

MFC较难精通，因为深入开发之后SDK还是要了解的。

必须Qt啊，跨平台，还有鬼知道项目以后要不要跑Linux和嵌入式设备上！界面简单的话，用qml开发，可以直接移植到嵌入式设备上去，还可以把编写逻辑的程序员和界面设计师分离出来！mfc现在微软都放弃更新维护了，mfc开发界面很麻烦的，除非老项目要维护，不然不建议再用mfc做新项目了！Qt的信号与槽很赞，比mfc的回调函数好用多了！

mfc底层太复杂了，但资料多，开源代码多。

qt底层可能好点，但资料和整个开发环境肯定不如vs系列。

微软精力不在mfc上面了，而qt则要在竞争中求存活。

用什么看开发习惯，熟悉哪个用哪个。有困难找我

图形界面库Windows Forms MFC WTL WxWidgets Qt GTK 综合比较

 

图形界面库Windows Forms、 MFC、WTL、 WxWidgets、Qt、GTK 综合比较见下表：

 

总结：

GTK+主要用在X Window上，整个设计的架构和许多概念和MFC以及一般 Windows 上的程序开发大异其趣，入门门槛较高，而且最主要的特色是，它用不具有物件功能的纯C 语言，模拟物件导向。所以写起来比较复杂艰涩，而且充满大量巨集，使用和除错都不是很容易，但优点则是可以用C，不需C++，如果和Win32 SDK比较，不会难学多少，缺点是不易上手使用，而且文件比较缺，架构又非常复杂，且提供的东西比起其它无所不包的 library，是简陋了一点，函数命名又臭又长。

对于简单的程序，GTK+会显得太复杂，但是当你开始想扩充其它library也都没提供的进阶功能，就会开始赞叹GTK+ 的架构严谨，还有超乎想像的高度弹性。同样的东西要用 MFC来做反而会要人命，并且多国语言的支持良好，内部也全面使用UTF-8，相容性好，要是unicode能够习惯的话，GTK+值得推荐，但不建议学，毕竟不好学，要用到熟会需要比较久，而且那样很多C++的功能会用不到。GTK+有C++版本叫做GTK–，没用过但看文件觉得，并没有比gtk+简单到哪里去。 因为 gtk+本来就是物件导向，所以即使换了c++ 语言，写起来架构还是差不多的。

另外，gtk+有Windows 版本，但缺点是，执行缓慢，不稳定，而且介面是使用gtk+自己的，不是使用 Windows 内建的Native原生图形介面，看起来会不太习惯。 Mac OS X 下可用 X11 来执行gtk+，但那样出来的程式是长得像 UNIX 程序，而不是美美的OS X Aqua外观。

wxWidgets和MFC最接近，已有十余年历史，命名习惯或架构都高度相似，会MFC几乎不用重新学习。此外，它的物件封装比MFC要好，提供的功能也多上太多，又跨平台。一般知名的MFC程式都会选择用wxWidgets改写，来快速移植原程式到其它平台，例如 eMule用wxWidgets移植出aMule，xMule， 还有在开发中的Filezilla 3…等。而它最主要的特色是，它是跨平台的Native GUI toolkit，在各种平台上都可写出使用该平台内建Native原生图形介面的程式。在Windows 上就长得跟其它Windows程式一样，在 Linux 下就使用 gtk+的图形介面，在 Mac OS X 下就可以使用华丽的Aqua 外观风格，这点是非常强悍。 不像gtk+到其它系统都还是只能用gtk+自己，缺点是，中文支持在有些地方会出问题，例如剪贴簿的操作，得自己patch，但仍然相当推荐，即使是个庞大的library，效能依旧不会太差，尤其在 Windows 上执行速度并不输 MFC，与其学MFC，不如学wxWidgets。

Qt的功能，应该是这三者加上MFC之中最强大的，文件也很完整，又有 RAD 工具可以辅助开发，并且有商业公司做强力后盾。不但有Windows/X Window/Mac版本，甚至还有嵌入式系统可用的版本，稳定性还不错，物件封装也算良好，资源比 GTK+ 或wxWidgets多得非常多，而且发行公司提供了相当多范例，算是一家以开放原始码成功营利的模范公司。 知名的KDE整个是用它开发，证明了它的稳定性和强大功能。缺点是如果你用它开发非 GPL 开放程序码的软件，必须以极昂贵的金额购买商业版本。而它的图形介面并不完全是 Native GUI，只是透过theme 去模拟系统上的标准 GUI，所以看起来很像，却会有些地方可以明显看出破绽。执行速度缓慢还有过于庞大则是另一个问题。

虽然封装得很好文件也齐全，并不代表它就很容易学。还有一个严重问题是，它写的不是标准C++，它使用的signal/slot机制必须透过Qt提供的preprocessor，处理过才可以转送给编译器，这部份可能被限定用qmake，算是一个可惜的地方，不过瑕不掩瑜，还是很推荐。忘了说，它内部也是unicode，多国语言没问题。

再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow