Qt 框架哪些方面效率高，哪些方面效率低？

01-08

這裡應該是指運行效率。那麼 Qt 效率高在什麼地方，又低在什麼地方？（猜測：高是否是相對其他語言而言，低是否相對於 cpp 的其他框架而言？）

有人點贊，已更新。

～～～～～圖形性能部分～～～～～

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除外），天生在性能上也有加成。

Qt的網路模塊性能比較差，而且難以提升，這是硬傷，除非Qt把現有的架構推倒重來。

此外，Qt的UI運行效率與wxWidgets，Windows的MFC，Linux的GTK+也都沒法比。

主要原因之一是Qt的信號槽這個核心機制，給開發帶來便利，但因此也喪失了一些性能。Qt的信號槽調用涉及鏈表操作，事件處理，還包括最傷性能的互斥鎖，等等，相比直接回調方式。多出100多行代碼，按官方說法，信號槽調用比直接回調慢了10倍左右。可是估計一旦遇到鎖競爭，恐怕遠遠不只10倍了吧。Qt的UI與網路模塊都嚴重依賴信號槽機制。

不過，相對於Java、C#之類，Qt畢竟是C++，運行效率自然要勝出很多。

總體上看，犧牲一點性能，換來漂亮的界面，更高的開發效率，大多時候還是蠻值的。

開發效率高吧，如果你涉及同時寫多個平台的界面軟體

嗯，算是在這個坑裡踩了幾年。然後算是某種意義上有了點兒心得。

開發效率算是高的，的確不得不說，在界面開發上(現在主要)使用QWidget模式，往往複雜的界面通過布局管理也能有一個比較好的分割實現，而且寫代碼qss很方便可以做出很好的效果,而且國際化這些,信號槽的鏈接非常方便等等。但是與這相關的也有一條，自身BUG有點多,導致很多時候可能因為這一條導致研發進度下來，而且有些比較關鍵的地方存在BUG。

這裡給幾個相關的bug，感興趣的可以跳過去看，

QApplication is not compatiable with Wacom 自己遇到並且舉報,當時也是一個客戶有這環境，然後連上看了一下，不過最後好像是只在XP上有這個問題。

Unable to draw OpenGL based widget inside widget drawn using Qt:: WA_TranslucentBackground

無法在一個使用了Qt::WA_TranslucentBackground標誌的窗口中使用openGL繪圖。

QGLWidget doesn#x27;t work with some window flags 都和上面相關Calling winId() into my promoted QWidget#x27;s constructor (and not just in there), causes a lot weird problems in a QMainWindow.

有興趣的可以在平台上逛逛看看還有哪些沒有關閉的，但是研發過程中很大幾率會踩的坑。

總結：

Qt自己的系統內部的兼容性往往是很好的，但是各種各樣奇葩環境，還有一些特殊需求需要使用openGL或者DirectX區域繪製的時候，就會很大可能出現問題(參見上面BUG)。二就是框架的搭配使用(這個在面向用戶開發時很難避免)，曾經在使用其他框架中，碰見因為事件循環的詭異問題，導致退出crash;而且qobject的delete和deleteLater，在因為一次QAction的事件循環引用計數出現問題導致崩潰，因為deleteLater會去做一個去引用刪除，而delete不會，所以當事件循環繼續執行，但是delete刪除掉了對象就會導致事件循環中的對象已經被幹掉了。結果就是直接崩潰。

所以，很多時候因為環境的複雜和需求多樣性的選取，採取Qt也不是一個很好的方案了(也許qt本身的用武之地也就不在windows界面開發上吧，估計在嵌入式系統上可能是一家獨大？)。當年也突發奇想想自己從gdi+在封裝一套上來，但是也因為各種原因啟動不了，不過有一個duilib感覺做得很好吧，好像百度雲也是用的這個。

如果現在要是讓我選windows上的界面設計技術方案，我很有可能會用C# + wpf或者使用瀏覽器外殼+html的模式去做界面。嗯，就這樣吧。

是的，信號槽在小範圍內連接還可以，範圍一大，真不好找出誰發的誰會接收

DEBUG的時候，調著調著，emit了一個信號，然後心裡罵一句，開始找到底是誰connect它了，還好linux的grep命令算是好用，但有時候不同的類里有同名的信號。。。

QT主要是跨平台特性，如果不想跨平台，windows下用WPF就好了，不要提MFC好么？

嵌入式平台首選Qt啊，開發效率把別的框架爆的渣都不剩。運行效率？我沒見到有多差。

其他平台運行效率或許不錯，但是在windows上跟.net的wpf的運行效率還是有差距的。

qt在其他平台最擅長的opengl被windows上的directx秒的渣都不剩。