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