快速全面瞭解QT軟體介面開發技術

目錄

l 前言

一、 學習QT可能的目的是什麼？

1. 目的1：只想體驗一下QT?

2. 目的2：當前的專案選擇了用QT。

3. 目的3：為將來做QT技術儲備。

二、 QT的核心技術優勢是什麼？

1. QT在軟體介面開發領域幾乎無所不能。

2. QT幾乎可以適配各種規格的硬體裝置。

3. QT二十年來一直在不斷更新迭代優化升級。

三、 QT的過去和現在以及未來是什麼樣的？

1. QT在軟體介面開發中的歷史地位回顧。

2. QT在軟體介面開發中的現實地位總結。

3. QT在軟體介面開發中的未來地位預估。

四、 QT包含哪些內容？

1. QT核心基礎概念技術體系

2. QT Widgets傳統介面技術體系。

3. QT QML/QT Quick介面技術體系。

4. QT 實用技術適配框架技術體系。

五、 應該如何看待QT

1. QT的核心價值

2. QT並非在所有領域都無所不能

u 總結

l前言

筆者是軟體開發技術培訓機構的一位講師。這篇文章不是介紹QT的具體軟體開發技術，僅僅只是在筆者認知範圍內，試圖客觀的系統的介紹一下QT這項軟體介面開發技術的整體概貌。

QT是當今跨平臺軟體介面開發的一種主流技術之一，是C++跨平臺軟體介面開發的主流技術，沒有之一。

這篇文章是為下面一些朋友們準備的：

你是否在為專案選擇什麼樣的軟體介面開發框架而糾結？

你是否在為專案選擇

你是否在為應不應該學習QT而糾結？

如果這篇文章能夠給你帶來一點點啟發，那麼這篇文章就沒白寫了。

一、學習QT可能的目的是什麼？

沒有目的的學習的唯一價值就是打發時間。

1.目的1：只想體驗一下QT?

QT之所以能夠在全世界範圍內得到廣大軟體開發者的青睞和使用，一個很大的原因是QT入門確實是非常容易。很少的程式碼就能折騰出一個比較複雜的軟體介面。很多人可能會想著體驗一下QT如何快速開發出一個像模像樣的軟體介面。如何讓所有控制元件根據主視窗的大小自動調整大小？這種介面開發常規需求在QT中預設就支援，而使用其它一些早期的介面開發框架實現這種需求可能會是一件十分繁瑣的事情。

2.目的2：當前的專案選擇了用QT。

很多人開始學習QT可能是因為專案上的原因。專案使用了QT，那麼就不得不學習一下QT。

3.目的3：為將來做QT技術儲備。

如果空閒時間比較充足，可以考慮全面系統的學習QT，為將來的職業生涯做一點技術儲備。

二、QT的核心技術優勢是什麼？

沒有核心優勢的技術有什麼學習價值呢？

1.QT在軟體介面開發領域幾乎無所不能。

QT已經支援傳統模式下的軟體介面開發技術體系以及新模式下的軟體介面開發技術體系。傳統模式比如QT Widgets，這種模式下的競爭對手比如MFC早就“躺平”了表示不再升級更新了。新模式比如QT QML/QT Quick，這種模式下的競爭對手是HTML5。HTML5支援的各種特性QT幾乎全都支援了。

HTML5不支援的QT也支援了。顯然，QT應用程式在C++原生程式碼和JavaScript指令碼程式碼以及介面標記語言 QML之間的互操作關係層面上肯定比HTML5方便得多。QT用QT QML /QT Quick就搞定了所有事情，而HTML5和C++建立互操作關係則麻煩得多。QT QML/QT Quick所不支援的特性，都可以由QT官方或者QT應用開發者直接使用C++去擴充套件。一個C++資料型別可以十分方便的註冊為QML的資料型別。

當然也有一些特性是HTML 5應用支援，而QT不支援或者支援得不夠好的。比如對CSS(Style Sheet)的支援，QT Quick應用就不支援，而QT Widgets應用支援CSS，支援得也並不完善。再比如HTML5應用可以使用WebGL技術直接繪製3D場景，而QT Quick應用只能繪製 2D場景；當然QT Widgets應用支援3D,但是必須使用C++程式碼，而不是JavaScript程式碼。

