HTML5與Qt QML僅從做UI的角度比較，哪個更便捷，哪個更強大，哪個(被渲染)性能更高呢？

01-14

做UI啊。如果是桌面應用，QML可以更快速。如果是手機UI，H5絕對佔優。

畢竟Qt提供的那一套控制項庫更適合桌面應用，而當年諾基亞都開發了塞班和米果的QML手機控制項庫，現在Ubuntu，旗魚，黑莓都有自己的QML手機控制項庫。

渲染性能上。QML有絕對統一的介面規範以及渲染機制。（跨平台是這樣的）。 H5桌面系統一套，就谷歌做的好。手機WebKit嗯，但是系統對WebKit的支持也不能說表現一樣。

接下來我來說說QML吧。 QML的執行引擎是基於Qt的V4引擎，V4最大的改變就是添加了類型。（有關源碼分析，請移步qtdeclarative 源碼略讀）添加了類型讓QML的屬性綁定相比於之前的版本（Qt4的QtQuick 1.x）有極其大的提升。屬性綁定（數據綁定，表達式綁定）。嗯，在QML中隨處可見的屬性綁定，雖然有H5中有類似數據綁定的JS庫。但QML語法上就支持了。

QML的渲染方式相較於之前的版本也有了重大的更新。之前的版本（Qt4的QtQuick 1.x）更接近widget，雖然是Griphics/view，但是渲染更多是優先提交給cpu處理。當然，在N9(嗯，第一個完全使用QML構造應用的系統)，會使用gpu，有硬體加速嘛。

現在的QML渲染方式更傾向於優先使用顯卡。（所以現在使用QML需要良好的顯卡支持，例如正確安裝顯卡驅動）。

簡單扯扯現在QML的渲染繪製機制吧。

1. 基於事件的,基於Griphics/secen

2. 有兩個線程，一個繪製，一個渲染。

3. cpu負責繪製，gpu負責渲染。

4. 當需要重繪時，繪製線程暫停，渲染線程進行渲染，渲染完畢，繪製線程啟動，繪製。

嗯，上面那個我是看Qt英文文檔，自己理解的，敘述有出入。此外，Qt正在開發的Qt3D，類比WebGL，其性能以及可部署性遠大於H5的WebGL，嗯，是個重型武器。其實也反應出了QML渲染和繪製的效率。

補充：我最近對這個問題有了新的認識，前端好招，但是貴。。。。

--------

這不僅僅是個技術的問題，或者說壓根不是個技術問題。

首先，用 html5 做桌面，只要有若干 c++ 或者 nodejs 開發人員做支撐（取決於需求和框架），上層的邏輯和 UI 可以全部交給前端工程師搞定，無論從交接還是招聘的角度，都方便的多。

用 qml 可能架構乾淨了，性能好了，可你到哪兒找通這門技術的工程師呢？讓前端現學，人家嫌不來錢不樂意，Qt 原生程序員又不好找（本來基數就小，就算找到了，這部分人現在大都琢磨著轉型，未必想給你干這個）。這種情況以後會越來越麻煩。

我之前做過原生 Qt 桌面應用，身邊同事懂 Qt 的不在少數。我也考察過 qml，確實有不少成功案例，包括 ktv 點唱機那種花哨的界面，用 qml 都是完全可行的。但是最近的項目，我還是選擇了基於 html5 的方案，主要考量就是以後的維護和交接。而且夥伴團隊跟我溝通過這裡面的利弊之後，他們新上的項目也採用了 html5 方案。

第二點理由，前端領域的可用工具比較多，包括 jQuery 這樣的工具庫，以及 angular 這樣的框架，可選項很豐富，qml 在這方面就差很遠。

第三點理由，調試。我對 qml 了解不夠深入，對調試手段了解不多，但是基於 html5 的方案調試起來實在太方便了，UI 層無需任何改動，直接用 Chrome 瀏覽器就能調試，必要時增加些 mock 代碼即可。

html5 做桌面的劣勢主要是系統級介面的缺乏，解決方法其實也很多，可以使用 nw.js 這類 nodejs 和 webkit 的集成框架，也可以自己封裝 native 和前端的消息通信。對於需要界面展示、前端又不好做的需求（比如播放視頻），可以動用 npapi 插件技術解決。

另外有評論認為 qml 的性能比 html5 好，這一點我認為除非是特殊的行業應用，大部分時候可以忽略。對於一般的業務， html5 的整體性能足以應付——你對網易雲音樂和有道雲筆記的性能滿意嗎？你的應用比這倆複雜多少？對於一些性能有要求特殊模塊，直接動用 c++ 即可。

以上說的是桌面端，移動端就不需要爭論了，鐵定 html5，移動端 qml 找個典型案例都費勁。

