快速全面了解QT软件界面开发技术

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

快速全面了解QT软件界面开发技术

前言

一、学习QT可能的目的是什么？

只想体验一下QT?

当前的项目选择了用QT。

为将来做QT技术储备。

二、 QT的核心技术优势是什么？

QT在软件界面开发领域几乎无所不能。

QT几乎可以适配各种规格的硬件设备。

QT二十年来一直在不断更新迭代优化升级。

三、 QT的过去和现在以及未来是什么样的？

QT在软件界面开发中的历史地位回顾。

QT在软件界面开发中的现实地位总结。

QT在软件界面开发中的未来地位预估。

四、 QT包含哪些内容？

QT核心基础概念技术体系。

QT Widgets传统界面技术体系。

QT QML/QT Quick界面技术体系。

QT 实用技术适配框架技术体系。

五、应该如何看待QT

QT的核心价值

QT并非在所有领域都无所不能

总结

前言

这篇文章不是介绍QT的具体软件开发技术，仅仅只是在笔者认知范围内，试图客观的系统的介绍一下QT这项软件界面开发技术的整体概貌。

QT是当今跨平台软件界面开发的一种主流技术之一，是C++跨平台软件界面开发的主流技术，没有之一。

这篇文章是为下面一些朋友们准备的：

你是否在为项目选择什么样的软件界面开发框架而纠结？

你是否在为项目选择QT的哪一种界面开发模式而纠结？

你是否在为应不应该学习QT而纠结？

如果这篇文章能够给你带来一点点启发，那么这篇文章就没白写了。

一、学习QT可能的目的是什么？

没有目的的学习的唯一价值就是打发时间。

只想体验一下QT?

QT之所以能够在全世界范围内得到广大软件开发者的青睐和使用，一个很大的原因是QT入门确实是非常容易。很少的代码就能折腾出一个比较复杂的软件界面。很多人可能会想着体验一下QT如何快速开发出一个像模像样的软件界面。如何让所有控件根据主窗口的大小自动调整大小？这种界面开发常规需求在QT中默认就支持，而使用其它一些早期的界面开发框架实现这种需求可能会是一件十分繁琐的事情。

当前的项目选择了用QT。

很多人开始学习QT可能是因为项目上的原因。项目使用了QT，那么就不得不学习一下QT。

为将来做QT技术储备。

如果空闲时间比较充足，可以考虑全面系统的学习QT，为将来的职业生涯做一点技术储备。

二、QT的核心技术优势是什么？

没有核心优势的技术有什么学习价值呢？

QT在软件界面开发领域几乎无所不能。

QT已经支持传统模式下的软件界面开发技术体系以及新模式下的软件界面开发技术体系。传统模式比如QT Widgets，这种模式下的竞争对手比如MFC早就“躺平”了表示不再升级更新了。新模式比如QT QML/QT Quick，这种模式下的竞争对手是HTML5。HTML5支持的各种特性QT几乎全都支持了。

HTML5不支持的QT也支持了。显然，QT应用程序在C++原生代码和JavaScript脚本代码以及界面标记语言 QML之间的互操作关系层面上肯定比HTML5方便得多。QT用QT QML /QT Quick就搞定了所有事情，而HTML5和C++建立互操作关系则麻烦得多。QT QML/QT Quick所不支持的特性，都可以由QT官方或者QT应用开发者直接使用C++去扩展。一个C++数据类型可以十分方便的注册为QML的数据类型。

当然也有一些特性是HTML 5应用支持，而QT不支持或者支持得不够好的。比如对CSS(Style Sheet)的支持，QT Quick应用就不支持，而QT Widgets应用支持CSS，支持得也并不完善。

这里之所以拿QT和HTML5对比，原因在于QT中有一些功能特性其实就是遵循或者参考W3C的一些标准规范来设计的。QT Style Sheet借鉴了HTML CSS的一些概念，比如QT Style Sheet支持CSS2定义的所有选择器类型，子控件跟CSS3的伪元素有一点似曾相识的感觉。正因为如此，QT Style Sheet有时候简称为QSS。另外，QT Quick内置JavaScript引擎，因此QT Quick应用支持HTTP AJAX、WebSocket等HTML5应用支持的功能特性。其中XMLHttpRequest API实现了与HTML5 XMLHttpRequest同样的W3C标准。QT Quick应用对XML文档的处理实现了 DOM Level 3 Core API的一个子集。 QT Quick的 Context2D实现了HTML5同样的 W3C Canvas 2D Context API standard。