這裡之所以拿QT和HTML5對比，原因在於QT中有一些功能特性其實就是遵循或者參考W3C的一些標準規範來設計的。QT Style Sheet借鑑了HTML CSS的一些概念，比如QT Style Sheet支援CSS2定義的所有選擇器型別，子控制元件跟CSS3的偽元素有一點似曾相識的感覺。正因為如此，QT Style Sheet有時候簡稱為QSS。 另外，QT Quick內建JavaScript引擎，因此QT Quick應用支援HTTP AJAX、WebSocket等HTML5應用支援的功能特性。其中XMLHttpRequest API實現了與HTML5 XMLHttpRequest同樣的W3C標準。QT Quick應用對XML文件的處理實現了 DOM Level 3 Core API的一個子集。 QT Quick的 Context2D實現了HTML5同樣的 W3C Canvas 2D Context API standard。

4.QT幾乎可以適配各種規格的硬體裝置。

QT是一種跨平臺的C++介面開發框架，可以適用於絕大多數作業系統和裝置，包括但不限於Windows、Linux、MAC等桌面裝置，還包括Android、IOS、WP等移動裝置，現在QT官方聲稱QT已支援在MCU上使用。據QT官方網站資訊，QT應用程式已經執行在數以十億計算的各種裝置上。QT實際上既可以在主頻低至400MHZ的低端裝置上執行，也可以在主頻高至2GHZ的高階裝置上執行；QT既可以支援軟體渲染，也可以支援GPU硬體加速渲染。

當然可以適配不代表所有人願意在自己的專案中使用QT去做這種適配。比如QT應用可以在Android和IOS上跑，充分利用QT跨平臺的優點，可以降低全終端應用的開發工作量。但實際上還是很少人選擇使用QT去開發Android和IOS應用，原因在於QT開發的應用在介面式樣和行為模式上和Android以及IOS原生應用相比，還是有比較大的區別；當然HTML5混合應用也有類似問題。如果不能接受這個缺點則真的不應該選擇QT作為介面開發框架。如果追求開發工作量最小化，同時不在意這個缺點，則完全可以使用QT作為介面開發框架。關於這個問題，筆者的看法是如果能接受HTML5混合應用作為全終端應用的開發框架，那麼應該也可以接受QT作為全終端應用的開發框架，否則還是使用各平臺原生應用比較好。

對於效能考量，QT的純C++應用和Android原生應用的效能對比哪個更好？ 這可以參考這個問題：在同樣的硬體配置條件下，IOS效能為什麼比Android優秀一些？筆者認為這其中有一個很重要的原因：IOS應用是C++寫的，而Android應用多了一層虛擬機器在中間,這個虛擬機器就算再怎麼優化也不可能完全不消耗效能。同樣作為純C++應用的QT應用和IOS原生應用，在效能上至少也是有得一拼。另外，QT應用作為C++應用，效能上看跟HTML5混合應用相比，自然是佔優的。當然，筆者在這裡並沒有實際去做這種嚴格的對比測試，這裡僅僅根據筆者個人認知做出的一個常識判斷。

5.QT二十年來一直在不斷更新迭代優化升級。

如果說實踐是檢驗真理的唯一標準，那麼時間也是檢驗價值的重要標準。歷史上多少技術經不起時間的檢驗，紅火那麼幾年然後就銷聲匿跡了，這其中原因可能有多種多樣，歸根結底還是缺乏可持續發展的技術生命力，或者說失去了升級換代的價值。

20年以來，QT的版本從3.X升級到了4.X，又升級到了5.X，現在又升級到了6.X。這說明QT官方在不斷的升級維護著QT。因此可以說QT表現出了頑強的技術生命力。QT作為一個軟體介面開發框架，可以毫不誇張的說是C++跨平臺軟體介面開發框架中碩果僅存的唯一存在。其它的C++軟體介面開發框架，有一些僅限於某一個OS，有一些僅限於少數幾個公司使用，有一些生命週期僅限於那麼幾年。

三、QT的過去和現在以及未來是什麼樣的？

沒有人想追隨一項沒有未來的技術。

1.QT在軟體介面開發中的歷史地位回顧。

QT是一個二十年前就存在的技術，一直在比較穩定的進行版本升級迭代更新，這件事情本身已經足以說明QT在軟體介面開發框架領域獨一無二的歷史地位。

QT的版權其實已經變更過多少次了，或者說支撐QT進行升級迭代的公司已經變更過幾次了，其中不乏全球知名大公司。這裡列舉一些：

6.QT在軟體介面開發中的現實地位總結。

首先講一下國內公司對QT軟體工程師的招聘需求。

分別使用兩個不同搜尋引擎搜尋了一下QT相關的職位資訊，基本上都有巨量搜尋結果。這並不代表當前存在這麼多不同的QT職位，但是這個數量級可以說明國內公司對QT軟體工程師的招聘需求還是比較旺盛的。國內現在國產化替代顯然已經是大勢所趨，而國產OS基本上都是基於Linux的。Linux上N多的軟體是用QT開發的。

