Qt5及模塊架構分析

關於框架

Qt這個框架歷史悠久，因爲當年桌面操做系統的GUI程序開發比較費勁，通常使用普通語言如c、c++或者平臺自身提供的難用框架，windows、Linux、mac各有各的不一樣機制。1991–Haavard Nord和Eirik Chambe-Eng開始開發將會支持X11和Windows的Qt，1994–奇趣科技公司成立，主要提供跨平臺、面向對象、易用的GUI程序開發框架。另外隨着Qt誕生的還有KDE，一個爲Linux提供圖形界面的開發庫和框架。

隨着逐漸的發展和社會的需求，Qt版本不斷演化，功能不斷增多。好比經典的Qt4系列，當年爲知足嵌入式開發提供的Qt/Embedded。如今這些版本已經退出舞臺。一直以來，對Qt影響比較大的轉折點一是2008 Nokia從Trolltech公司收購Qt,二是2012 Aug 09 諾基亞正式放棄該框架。

諾基亞收購Qt是由於從那時起，智能手機開始流行，最先的iphone發佈，android也開始發展，而Qt是當時是比較流行的嵌入式設備開發框架。單從時間節點看，諾基亞在智能手機發展初期並沒用太落後，只是後來的發展過程比較緩慢，逐漸和蘋果、android拉開了距離。

Qt被諾基亞收購後，其開發方向在跨平臺的同時，主要面向新的基於Linux的智能手機操做系統。因爲Qtwidget自己不適合觸摸操做，因而偉大的QML技術誕生，QML是專爲可觸摸界面定製的開發語言，構成了meego系統的界面框架。隨着不斷的發展，諾基亞在智能手機方面被蘋果和谷歌甩的更遠，最終放棄手機業務。Qt也被移交給了另外一家芬蘭公司。

從這時候起，Qt開始進入5的時代。技術架構方面有了完全的變化，主要是更細粒度的模塊化和重點轉向基於opengl的QML、QtQuick技術開發。這個時候的QML繼承了諾基亞的遺產，而且完全轉向以opengl爲底層，使得繪圖性能更好，更適合現代圖形界面開發。Qt技術的演變一直以來都是很天然的，符合社會對不少方面的須要，固然，因爲其是一個開源項目，沒有了實力資本的支持，Qt一直以來 不少模塊要麼缺乏功能，要麼bug比較多。直到目前（2016），Qt5.6系列發佈長期支持版本，這才標誌着Qt5系列已經相對比較穩定。固然，新功能的增長和優化仍是會根據需求繼續發展。

關於架構和模塊

Qt5開始更加註重模塊化，從上層邏輯上分爲Qt Essentials、Qt Add-Ons、Technology Preview、商業模塊和tools 幾部分。代碼層面，Qt Essentials中除QML部分模塊如qtdeclarative.git、qtquickcontrols.git爲獨立倉庫，其包含的多數模塊在qtbase.git倉庫，如Core, Gui, Widgets, Network等。其它Add-Ons、技術預覽模塊通常爲獨立倉庫。另外還有工具類如widget設計器、幫助系統、安裝程序製做、構建系統、QtCreator、SDK等周邊項目。

隨着需求的不斷變化，Qt5新增了不少功能，已經不只僅是開發界面，而是成爲功能豐富的多用途框架。其中一些新功能放進了基礎模塊，一些以獨立的附件模塊提供。下面是Qt Essentials架構：

Module	Description
Qt Core	被其它模塊用到的非圖形模塊類
Qt GUI	用於GUI界面開發的基礎類，包含 OpenGL.
Qt Multimedia	用於多媒體開發的音頻、視頻、無線和相機功能
Qt Multimedia Widgets	上述功能的widgets實現，方便開發
Qt Network	網絡功能
Qt QML	QML和javascript解析引擎
Qt Quick	基於上述語言的現代界面和功能開發框架
Qt Quick Controls	用於開發具備傳統桌面風格的qml控件
Qt Quick Dialogs	各類qml實現的對話框
Qt Quick Layouts	用於qml界面開發的佈局工具
Qt SQL	數據庫抽象
Qt Test	測試
Qt Widgets	基於widget的GUI開發控件

其它附加模塊請參考官方文檔。

關於跨平臺和移植

Qt自身的屬性就是跨平臺，即相同功能的api能夠在各個平臺編譯運行。爲了儘量達到此目的，勢必會照顧各平臺共有的特性和約束，另一些平臺專有的功能以Extras模塊提供。由於跨平臺的特性，因此註定了其在各平臺上並非最優化方案，通常各平臺的原生開發語言和框架在不少方面要優於Qt。

雖然Qt自己是C++，但因爲各平臺有本身的原生語言，如android，而且上層的api都是經過這些語言導出，雖然Qt能夠經過封裝的形式調用，但無形中添加了不少步驟，性能上可能會有點折扣。

關於Linux移植方面，對於Qt Essentials的多數模塊，通常只須要移植widget的窗口系統、QtQuick的opengl層、Multimedia須要的音視頻庫，驅動的移植較少。而對於其它模塊，如傳感器，這些模塊和設備綁定的關係比較密切，除了中間庫，很大程度上還須要本身移植對應的硬件驅動。

通常若是想要搭建一個基於Qt的平臺，建議的途徑是選一個適合應用場景的開源Linux分之，通常要對Qt有較好的支持。在這些分之中，Qt移植相關的工做如安裝包文件的創建等基本已經作好，本身參考修改用於新的Qt版本便可。另外所選的Linux分之要儘量有着不錯的activity和維護支持，不到無可奈何，不建議本身維護Linux分之。

移植工做有時候是很噁心的事情，Qt自己是一個上層api框架，不少功能須要調用其它中間件實現。而Linux上比較麻煩的就是軟件的管理，一是版本二是依賴關係。可能爲了使某功能工做，須要依賴庫A，而A又依賴B，B又依賴其它亂七八糟的庫。依賴解決後，若是庫的版本不符合要求，通常會產生二進制兼容問題致使程序沒法運行和莫名其妙問題。

現狀評價和方案選擇

整體上，現階段的Qt已經能夠知足不少需求，性能和體驗上有所提高（固然還有各類缺陷）。目前，真正的基於操做系統的嵌入設備開發通常會選擇改造的android，因爲android系統的完善及應用支持，這方面的優點要遠遠大於Linux+Qt。而Qt通常能夠用於一些對應用數量要求很少，驅動設備不是不少，界面須要靈活定製的應用場景，這方面Qt具備必定的優點。

而若是能將硬件驅動支持、應用數量、Qt的靈活性結合，則優點會更好。具體須要根據應用場景選擇，好比作手機系統，Qt雖然靈活，但缺少豐富的應用生態，在如今的市場下，不太適合。通常選擇Qt，要麼是應用數量要求不高，要麼就得本身搭建生態環境。另外硬件的驅動支持也是重要的參考。不少方案都只提供android開發包，Linux的東西較少。雖然有技術可讓Linux利用android驅動，但這種繞彎子的方式可能沒有直接使用android有效率。

另外對於物聯網等應用，通常不須要圖形界面，所用的芯片通常爲單片機，跑Linux不合適。固然，在設備成本不敏感的狀況下，不以爲浪費或者跑Linux更合適的場景下，Linux+Qt也是選擇之一，另外還能夠用嵌入式web服務。