QT几乎可以适配各种规格的硬件设备。

QT是一种跨平台的C++界面开发框架，可以适用于绝大多数操作系统和设备，包括但不限于Windows、Linux、MAC等桌面设备，还包括Android、IOS、WP等移动设备，现在QT官方声称QT已支持在MCU上使用。据QT官方网站信息，QT应用程序已经运行在数以十亿计算的各种设备上。QT实际上既可以在主频低至400MHZ的低端设备上运行，也可以在主频高至2GHZ的高端设备上运行；QT既可以支持软件渲染，也可以支持GPU硬件加速渲染。

当然可以适配不代表所有人愿意在自己的项目中使用QT去做这种适配。比如QT应用可以在Android和IOS上跑，充分利用QT跨平台的优点，可以降低全终端应用的开发工作量。但实际上还是很少人选择使用QT去开发Android和IOS应用，原因在于QT开发的应用在界面式样和行为模式上和Android以及IOS原生应用相比，还是有比较大的区别；当然HTML5混合应用也有类似问题。如果不能接受这个缺点则真的不应该选择QT作为界面开发框架。如果追求开发工作量最小化，同时不在意这个缺点，则完全可以使用QT作为界面开发框架。关于这个问题，笔者的看法是如果能接受HTML5混合应用作为全终端应用的开发框架，那么应该也可以接受QT作为全终端应用的开发框架，否则还是使用各平台原生应用比较好。

对于性能考量，QT的纯C++应用和Android原生应用的性能对比哪个更好？这可以参考这个问题：在同样的硬件配置条件下，IOS性能为什么比Android优秀一些？笔者认为这其中有一个很重要的原因：IOS应用是C++写的，而Android应用多了一层虚拟机在中间,这个虚拟机就算再怎么优化也不可能完全不消耗性能。同样作为纯C++应用的QT应用和IOS原生应用，在性能上至少也是有得一拼。另外，QT应用作为C++应用，性能上看跟HTML5混合应用相比，自然是占优的。当然，笔者在这里并没有实际去做这种严格的对比测试，这里仅仅根据笔者个人认知做出的一个常识判断。

QT二十年来一直在不断更新迭代优化升级。

如果说实践是检验真理的唯一标准，那么时间也是检验价值的重要标准。历史上多少技术经不起时间的检验，红火那么几年然后就销声匿迹了，这其中原因可能有多种多样，归根结底还是缺乏可持续发展的技术生命力，或者说失去了升级换代的价值。

20年以来，QT的版本从3.X升级到了4.X，又升级到了5.X，现在又升级到了6.X。这说明QT官方在不断的升级维护着QT。因此可以说QT表现出了顽强的技术生命力。QT作为一个软件界面开发框架，可以毫不夸张的说是C++跨平台软件界面开发框架中硕果仅存的唯一存在。其它的C++软件界面开发框架，有一些仅限于某一个OS，有一些仅限于少数几个公司使用，有一些生命周期仅限于那么几年。

三、 QT的过去和现在以及未来是什么样的？

没有人想追随一项没有未来的技术。

QT在软件界面开发中的历史地位回顾。

QT是一个二十年前就存在的技术，一直在比较稳定的进行版本升级迭代更新，这件事情本身已经足以说明QT在软件界面开发框架领域独一无二的历史地位。

QT的版权其实已经变更过多少次了，或者说支撑QT进行升级迭代的公司已经变更过几次了，其中不乏全球知名大公司,在此不一一列举。

QT在软件界面开发中的现实地位总结。

首先讲一下国内公司对QT软件工程师的招聘需求。

