跨平臺應用：Qt 對決 HTML5
我覺得作者分析很到位，特此翻譯出來，看者有緣。我開通了微信訂閱號——“程式視界”，漫談程式人生，有趣，有能量。微信掃描下面的二維碼即可關注。
也可以：開啟微信-->“新增朋友”-->“公眾號”-->搜尋“微信視界”-->關注。
好啦，進入正文啦——
----------------------------------------------
儘管對於面向大眾消費市場的應用來講，為每個平臺構建一個獨立的原生app已經被證明是當下最成功的方法，但跨平臺仍然很有意義。在本文中，我們來看看最受歡迎的選擇，使用HTML5的混合web應用和積極進取的挑戰者 Qt 。
為什麼選擇Qt
那些熟悉Qt歷史的人看到它被描述為“積極進取”可能會感到驚訝。Qt一開始被設計來構建跨平臺的桌面應用，它的創始人在1994年開始為它工作！然而，當諾基亞收購 Trolltech 後，Qt開始對移動開發感興趣，公司開始大力發展Qt，大量投資，想讓它成為構建移動應用的理想工具。不幸的是，諾基亞剛剛作出這一戰略決定沒多久，iPhone面世了。iPhone改變了遊戲規則，移動應用構建很快從面向帶數字鍵盤和Qwerty鍵盤的裝置，轉向以觸控操作為主的裝置。前Trolltech工程師意識到他們需要一個非常特別的方式來建立應用來支援諾基亞參與競爭。
當史蒂夫·喬布斯在iPhone面世時說iPhone比競爭對手領先五年時，基本上是正確的。可能因為 Google 的高官們意識到了iPhone的領先優勢，Android已經縮短了一些差距。不幸的是，諾基亞最終放棄了它自己的基於 Qt 的裝置，轉而支援 Windows Phone，然而他們在軟體上花費了太長的時間，最後他們在生態系統的競爭中遠遠落在後面。他們把 Qt 出售給了他們的一個主要的服務供應商——Digia，Digia 最近為 Qt 這個產品建立了一個獨資的實體——the Qt Company。只有從諾基亞完全解脫出來後，Qt才又迴歸到它作為跨平臺框架的本源，開始支援主流的移動平臺。然而，與此同時，其他人已經看到了諾基亞投資移動應用建立起來的偉大基礎，因此，BlackBerry 10（黑莓10），Jolla Sailfish（旗魚），Ubuntu Mobile 和 Tizen 平臺都選擇 Qt 作為核心框架。
從個人角度來說，我在 2011 年早些時候，用 Qt 為 Symbian（塞班）重寫了一個流行的 iOS 遊戲。當時UI設計和通用除錯工具還有點不成熟（譯者注：現在，2015，又好了很多了），但在我工作過的所有平臺上，它有最簡單的學習曲線和最愉快的開發經驗（原作者注：我這麼說可沒拿一分錢）——儘管 Qt 的核心使用了對開發者不太友好但高效能的C++。我甚至在某些配置相當低的硬體上也達到了 60fps 的效能。學習 Qt 新的UI技術——Qt Quick——相當簡單，你可以在短短几天內為遊戲構建出選單介面。
為什麼選擇 HTML5，或者不選擇
HTML5是開發者在構建跨平臺移動應用時最流行的選擇，然而，它似乎慢慢有點兒失寵。Web browsers和Web views在每一個平臺上都可用，web開發者可以把建立網站的技術平移到構建app上。像 Cordova（PhoneGap）之類的開源框架讓使用HTML5的開發者可以訪問移動裝置的附加功能，並且將應用打包成每個平臺的原生格式也很簡單。額外的好處是，您通常可以用最小的付出，同時擁有一個基於Web的應用和一個放在應用商店裡的應用。在構建以UI為中心的應用時，HTML5通常比原生應用更有效率。當涉及到使用庫和框架來構建移動web應用時，HTML5也有一些尷尬。混合web應用程式有一個特別的優勢(至少在 iOS 上)，能夠直接更新他們的程式碼，避開應用程式商店的審查過程（除了重大變化）。
鑑於其普遍性和龐大的開發者基礎，為什麼HTML5不是預設的跨平臺方法？儘管有許多優點，混合web應用開發者一直在和效能問題做鬥爭（一定程度上是由於不完整或過時的webview實現造成的，在最新版本的iOS和Android上，這個問題已經被修復了，儘管這將需要一段時間來滲透整個安裝基數）。還有一個問題是各種各樣的移動瀏覽器對標準的支援亂七八糟（這點正在改善但還遠遠沒有徹底解決）。Web技術還沒有真的被設計來滿足移動使用者現在期待的充滿動畫效果的UI。這也是備受推薦的框架 Famo.us 致力要解決的問題。
一些非常高調的消費類初創公司已經公開從web混合應用切換到了原生移動應用。關於這些切換，最常見的說法是缺乏足夠的相關工具。可以肯定的是，讓web apps在記憶體受限的前提下，在移動裝置上表現良好是可能的，但鑑於當前的除錯和效能分析工具的現狀，與生產原生應用相比，那仍然不是一件容易的事情。這麼說吧，並不是所有的應用程式需要完美的UI動畫，我也不是拿HTML5和原生應用相比，所以，讓我們來看看它和 Qt 怎麼個頂個的比較。
Qt 對比 HTML5 ——正反兩面
支援的平臺
- HTML5的支援無處不在
- Qt支援所有主流平臺（而且非主流平臺碰巧用它做UI）
雖然理論上你可以用HTML5適配更多平臺，但這不是大多數開發人員在現實世界裡使用它的原因。HTML5開發者越來越多地放棄瀏覽器以及構建混合app。大部分移動開發者針對Android、iOS、Windows Phone和BlackBerry 10當中的幾個平臺開發。Qt 不僅支援這些平臺，而且還支援更多。事實上，在實踐中我們的資料表明，平均來看，Qt 開發人員實際上覆蓋的平臺比HTML5開發人員還略多一點。結果是，對於那些想在智慧手機、智慧電視等任何平臺執行軟體的開發者來講，Qt相比HTML5的一個顯著優勢讓兩者不分勝負。
學習曲線
這點取決於你是否已經是一個web開發者。如果你是，學習構建移動web應用可能比學習Qt容易些。然而，如果你是新手，那Qt有明顯的優勢——你只有一個框架要學，而HTML5呢，你在還沒開始的時候就要從十來個框架中選一個。Qt 還有非常強大的文件，而web框架則不一定有。在一個公平的比賽裡，這是 Qt 的一大勝利。
開放性
- HTML5是開放標準，有多個開源實現。
- Qt是開源的，但是有雙重許可，由一個單一的供應商有效控制。
顯然 HTML5 比 Qt 更加開放。這不總是一個優勢。建立標準並讓多個供應商去實現的過程是漫長的，Qt 可以更靈活。如果你真的需要讓開源專案修復一些Bug或新增一個新特性，你可以自己做或者花錢請人去做。如果你需要支援 IE 並且 IE 有個問題，你必須自己解決或等微軟來解決。還有，沒有供應商能鎖定HTML5，讓web哪兒也去不了。別人可以買 Qt 並把它帶向與你目標不符的方向，或者他們可以把價格提高到超出你的預算。HTML5 在這點上有優勢但不是一個明確的勝利。
成本
- 構建HTML5是免費的。也有一些非必須的付費工具可以提供幫助。
- 對於移動端的大多數商業應用，Qt 需要商業許可證書。
Qt 的開源許可協議與大多數應用商店不相容。儘管 Qt 的 iOS 版本是在開源狀態下開發的，但你需要一個商業許可才能在應用商店上架。使用 Qt 為 iOS 和 Android 商店開發移動應用，最低的成本是一個月25美金。HTML5 勝出。
跨平臺相容性
- HTML5的一個標準對應有多個獨立實現。
- Qt是一個供應商在多個平臺上實現相同的執行時環境。
多個實現，與幾個開源夥伴和一個大型社群一起彙報和圍繞相容性問題工作造就了一個非常健壯的平臺。即便如此，有一個供應商確保所有平臺表現一致，對你的應用相容性來講，幾乎總是更好的。Qt 獲勝。
效能
- HTML5的DOM不是為現在的移動應用構建的。
- Qt Quick（QML）的 scene graph是直接在 OpenGL ES上構建的。
兩個環境都使用JavaScript。然而，使用 Qt ，如果你真的需要原生平臺的功能或效能，會更容易下降為原生程式碼。使用 Qt ，JavaScript 和原生代碼之間切換的效能損失要低得多。然而，最大的區別是圖形效能。追求效能的人在使用 HTML5 時常常藉助於複雜的方案來規避 DOM ，能不碰就不碰。在WebGL上構建整個UI看起來是有前途的方式，但得看未來的執行情況。現在，WebGL已經有更廣泛的支援（Apple在iOS8加入了對WebGL的支援）。Qt 在這點上有很大優勢，相比web開發者的CSS3，Qt 還有更多的動畫選項。
原生使用者體驗
- 使用HTML5，你要麼依賴類似 Ionic 之類的第三方框架，要麼構建你自己的原生介面元素的替代品。
- 使用Qt你可以使用那些克隆了原生介面元素的元件，或者直接呼叫原生UI。
在 Qt 裡可以呼叫原生API可能在這點上給了它優勢，但實際上這損失了跨平臺相容性。實際上，當你需要真正的原生使用者體驗時，哪個選擇都不能很好地滿足需求。兩個方案都可以模仿某些應用的一個子集。一般來講，當你需要一個完全定製的UI或原生外觀和感覺不是真的必要時，可以採用跨平臺的方式。
結論
通過對這些指標的比較，Qt 比 HTML5 略有優勢。然而，你也可以使用其他指標來比較，得出相反的結論。在實踐中，需要選擇適合專案的技術。兩個選擇都有優點，如果你是一個 HTML5 開發人員，不熟悉 Qt 的產品，它們值得一看。還有一點我沒提及，Qt 可以使用webview來顯示 HTML5 內容，這意味著並不需要非此即彼，可以合二為一。
------------------------------
我開通了微信訂閱號——“程式視界”，漫談程式人生，有趣，有能量。微信掃描下面的二維碼即可關注。
也可以：開啟微信-->“新增朋友”-->“公眾號”-->搜尋“程式視界”-->關注。