ps：啥時候能出個 React Qt？實際上很多時候用腳本就是想提升開發效率（不大喜歡pyQt），不是想要那些複雜的 gpu 動畫效果。React native 的思想，可能比 qml 更實用，也更能體現差異性。

這是個非常好的問題，不過以我的了解程度，還沒辦法給出好的回答。

QML 組件化特徵比較強，這一點是 HTML5 不具備的。原始的 Web 開發方式（HTML/CSS/JS）更像是在用磚頭砌牆。

便捷h5勝。

性能qml勝。

強大，這個沒標準吧？

投QML一票

之前有一個項目。急著要出產品。拉了2，3個JAVA工程師，3個月就把第一版做出來了。UI部分用的是QML。

後面領導突然覺得不夠潮流，不能在瀏覽器運行，決定拉了一幫人馬20多個人，用Node.js 和HTML5去做。做了幾個月，做不出來。

回來後老老實實用QML繼續做，越來越好。

用html5去做，同時刷4路1080p的攝像頭視頻，能做到嗎？QML可以做到。

當然，QML坑挺多。

當然，後面做HTML5的人跳槽了。薪資杠杠的。他們跟我說寫QML比寫HTML快且爽，但怕找不到工作。

這個問題其實想真正回答好，是有難度的。Qt重在跨平台的桌面應用，而H5則重在WebApp的體驗，二者本沒有多少重合點，但近年來瀏覽器被拿來做UI了，所以才有了糾結的開始。

對QML了解不多，只是隨便百度了下，僅知道了個所以然。從題主關注的幾點出發，主要以下幾點：

一、便捷性

與H5的大眾型普及度來看，QML只能算是Qt家族的一小分支，屬於小眾類。QML提供了專有設計器，H5的設計工具則琳琅滿目。QML的語法類似JSON語言，如果離開設計器，可讀性和可維護性較差。而H5的HTML和CSS黃金組合，則更容易獲得開發人員的支持。

兩者運行都需要自己的容器。QML離不開Qt的一堆庫，開發基於組件式，調用Qt的各個功能，開發比較便捷；而H5離不開瀏覽器支持，但如果要考慮一個個性化的界面，H5需要把瀏覽器嵌入現有的的開發框架。雖然已經有很多愛好者對各種流行的瀏覽器內核進行了令人嘆為觀止的精簡，但發布包依然動輒十幾兆，而且需要c++等語言與庫的捆綁，技術難度較大。但如果解決了上述問題，H5本身的開發難度就小case了。

二、功能性

QML有點類似Adobe前些年推出的Flex，有自己的ActionScript和MXML語言，在自己的框架里使用，可以充分的調用Qt的各個功能包，界面方面比較循規蹈矩，很難衝出Qt本身的組件框架。

H5依靠Javascript以及HTML5強大的canvas、css3的動畫支持，可以做出更自由、更充滿靈氣的界面。這一點無可置疑。

三、渲染性能

沒比較過。但從二者的實現原理來看，Qt本身是基於OS的native層的，而H5則需要間接的通過js這一層腳本去調用。雖然現在js的性能已經很強，但畢竟以腳本去對抗native，還是略佔下風。不過好在現在用戶的電腦和設備配置都越來越好，一點點的性能差異幾乎難以察覺。

從開發者角度，在技術選型時，不僅僅要考慮上面的幾點因素。還要考慮技術的學習成本、可維護性、擴展性、可部署性等多方面。技術沒有絕對的優和劣，最合適自己的就是最好的選擇。

沒大規模寫過QML，憑印象答下。便捷程度的話，怎麼可能有東西比的上H5呢，幾千個css樣式和幾百個標籤，各種排版布局，各種矢量繪圖，甚至還有webgl這種3D的東西，,再加上各種第三方庫,QML無疑在便捷、強大程度上差太遠了。如果說渲染效率的話，這個不好比較。但據我對chromium的渲染機制的了解，絕對遠比qt的渲染機制強大的多的多。HTML的解析，chromium早就做到多線程解析，渲染的話，chromium的cc層現在已經非常強大了，做到多顆layer tree架設在各種線程，錄製渲染指令，回放渲染指令，合成，上屏，都能做到不同線程並發，這方面QML肯定又要差的遠。但HTML有個致命缺點就是規範太複雜，以至於要實現完整的html標準會導致低下的性能。未完待續·····

從qt到qml再到html5，現在開發單機應用，html5開發界面，qt開發後台服務，你說呢

Qt本身在PC端已經憑藉良好的跨平台特性和設計良好的架構已經佔據了統治地位，Qml的推出無疑讓開發者做界面更加得心應手，採用M/V模式使得與c++的交互也顯得那麼渾然天成，隨著Qt5.*版本對移動平台的大力支持，相信Qt大有可為。

而h5作為移動端目前炙手可熱的技術之一，當然不容小覷，如果之前就是做web開發的，還是建議在移動互聯網上下功夫，繼續堅持下去~