分别使用两个不同搜索引擎搜索了一下QT相关的职位信息，基本上都有巨量搜索结果。这并不代表当前存在这么多不同的QT职位，但是这个数量级可以说明国内公司对QT软件工程师的招聘需求还是比较旺盛的。国内现在国产化替代显然已经是大势所趋，而国产OS基本上都是基于Linux的。Linux上N多的软件是用QT开发的。

请参考<<QT软件工程师招聘市场需求报告>>。

其次对比一下 QT现在的市场地位。

无论是看支持的OS的种类的数量，还是看支持的设备的种类的数量，相比于其它界面开发框架而言，QT无疑都是位居首位。这是QT的超级跨平台能力决定的。尽管笔者没有实际深入研究过其它界面开发框架，但是一个显而易见的情况是，用QT写的代码，确实是可以在重新编译之后至少在几种最常见的OS和设备上运行的。 Hybird模式的一些界面开发框架，基本上是HTML5 + JavaScript应用,所支持的跨平台的广泛程度以及运行性能显然不能跟QT相比。

最后讨论一下功能问题。

跟其它界面框架相比，QT对界面开发相关的特性的支持能力怎么样呢？ QT是一个有着长期历史沉淀积累的古老框架；当然古老肯定是有不少缺点的，这是必然的。QT过于庞杂笨重；但是QT也是在不断的更新迭代升级的，新的QT QML/QT Quick 相对于古老的QT Widgets而言，是一种“轻量级”的新生代界面开发框架；而QT QML/QT Quick和QT Widgets是可以互操作的，就是说QT已经实现了在同一个应用程序中新老框架兼容和互通有无。

QT在软件界面开发中的未来地位预估。

这里讲一下QT现在所属的Digia公司。

Digia公司在包含中国在内的全球十几个国家开展业务，这只包含其付费业务，而免费QT已被全球很多国家的开发者选择使用。QT提供免费社区版本和付费商业版本。Digia公司是一家小而美的IT公司。因此QT健康有序的可持续发展是比较有保障的。

有一些人可能会有这种疑问：选择在商业公司控制之下的免费QT作为技术路线，是否蕴含了一定的商业风险？在笔者看来，即便发生了最坏的情况比如不再提供免费社区版本的升级更新，那么以QT目前版本的完善程度而言，在免费开源社区以当前老版本为基础长期维护一个免费版本分支然后独立迭代更新升级也是可行的。这个事情在开源软件世界是有先例可循的，一些知名的开源软件在被商业公司控制之后的发展轨迹也有正如上述所言的。

四、 QT包含哪些内容？

纵观全局带来的价值可能远远超出想象。

QT核心基础概念技术体系。

包含了QT核心概念及其实现。比如对象模型、元对象系统、信号与槽机制、事件循环机制、状态机机制，对象属性系统机制，国际化机制、跨平台支持机制、IPC和多线程机制，以及基础数据类型等。

QT Widgets传统界面技术体系。

包含了布局管理、焦点管理、事件循环、图形绘制、窗口控件、窗口式样，以及Style Sheet，模型视图代理框架，图形视图框架等。这些属于QT传统的界面开发模式。

QT QML/QT Quick界面技术体系。

包含了QML标记语言、JavaScript支持、QT Quick布局管理、焦点管理、窗口控件，与HTML5应用类似的对W3C标准的支持，比如Canvas/Context2D、LocalStorage、WebSocket等，以及界面特效支持，比如动画框架、图形效果框架、粒子系统框架等。这些属于QT比较新的界面开发模式。

QT 实用技术适配框架技术体系。

包含了音视频框架、网络框架，以及各种硬件访问框架，比如对BLUETOOTH、WIFI、NFC、SERIAL PORT、GPS等硬件设备的支持。当然，由于QT真正的核心优势是界面开发，这些支持大部分情况下都只是作为一种应用程序和底层设备软件API之间的一种适配层存在的，很多时候只是对 OS层面API的一种高层封装，或者说QT提供了相比于原始API而言更加简化和更加“QT”的API。

五、应该如何看待QT

降低产品研发成本，提升产品研发效率，提供艺术级的用户界面体验。---QT官网

QT的核心价值

