標籤：
～～～～～圖形效能部分～～～～～
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
Qt 架構的圖形效能高，網路效能低，開發效率高——Qt中分為好幾套圖形系統，差不多代表了2D描畫的發展史。最經典的軟描畫系統