其次對比一下 QT現在的市場地位。

無論是看支援的OS的種類的數量，還是看支援的裝置的種類的數量，相比於其它介面開發框架而言，QT無疑都是位居首位。這是QT的超級跨平臺能力決定的。儘管筆者沒有實際深入研究過其它介面開發框架，但是一個顯而易見的情況是， 用QT寫的程式碼，確實是可以在重新編譯之後至少在幾種最常見的OS和裝置上執行的。 Hybird模式的一些介面開發框架，基本上是HTML5 + JavaScript應用,所支援的跨平臺的廣泛程度以及執行效能顯然不能跟QT相比。

最後討論一下功能問題。

跟其它介面框架相比，QT對介面開發相關的特性的支援能力怎麼樣呢？ 這個只需對比一下不同介面開發框架的原始碼的大小瞬間就能理解。相比於QT 20年的積累，其它C++介面開發框架基本上都可以稱得上是“原型框架”。所謂“原型框架”是說大多數是輕量級的嬰兒時期的C++框架；這些C++框架無論知名度還是應用的廣泛程度，與QT相比，都不可同日而語。QT是一個有著長期歷史沉澱積累的古老框架；當然古老肯定是有不少缺點的，這是必然的。QT過於龐雜笨重；但是QT也是在不斷的更新迭代升級的，新的QT QML/QT Quick 相對於古老的QT Widgets而言，也是一種“輕量級”的新生代介面開發框架；而QT QML/QT Quick和QT Widgets是可以互操作的，就是說QT已經實現了在同一個應用程式中新老框架相容和互通有無。

7.QT在軟體介面開發中的未來地位預估。

這裡講一下QT現在所屬的Digia公司。

Digia公司在包含中國在內的全球十幾個國家開展業務，這隻包含其付費業務，而免費QT已被全球很多國家的開發者選擇使用。QT提供免費社群版本和付費商業版本。Digia公司是一家小而美的IT公司。因此QT健康有序的可持續發展是比較有保障的。

有一些人可能會有這種疑問：選擇在商業公司控制之下的免費QT作為技術路線，是否蘊含了一定的商業風險？在筆者看來，即便發生了最壞的情況比如不再提供免費社群版本的升級更新，那麼以QT目前版本的完善程度而言，在免費開源社群以當前老版本為基礎長期維護一個免費版本分支然後獨立迭代更新升級也是可行的。這個事情在開源軟體世界是有先例可循的，一些知名的開源軟體在被商業公司控制之後的發展軌跡也有正如上述所言的。

四、QT包含哪些內容？

縱觀全域性帶來的價值可能遠遠超出想象。

1.QT核心基礎概念技術體系。

包含了QT核心概念及其實現。比如物件模型、元物件系統、訊號與槽機制、事件迴圈機制、狀態機機制，物件屬性系統機制，國際化機制、跨平臺支援機制、IPC和多執行緒機制，以及基礎資料型別等。

8.QT Widgets傳統介面技術體系。

包含了佈局管理、焦點管理、事件迴圈、圖形繪製、視窗控制元件、視窗式樣，以及Style Sheet，模型檢視代理框架，圖形檢視框架等。這些屬於QT傳統的介面開發模式。

9.QT QML/QT Quick介面技術體系。

包含了QML標記語言、JavaScript支援、QT Quick佈局管理、焦點管理、視窗控制元件，與HTML5應用類似的對W3C標準的支援，比如Canvas/Context2D、LocalStorage、WebSocket等，以及介面特效支援，比如動畫框架、圖形效果框架、粒子系統框架等。這些屬於QT比較新的介面開發模式。

10.QT 實用技術適配框架技術體系。

包含了音視訊框架、網路框架，以及各種硬體訪問框架，比如對BLUETOOTH、WIFI、NFC、SERIAL PORT、GPS等硬體裝置的支援。當然，由於QT真正的核心優勢是介面開發，這些支援大部分情況下都只是作為一種應用程式和底層裝置軟體API之間的一種適配層存在的，很多時候只是對 OS層面API的一種高層封裝，或者說QT提供了相比於原始API而言更加簡化和更加“QT”的API。

五、應該如何看待QT

降低產品研發成本，提升產品研發效率，提供藝術級的使用者介面體驗。---QT官網

1.QT的核心價值

QT支援的特性越來越多，但是QT最核心的價值仍然沒有改變，那就是最優秀的跨平臺軟體介面開發框架。有一些讀者朋友看到這裡可能會有一些不爽，認為QT能做的遠遠不止這些。筆者認為能做不一定表示能做到最好，甚至不一定表示能做好。筆者在這裡並沒有故意冒犯這些讀者的意思，僅僅是就事論事表達個人觀點，僅供參考。