QT支持的特性越来越多，但是QT最核心的价值仍然没有改变，那就是最优秀的跨平台软件界面开发框架。有一些读者朋友看到这里可能会有一些不爽，认为QT能做的远远不止这些。笔者认为能做不一定表示能做到最好，甚至不一定表示能做好。笔者在这里并没有故意冒犯这些读者的意思，仅仅是就事论事表达个人观点，仅供参考。

使用QT官网的话来讲QT的价值在于降低产品研发成本，提升产品研发效率，提供艺术级的用户界面体验。这表明本质上而言QT最核心的优势仍然是专注于提升用户界面体验。这也正是笔者对QT的价值的一个基本认知。笔者认为QT官网上的这三句话并非空穴来风，而是言之有物的。

首先来说降低研发成本。

设想这么一个跨平台产品研发场景：为了公司的产品能够给Android、IOS、Windows、Linux、 MAC用户使用，是否会考虑针对每一个平台独立开发一个app，每一个平台都招聘一些专门的软件工程师呢？相信这会是很多公司的常规做法。但是考虑一下使用QT来开发这种产品，情况立即就变化了。这时只招聘一些QT软件工程师，只开发一份代码，针对每一个平台独立编译出一个 app。显然后者至少降低了研发人员数量，从而降低了公司研发成本。

其次来说提升研发效率。

QT是一个完全面向对象的设计，有着比较严谨的类型继承体系，以及比较好用的基于C++的API接口。关键的是QT提供了用户界面开发所需的各种实用类型，对于软件界面软件工程师而言，简直就是急人之所急想人之所想。无论是开发本机独立应用还是开发网络客户端应用，无论是开发基于套接字的传统网络应用，还是开发基于HTTP AJAX的现代化网络应用，或者开发基于WebSocket的新型网络应用，QT都提供了很好的支持，有些情况甚至提供了多种支持方案供选择。如果说C++相比其它一些“现代化”高级语言而言，运行效率高，但是开发效率低，原因是C++缺乏一套独立的完善的大型的实用类库，那么QT已经彻底弥补了这个缺憾，因此QT提升C++开发效率就是自然而然的事情。另外QT入门门槛非常低是一个不争的事实。当然，如果没有系统全面深入掌握QT各项技术，那么在实际开发工作中遇到比较复杂的应用场景，也可能出现一些问题；这些问题不能说是QT的问题，只是说QT的复杂性导致初学者遇到没有掌握的情况时也可能错误的使用QT导致一些问题。

最后来讲一下提供艺术级用户界面体验。

QT的各种特效框架，提供了一些游戏开发框架所提供的功能，比如动画框架、粒子系统框架、图形效果框架，而游戏最讲究的就是用户体验。这样来讲QT官方所称的提供艺术级用户界面体验自然所言非虚。

QT并非在所有领域都无所不能

前面说QT在软件界面开发领域几乎无所不能。请注意限定条件软件界面开发领域。QT受限于自身各种特性，并不适合用于网络服务器软件开发领域；网络上很多人吐槽QT开发的网络服务器的性能问题。

QT提供了网络编程框架，但是并不适合作为网络服务应用的API框架。原因在于QT的很多框架都支持QT的信号与槽机制，这类设计选择使得QT保持了QT信号与槽机制带来的鲜明的QT特色，但是这个特色在一些情况下极大的降低了应用程序的性能，在一些多线程情况下使用不当时容易导致程序运行不稳定。可能正是如此，笔者发现QT中一些框架的API并没有使用传统的信号与槽机制。

因此，真正学习涉及这些领域的技术时，还是应该学习使用操作系统提供的API接口。当然，在一些并不以性能作为评价指标的桌面应用和移动应用以及嵌入式应用等应用场景中，使用这些QT框架的API 是没有任何问题的。在使用QT的这个适配层时，必须对QT的一些基础机制有比较良好的理解，否则容易发生因为错误的使用导致问题的现象。

没有QT的时代，只有时代的QT。就目前而言，并非QT的时代来了，而是QT已经成功跨越了几个时代，大概率可以成功跨越下一个时代。如果说时代的QT已经迎来了QT 6.X版本，那么作为跨平台界面开发利器，时代的QT在未来是否能够得到更大规模的应用呢？让我们翘首以待。