Qt的前景如何？Qt for Android 好嗎？

01-04

Qt 是諾基亞開發的一個跨平台的 C 圖形用戶界面應用程序框架，隨著 Nokia 的日漸式微，Qt 的前景又將如何呢？Android 上已經有比較好的 GUI 了，那 Qt 還有什麼用？

Android圖形系統確實已經很好了,但是某些就此而下結論說Qt for Android的沒有前途或者未有必要未免太過武斷。

Qt for Android還是有他的優勢：

1. Qt主打的優勢是跨平台,Qt5.2已經可以較完整的支持Android和IOS,目前從跨平台這方面來講Qt是最好的沒有之一。

2. 經過近20年的錘鍊,Qt已經積累豐富實用的,網路,2D圖形,3D圖形及UI庫等,這些如果能在Android上得以重用自然是好事

3. Java在很多複雜運算上面的效率是不如C++的,雖然有NDK,但是使用起來還是略顯麻煩,Qt for Android在這方面就容易的多了

4. 對於一些C++的死忠,而又需要開發Android的應用，但是又不想學習Java Android開發的人Qt提供了一個快速上手的好選擇

5. QML+JS可以方便快速的開發出高端大氣上檔次的UI,同時效率又比HTML5高出將近5倍(網上有測評)

因此,有沒有前途跟用什麼技術沒有太大關係,重要的是你用它來做什麼應用。

Qt作為一個C++的框架在界面方面有它自己的優勢，在嵌入式平台及桌面均有著不錯的表現。作為android之外的一個可選擇的框架，Qt不會就此消失，但Qt for android這樣的方式一定不會有光明的未來。理由：一，android本身的圖形系統已經很完善，加上java類庫的支持，Qt完全沒有在android上存在的價值；二，作為移動平台來說，android的框架顯然更適合移動互聯網，更能滿足用戶需求；三，基於android的應用數量已經非常豐富,Qt在這方面的差距無法彌補；四，android的開發群體數量質量（相比Qt開發者有很大一部分做PC桌面應用）更大更適於移動平台；五，用戶數量和關注度的不同，會讓android與Qt的差距越來遠大。當然，因為meego系統的存在，Qt作為android之外的一個選擇，還會繼續存在下去

移動版Qt沒用，但你想開發桌面版應用，Qt是你不二選擇。

安卓的世界足夠大，可以容下這個重量級的工具。安卓平均硬體水平足夠好，可以跑動Qt編譯的應用。

Qt on Android現在就是為以前使用Qt開發傳統桌面應用的開發人員一條新的出路。有人說Qt很臃腫，學習難度大，而且本身使用c++。那就直接學習qml（入門門檻就是面向對象，信號與信號處理器，屬性綁定，父子樹，JavaScript，巴拉巴拉的QtQuick庫），貌似特性也挺多的。

現在，也就是2015年7月。Qt5.5發布，bug一如既往還沒發現但肯定是有的（可能很坑，也很多），修復的bug的一如既往的多。例如讓人振奮的Qt3D，和QtCanvas3D這兩個模塊，哦還有使用gstream來支持多媒體播放。

還有要重申一點，Qt開發出來的應用在所有平台，界面不是一個風格的，界面不是一個風格的，界面不是一個風格的~重要的事情要說三次。Qt會調用系統默認的繪圖系統。

然後談談Qt on Android

---

2016-11-13

Qt 5.8 都發布了。Qt 這些年來版本刷得有點歡快阿。

QtQuick Controls 2.0 是個很不錯的針對移動設備的QtQuick控制項庫。

Android不需要qt是很奇怪的想法，只能說民用Android手機app不需要qt。

但是android賺錢的不是民用。

高檔次的Android器材，例如空軍和宇航員用的智能頭盔控制板，不用qt編程用什麼？難道用android studio橋接jni的c++？那樣很累的，實際上很多項目在橋接開發了一段時間後，都轉了Qt。

比如美國宇航局一個大型宇航+3d+gis系統，用到houdini和unreal的技術，技術提供方提供的模板都是qt，所以多年來開發這些項目全是qt，然後需要移植一部分功能到android感測器或者android頭盔，難道這些項目還要用java重新開發一次嗎？

這樣一個大項目投資力度比1000個手機app還大，qt不需要用的人多，只要知道：

美國宇航局裡的python和c++，多少是在qt平台。

美國軍方多少項目是qt。

華爾街多少公司，一打開電腦就是qt（python調用c++），就足夠了。

在美國政府，宇航局，軍方，華爾街的要求下，最近幾年多少大型軟體都用qt的庫了。

這裡提一個大型系統，就是說從華爾街的金融公司，到美軍軍艦和飛機，到政府快速反應管理，和宇航地理信息系統，全都是這個軟體配置，幾乎沒有例外了：大型系統的主導就是qt+java，其中java只運行在服務層，戰略層全都是C++，然後嵌套golang，運行於實時linux，有python的快速編程干涉介面。

