Qt 框架的图形性能高(OpenGL上的系统效率高),网络性能低,开发效率高,Quick是可以走硬件加速——Qt中分为好几套图形系统,差不多代表了2D描画的发展史。最经典的软描画系统


~~~~~图形性能部分~~~~~
Qt的widgets部分,运行时的图像渲染性能是一般的,因为大部分的界面内容都是Qt自绘,没有走硬件加速,也就是说很多图形内容都是CPU算出来的。
但是widgets底层毕竟是C++,而且Qt的模块写的也不错,做过很多优化,这个渲染的性能在桌面上与有硬件加速的框架比差别不大,除非是有很多动画的复杂场景才能看出区别。
不过在手机上或者嵌入式上,就会明显觉得widgets的渲染性能低了。

那么怎么办呢,Qt是不会抱死在widgets一个框架上的。所以Qt推出了Quick和QML。
Quick是可以走硬件加速,各个平台都可以,而且支持OpenGL或OpenES。图形渲染性能非常强悍。
而且框架本身是类js的开发语言QML,开发效率也非常高。
目前Qt正在开发Controls2.x,这是Quick中主要的控件库,比现在的1.x性能又是成倍的提升。

有些人说Quick加载慢,我想说,把QML文件(包括Controls这些库级别的)直接编译进qrc文件,然后开QML编译器,加载速度66的。


~~~~~网络性能部分~~~~~
先说TCP部分的服务器,就是QTcpServer
这个模块性能是不强悍的,甚至连中等性能水平都到达不了(C++)。
这主要体现在两部分,第一是并发很低,这和Qt用的事件循环底层有关,超过800长链接就不稳定,超1000基本没法正常使用。第二是数据传输性能低,大约传输相等的数据量,比ASIO要多至少一倍CPU占用。
但是毕竟是C++,性能相比其他语言还是可以的,开发小规模的服务器,是没问题的。

再说说UDP服务器,就是QUdpSocket
前段时间做一个项目,要求用UDP接收大量数据,是每包1400字节数据,每秒4w包,大约相当于500M的带宽。
然后我先是用Qt做开发,然后各种丢包,最后简化到单独线程死循环接收,接收后甚至不做任何处理直接回去接收下一个包。这样,也只能每秒收7000个左右。
额,这丢了80%多,亲,不给力啊。
然后换了ASIO,也只能接到1.3w个,亲,还是不给力啊。
后来换了WinPcap,轻松拿下4w个而且一个不丢,终于给力了。
 
---------------------------------------------------------------------------------------
开发效率还是运行效率?一般效率指这两项为多,后者更多用性能来表达。
开发效率在C++库中绝对是高的,Qt自带的一套非常完备,应有尽有。
运行效率的话,在Qt中分为好几套图形系统,差不多代表了2D描画的发展史。最经典的软描画系统,性能只能说差强人意,而搭建在OpenGL上的新系统效率就高的多。而且,作为原生C++语言(QML除外),天生在性能上也有加成。
 
链接:http://www.zhihu.com/question/37444226/answer/71999921
 
---------------------------------------------------------------------------------------

简单的说就是:如果你的项目没有跨平台需求,那么不建议使用Qt开发Android或者iOS或者WP的app为什么这么说,因为如果要开发一个单平台相同质量(能不能到相同质量还有待权衡)的移动端app,用Qt相比原生框架往往需要更多开发量。如果相同的开发量,往往意味着更平庸的软件质量。但是如果是跨平台,Qt的优势就体现出来了。可以理解为1.1份的开发获得2份平台的结果或者1.2份的开发或者3份平台的结果。我目前用Qt开发了Windows、OS X、Linux、iOS(11款已上架)、Android、WP(1款已上架)的客户端。Linux、WindowsServer的服务器端。对我而言,我发挥了Qt跨平台的特点,降低了总体的开发量。而且也降低了各个平台开发的入门门槛以及学习成本。可以说一份代码,几乎不需要更改就可以编译到另外一个平台是非常爽的。对了,如果是桌面端的程序,哪怕只部署到一个平台,Qt也具备高开发效率、高质量等特点。移动端毕竟还需要很多的改进。

链接:http://www.zhihu.com/question/37331229/answer/71555381

原文地址:https://www.cnblogs.com/findumars/p/4973314.html