Qt 如此强大为什么就是火不起来呢?
共 1837字,需浏览 4分钟
·
2020-10-29 23:19
知乎上的一个问答,站长觉得挺有意思的,分享给大家。
问:
举个例子,Qtdesigner 中直接就有日历控件,拖过来就能生成一个简易日历软件了。Qt 真的很强大,但为什么就是火不起来呢?跟开发出它的公司不出名有关嘛?
其中一个回答:
作者:知乎用户
链接:https://www.zhihu.com/question/53068823/answer/781294779
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
先说结论,Qt是很多领域是很火的,只不过Qt火的领域我们普通人接触不到。我们接触的大部分都是互联网应用,企业级应用,这些领域用Qt就是大炮打蚊子。
Qt面向的是什么?首先Qt的第一个吹牛逼的特性是跨平台,目前你能想到的操作系统平台它都能支持,虽然有部分平台支持的不是特别好,但是在比较流行的平台下,如Windows,Linux桌面端/服务端/嵌入式,都是支持非常不错的。BUG虽然有一些,但也算在解决方案内部绕过去的那种,致命的BUG不多。
Qt第二个特性是高效,基于C++的语言决定了使用它做GUI开发,一些辅助功能可以直接使用硬件特性,比如直接操作内存什么的,同时GUI绘制的时间也是可控的。所以一些嵌入式软件的人机交互界面基本上都用Qt实现比较合理(在资源本来就不行的情况下,跑个tomcat+浏览器简直不可能)。
Qt第三个特性是门槛低,这点有争议的,这里的门槛是和操作系统底层的GUI相关的API比较的,只有用过Win32 API,GTK+的才有发言权。那些十几个参数的API,想想都恐怖。
那么那些Qt火的领域为什么用Qt呢?那些Qt不火的领域为什么不用Qt呢?这个是典型的软件设计架构问题。我能用苍蝇拍子解决的问题,为什么用大炮呢?先说Qt火的领域
国内的电网领域:早期的(90年代)电网自动化软件都是国外的,菜一点的都是跑在NT4.0上的,高级一些的都跑在Solaris上的,然后国内开始仿制(那个时候已经WinXP了),一看国外的系统既可以跑在Win上,又可以跑在Unix上,Linux又开始慢慢流行。你说那个时候的设计师选什么作为图形框架?首选Qt3啊,那个时候Java还不知道在哪里呢。现在国家电网南方电网又在推广国产操作系统,所有的生产控制系统都是基于Linux的国产操作系统,那些早期用MFC的,实时系统转Qt,非实时系统转Java。这个领域用了Qt的跨平台和门槛,毕竟那个时候的程序员能用好操作系统底层API的太少了。
汽车领域:大家看到的车机系统早期是WinCE的,非常卡,点一点反应一秒钟,后来逐步是Linux,然后是Android,反应快一点儿了。汽车仪表盘的实时性可比车机要高的多,早期的仪表盘都是指针+单色液晶,就是一个很简单的裸片子控制,连操作系统都不上,为了就是实时性。要是你已经加速到了120,但是仪表盘上还是60,那你不疯了。现在的仪表盘要么是厂家自己定制的Linux,要么就是QNX,但是在图形框架上绝大多数用的是Qt,C++的特性保证了硬件性能实时掌握在程序员手上,要是瞄一眼仪表盘的时候,这个时候Java正好GC了……这不是都是利用了Qt的高效性质。
其他火的领域就不一一说了,比如视频监控,军工控制。
我们接触的比较多的领域是互联网和企业应用,那么为什么这些领域现在的不青睐Qt呢?
首先跨平台,说跨平台貌似没有多少能比JVM做的更好的了,管你什么硬件平台,基本上都有能用的JVM版本,至少在跨平台上面Qt并没有绝对的优势;
其次是效率,这些应用很少那种批量数据处理解决大批量数据的问题,即使有,也可个作为核心模块,使用专门的技术解决(比如MapReduce等,这些领域通常硬件资源是无限的),更多的关注的是业务流程,所以基于C++的Qt并无太多优势;
然后是门槛,虽然Qt框架的门槛比直接使用操作系统API要低,但是比C/C++门槛低的高级语言多得是啊,部分Java框架在语言层次上和Qt比较简直毫无下限;
最后是,使用流行的Java,Python之类的能干的活,为什么要用C/C++的Qt呢?毕竟人家用Maven和Pip方便多了。
总之找不到使用Qt的理由。