我個人始終以為，在美國（包含美國承包給加拿大的編程）所使用這部分c++開發花費的錢，可能佔據軟體開發GDP的總量的50%以上！

舉個例子，宇航和船艦系統一個c++程序員，需要幾百萬上千萬美元的配套軟硬體（例如一個unreal引擎至少70萬美元，一個實時linux軟硬體平台往往上百萬。），這都屬於軟體開發GDP。

Qt for android只是Qt everywhere的一個操作系統分支，我看到除了Qt, 沒有一個GUI做到了win,mac, linux,android, winrt, ios等

作為一個資深的QT開發者了解，QT是挪威一家小公司開發的C++的框架。Nokia 只是在幾年前把他收購，又在最近把它出售了。我看法是QT還是把精力放在跨平台的GUI的的領域吧。特別是要跟上WINDOWS 8的步子，以及強化Mac OS的上能力。現有嵌入式平台版本，雖然哪一個OS都會官方或開源版本的移植。自Symbian 被NOKIA丟棄後，在哪一個嵌入式平台都不是人家的親兒子，競爭不過官方開發環境了。

現在大量的QT應用是在工控領域的 ARM-linux ，硬體配置較低，這個領域有很多年傳統用QT了

我看不出來Android需要QT的理由。在我看來，Android現有的原生界面和服務API已經足以滿足需要，為什麼我們一定要引入新的開發工具？我知道有很多人可能會爭論說這是為了可移植性，但是現在手機應用的開發成本並不算高（事實上整個軟體世界的開發成本都在下降，除了微軟桌面系統的非託管平台之外），而且蘋果這些年實際上已經確立了一個高高的標杆：不同的手機上的應用軟體風格應當與本身平台保持一致，而不是在所有平台上看上去都是一樣。而如果我們需要根據不同平台設計界面，那麼何必要一個統一的開發庫呢？

所以我還是認為我應當堅守原生界面。

我很慶幸第一份工作學過用過Qt，對我來說就是一個萬金油的工具。

工作兩個PC：一個Windows一個Linux，家裡一台Mac

跨平台GUI，我中意～

個人開發者可以選擇這個或者phonegap玩玩, 畢竟一下子兼容ios和安卓手機還是足夠吸引人.

如果是想專業開發自然還是選原生的, Qt5.1看似不錯, 但是再發展幾年也難以真正抗衡java開發者組成的原生陣營. 況且Qt當年被N收購後一直在玩弄跟隨他的開發者, 悲慘的前車之鑒, 現在誰還敢真心跟著Qt搞呢?

2013年底更新:

玩了陣子phonegap+sencha touch(phonegap需要配合一個js 框架), 覺得運行效率還是成問題, 功能實現起來也沒有想像的那麼簡單. 恰逢最近Qt5.2發布, ios和安卓支持的不錯, 有engin io做存儲後端支持, 可玩性還是很高的. nokia收購Qt後幾年沒完成的目標, digia看來基本完成了. 加油.

個人觀察：跨平台UI庫，幾乎沒有一個在互聯網領域活動了足夠多的用戶；在傳統軟體領域、企業應用等場景倒是用處很多。大概想過原因：互聯網應用對體驗要求甚高，跨平台庫往往是為了跨平台而放棄了一些系統的獨有特性，從而在哪個平台都不能將體驗做到極致。

站在Android的角度，QT for Android幾乎沒有存在的必要（理由是Android自帶框架在性能和開發效率上都不錯）；而站在跨平台的角度，各移動平台特性很不統一，一個QT UI庫也難做到既全而專。

既不能有效提高Android平台的開發效率，又不能實際收穫跨平台的成果，用它作甚？

我覺得嘛，GUI程序怎麼可能什麼都不改就跨平台？

你在mac運行一個長得像windows的程序你能用？

你在windows運行一個長得像ubuntu的程序你能用？

你在windows phone運行一個長得像android的程序你能用？

你在ios運行一個長得像ubuntu的程序你能用？

所謂的qt for android，只是節省了其實沒什麼所謂的學習成本而已，android上java寫GUI儘管比C#和xamarin爛很多但是怎麼說都比C++強多了。

沒有VC++2013的__await，寫非同步GUI都要哭。

Qt 的前景不是很樂觀。雖然認為它很優秀。問題在於許可證。作為 GPL 許可證和商業許可，startup 都很難接受，可能先 focus iOS/Cocoa 開發，或者直接轉向 Web 。而有一定資金的企業，又有自己的能力開發內部的跨平台 framework 。改成 BSD 許可證還有發展空間。

-----------

失誤，Qt 是 LGPL 的。不過我還是認為 BSD 許可好一些。

之前稍微了解過qt for android的實現，挺有意思的……

程序啟動前要先判斷運行時庫是否存在（判斷裝有運行時庫的apk是否安裝到手機），沒有就先下載安裝。