使用QT官網的話來講QT的價值在於降低產品研發成本，提升產品研發效率，提供藝術級的使用者介面體驗。這表明本質上而言QT最核心的優勢仍然是專注於提升使用者介面體驗。這也正是筆者對QT的價值的一個基本認知。筆者認為QT官網上的這三句話並非空穴來風，而是言之有物的。

首先來說降低研發成本。

設想這麼一個跨平臺產品研發場景：為了公司的產品能夠給Android、IOS、Windows、Linux、 MAC使用者使用，是否會考慮針對每一個平臺獨立開發一個app，每一個平臺都招聘一些專門的軟體工程師呢？相信這會是很多公司的常規做法。但是考慮一下使用QT來開發這種產品，情況立即就變化了。這時只招聘一些QT軟體工程師，只開發一份程式碼，針對每一個平臺獨立編譯出一個 app。顯然後者至少降低了研發人員數量，從而降低了公司研發成本。

其次來說提升研發效率。

QT是一個完全面向物件的設計，有著比較嚴謹的型別繼承體系，以及比較好用的基於C++的API介面。關鍵的是QT提供了使用者介面開發所需的各種實用型別，對於軟體介面軟體工程師而言，簡直就是急人之所急想人之所想。無論是開發本機獨立應用還是開發網路客戶端應用，無論是開發基於套接字的傳統網路應用，還是開發基於HTTP AJAX的現代化網路應用，或者開發基於WebSocket的新型網路應用，QT都提供了很好的支援，有些情況甚至提供了多種支援方案供選擇。如果說C++相比其它一些“現代化”高階語言而言，執行效率高，但是開發效率低，原因是C++缺乏一套獨立的完善的大型的實用類庫，那麼QT已經徹底彌補了這個缺憾，因此QT提升C++開發效率就是自然而然的事情。另外QT入門門檻非常低是一個不爭的事實。當然，如果沒有系統全面深入掌握QT各項技術，那麼在實際開發工作中遇到比較複雜的應用場景，也可能出現一些問題；這些問題不能說是QT的問題，只是說QT的複雜性導致初學者遇到沒有掌握的情況時也可能錯誤的使用QT導致一些問題。

最後來講一下提供藝術級使用者介面體驗。

QT的各種特效框架，提供了一些遊戲開發框架所提供的功能，比如動畫框架、粒子系統框架、圖形效果框架，而遊戲最講究的就是使用者體驗。這樣來講QT官方所稱的提供藝術級使用者介面體驗自然所言非虛。

11.QT並非在所有領域都無所不能

前面說QT在軟體介面開發領域幾乎無所不能。請注意限定條件軟體介面開發領域。QT受限於自身各種特性，並不適合用於網路伺服器軟體開發領域；網路上很多人吐槽QT開發的網路伺服器的效能問題。

QT提供了網路程式設計框架，但是並不適合作為網路服務應用的API框架。原因在於QT的很多框架都支援QT的訊號與槽機制，這類設計選擇使得QT保持了QT訊號與槽機制帶來的鮮明的QT特色，但是這個特色在一些情況下極大的降低了應用程式的效能，在一些多執行緒情況下使用不當時容易導致程式執行不穩定。可能正是如此， 筆者發現QT中一些框架的API並沒有使用傳統的訊號與槽機制。

因此，真正學習涉及這些領域的技術時，還是應該學習使用作業系統提供的API介面。當然，在一些並不以效能作為評價指標的桌面應用和移動應用以及嵌入式應用等應用場景中，使用這些QT框架的API 是沒有任何問題的。在使用QT的這個適配層時，必須對QT的一些基礎機制有比較良好的理解，否則容易發生因為錯誤的使用導致問題的現象。

沒有QT的時代，只有時代的QT。就目前而言，並非QT的時代來了，而是QT已經成功跨越了幾個時代，大概率可以成功跨越下一個時代。如果說時代的QT已經迎來了QT 6.X版本，那麼作為跨平臺介面開發利器，時代的QT在未來是否能夠得到更大規模的應用呢？讓我們翹首以待。

u總結

這篇文章討論了學習QT的目的，QT的核心技術優勢，QT的過去和現在以及未來，QT包含哪些內容，以及如何正確看待QT。

如果這一篇文章能夠解答你對於 QT的一些困惑，那麼筆者寫這篇文章的目的就已經達到了。

這篇文章純屬筆者個人觀點，僅供讀者朋友們參考。限於筆者知識水平有限，加上時間有限，錯漏在所難免，敬請諒解，如蒙不吝批評指正，感激不盡。