其次，使用 AIDL 技術從裝有運行時庫的 app 中拷貝 so 文件到自己的 app 下，然後鏈接運行……

然後照著Demo自己簡單拖拽了一個 button，運行時發現按鈕太小了……果斷想了想，Android這麼多年了，多dpi的問題一直是一個噁心的問題，就qt目前這尿性來看，還不得把開發弄死啊？

……qt for android 不靠譜~

安卓需要Qt么，不需要啊。可憐了我的Qt，以後只能在嵌入式跨平台應用了么，期待新Qt帶來變革

一個開發語言要流行起來，前提一定是簡單到大量的蠢程序員也可以用它開發程序，qt使用c++，天生就把不會用指針，會搞內存泄漏的程序員杜絕在外了。

千萬別指望什麼智能指針，c++的智能指針，我認為是另一個更深層次的失敗，首先他不解決蠢程序員的問題，其次他讓程序員覺得c++也蠢了起來。

所以基本上，qt不會有啥事了，這和是否優秀無關

雖然我個人很喜歡QT，但是它跨平台的處境的確是有點尷尬，在Windows下體積與性能不如用VC，開發效率又不如.NET系列；在Mac上體積與性能也不如Objective-C；在這兩種專制系統下都不如它們各自的平台語言，所以現在有很多公司做的支持多種系統的應用並不是用QT一次開發多處編譯的產物，而是針對不同的系統用它們各自的官方語言再實現的結果。

本來QT可以在Linux桌面系統（此處強調的是Linux桌面系統）活得更好的，可是自Ubuntu系統推廣以來，大家幾乎都默認了Pygtk為它的官方開發語言，這主要是因為Python這種動態語言的特性決定的，它天生開源（除非你特意把它的源文件處理成二進位位元組碼），代碼簡潔，開發效率高，功能齊全，也是跨平台的，既能做Web應用，又能做桌面開發，還能作為Linux伺服器系統編程語言（這才是它的用武之地）。

而對於需要圖形界面的桌面環境來說，QT用得最多最好的還是針對Linux桌面系統，但是Linux桌面系統用戶量太少，而桌面環境又太多，不同的桌面環境又偏重於不同的開發語言，所以導致QT難有用武之地（雖然有KDE），但QT5+QML的到來也許能改善一下當前的局面，特別是提供LGPL版的QT for Android/IOS。

不能單純從技術上來看待這個問題，Qt本來是小眾的開發平台，個人認為，它的出現只是解決特性場景的特定問題，Qt帶來的是更加低廉的開發成本和學習成本，對於很多小公司而言，這種優勢足以讓他們獲得更大的利潤空間，如果我是公司老闆，在不增加人力成本的基礎上獲得跨平台（包括桌面和移動設備）的開發能力，何樂而不為？

第一，QT已經脫離諾基亞了。第二，QT是跨平台庫。用QT寫的東西，在Windows，在Linux-base的系統上都能運行，QT的價值不在Android上，在於其它嵌入式應用上。

不看好Qt for Android。以下簡稱QfA.

1. 跨平台只在PC上有優勢，在移動設備上毫無優勢。移動設備整體的應用風格需要保持一致，你外部加進來一個UI，倒是和平台保持一致了。你如何保持和原生UI的這種使用一致性。

2.在開發易用度上，Android(java) API 已經做得很好，包括事件，廣播，服務等Qt里有的基本上Android API里已經做得很好，從Qt開發者轉為java開發者也很容易。而如果要寫QfA應用，開發者不僅要懂Qt，同樣也避免不了要寫java代碼。

3. 如果要寫和其它app通信的時候,QfA的災難性就來了。如果是上層的幾乎等完整的搞一遍Android API吧。另外對於和設備相關的一些調用(GPS/Telephony)等,QfA的工作量一下子就上來了，這時候你還指望QML么？

4.性能呢？ QfA對於圖形渲染區的請求還得在java的介面請求，是不是又要繞了個大彎。

5. 軟體體積。終端用戶要用Qt app，勢必要先裝一個Qt lib，或者在你的app 中一起靜態發布。

在有很多優秀的QfA app出現之前，大家不帶樂意只為一個好的app 去裝一個大的軟體，而會願意選擇一個原生軟體替代。

6.官方支持。目前Qt開發團隊多少人？但目前他們要支持多少平台。 Linux/Windows/Mac/Vxworks/QNX/Android。如果沒有一個比較大的商業級別軟體在用QfA,官方能做的就是讓這個軟體在Android平台能編譯，運行，解決一些明顯的bug。

7. Qt做mobile最好的機會就是被大款看上。她也曾經被看上過(Nokia 和 Intel)。但是被Elop害死了。我恨他！！！！！！！！！！！！！！！！！！！！! ！

----------------------分割線---------------------

Qt是一款優秀的開發套件，我愛她。