未來不是Web與App的生死之爭，而是Web和App的融合

　　有一系列的文章討論HTML5開發的未來，其中包括樂觀派的《HTML 5終於定稿，八年後我們再一次談談怎麼改變世界》，還有悲觀派的《HTML 5定稿了？背後還是那場鬧劇》以及《反思HTML5慘痛的500天和四個謊言》。

　　這幾篇文章已經基本上把Web App（以下簡稱Web）和Native App（以下簡稱App）的優劣講清楚了。

　　Web的優勢是

• 對使用者而言：通過 Web 訪問業務，無需下載安裝，快速安裝使用，手機上也就無需安裝大量的 App，影響注意力；
• 對開發者而言：手機瀏覽器跨作業系統，App 開發商一次開發，就可以部署在 Android，iOS，WP 等不同平臺的手機瀏覽器上，開發效率遠超 App；
• 對網際網路公司而言：基於 Web 訪問業務，可以方便地跨應用訪問和呼叫資料，這一點 App 目前還很難做到。

　　Web 沒有真正提高開發效率

　　但是即使理論上 Web 有諸多優勢，但是無法改變目前 App 開發佔據主流的現狀，其原因不外乎以下：

• 執行效率：在手機端，無論就 JavaScript 的執行效率，還是渲染效能，Web 技術都無法與更直接呼叫 OS 功能的 Native App 技術匹配，這是天然的；
• 內容呈現能力：在手機端，傳統 Web 的 UI 控制元件與 Native App 的 UI 控制元件的的形態和表現能力有較大差距；
• 功能覆蓋：一些I/O功能呼叫如：拍照、音效、視訊...基於 HTML5 的呼叫效果仍然不及 Native API。

　　從使用者體驗的角度來講，使用者對於 Web 並沒有強烈的需求。而且傳統 Web 模式在產品模式上是有問題的，它在作業系統與應用之間插入一個自有的操作體系和業務體系。這在 PC 上可行，在手機端則會引發以下問題：

• 操作極其不流暢 相對於 PC 上可以通過滑鼠、鍵盤、選單等豐富的操作方式，手機上的操作方式非常有限。使用者在手機瀏覽器等 Web 平臺中針對 Web App 的操作，一部分將會被平臺本身截獲，產生不符合使用者預期的執行結果。典型的被截獲操作是系統回退和左右滑屏——這使得 Web App 在傳統應用模式下無法實現應用內回退或側邊欄等設計。

• 沒有減少操作 傳統手機瀏覽器試圖在其自身操作範疇內建設一個大而全的生態。使用者進入所謂的輕應用，和桌面一樣 需要尋找，指示操作的物件從 App Store 換成了搜尋引擎。Android 和 iOS 的 App 雖然數以百萬計，但使用者常用的業務型別只有 10 種左右，除遊戲外，使用者只需要針對每種業務型別選擇安裝 1~2 種垂直領域的“超級 App”就可以滿足日常絕大部分移動網際網路需求。

• UI 元素落後 所有的手機瀏覽器，基本操作元素都來自 PC 瀏覽器，包括：選單欄、網址框、搜尋框、視窗標籤等。不過，在寸土寸金的手機螢幕，這些元素都是必須的嗎？在功能機時代，系統桌面不是多工的，手機瀏覽 器的多工會給使用者帶來極大的便利；但智慧手機系統本身就是多工、多視窗的。使用者沒有感受到 Web 的便利。

　　除了一般意義上的 Web，還有一個要單獨拿出來講的是手機上的網頁遊戲。

　　高品質的手機遊戲，如果完全基於傳統 Web App 即時下載的執行模式，根本無法啟動執行。而針對一些輕小的休閒遊戲，微信、QQ 空間、微博等平臺基於其社交屬性，很容易引起使用者的交流和分享，給“打飛機”“神經貓”“2048”等看似簡陋卻極易傳播的 HTML5 遊戲帶來了巨大的訪問量，但這樣的遊戲又很難找到持久粘性。

　　HTML5 標準的設計者認為 Canvas 就是 2D HTML5 遊戲的技術基礎；但在實際的開發中，絕大部分 HTML5 手遊開發商卻選擇 DOM 作為執行基礎。根本不是為遊戲定義的。但是基於 canvas 開發高品質遊戲，對研發人員有很高的要求。DOM 是 HTML 的基本組成部分，所有的前端開發人員都會；而擁有 Canvas 商用開發經驗的前端人員則鳳毛菱角。Canvas 的 API 非常底層，如果基 Canvas 開發遊戲，必須從最基礎的元素開始構建幀畫面，其開發成本並不亞於基於 Native。

　　綜上所述，傳統意義上的 Web App 應用模式，面臨諸多挑戰。但是傳統 Web App 應用模式的問題並不意味著移動 Web 缺乏應用價值。恰恰相反，移動 Web 具備其他平臺技術很難有的獨特優勢。基於開放的應用模式，移動 Web 可以在更大的應用場景下，充分實現其平臺化價值。在移動端，Web App 與 Native App 最終將不是孰優孰劣的問題，而是 Web App 自身將融入作業系統的大平臺中。

　　Web 的歸 Web，App 的歸 App

　　在移動端，社交平臺內傳播的內容形態，當前移動搜尋可以訪問的內容形態，當然還有手機瀏覽器，都是基於 Web 的。所以，在幾乎所有的 App 應用領域，幾乎所有的 App 開發商都必須提供基於移動 Web 的內容呈現形態，否則，將失去社交平臺、手機瀏覽器、移動搜尋等重要的流量入口——這就是移動 Web 技術的平臺化價值。

　　所以，對於移動 App 開發商而言，存在一個普遍的需求：只開發一套基於 Web 的應用，就可以同時部署在應用商店、社交平臺、手機瀏覽器，可以被移動搜尋訪問，甚至還可以被其他應用直接呼叫。以下是某電商的新版移動端解決方案，融合和 Web 和 App。

　　同時，如果想將 Web 與瀏覽器核心打包為 App，Web App 在手機瀏覽器中執行可能存在的問題將得到自然解決，例如：

• 功能缺陷可以通過 Native API 呼叫實現（Hybrid App 技術）；
• 杜絕與業務本身無關的操作元素，不產生操作混淆；
• 資源可以預先下載到本地，不需要執行時下載大量資源。

　　這個思路簡單總結起來就是 Web 的歸 Web，App 的歸 App。但是這種思路也面臨著一個問題，因為當前智慧手機作業系統並不能很好地滿足這個需求，當前應用 App 開發可用的核心平臺執行效果很差。正如之前 36 氪討論 HTML5 的文章中說的那樣:

HTML5 標準本身涉及的技術並無任何障礙，截止 2013 年 90% 以上的 HTML5 的標準早已完成，但是遲遲無法定稿的原因則是各種利益集團的政治博弈。

　　不僅要優化，還要開放

　　再這樣的局面下，其實是需要有一方出現強力推廣自家的標準打破這種僵局。不管是蘋果的 Safari 和 Google 的 Chrome，還是國內的大多數手機瀏覽器，都在基於 WebKit 不斷優化瀏覽器引擎，也取得了很好的效果。但是這些引擎並不對第三方開放，開發者無法用他們來完成自己想要的 Hybird 開發。

　　在今年 9 月底，騰訊首先開放了 QQ 瀏覽器使用的 X5 核心，我認為這只是行業的第一步。順便八個卦，這個核心很快也被微信採用了，這讓我很意外。因為微信和 QQ 兩家向來是不喜歡用對方的東西。

　　未來騰訊應當充分利用作為微信核心的優勢，爭取給 App 開發商提供真正一站式的應用開發服務支撐。 對其他手機瀏覽器核心廠商而言，如果面向移動 App 開放核心，同樣可以獲得廣泛的需求空間；其他三方瀏覽器完全可以找到獨特的差異化優勢，也可以與 AppCan、PhoneGap 這些移動 Web 框架引擎巨頭合作獲得廣泛的使用者（應用開發商）資源。

　　一旦這樣的整合完成後，對移動 App 開發商而言，只需要開發一次，就可以順利適配微信、QQ、QQ 空間並打包為 Native App。對騰訊而言，藉助這個核心，甚至可以直接打通包括應用寶、微信、QQ、QQ 空間、QQ 手機瀏覽器的完整的應用開發服務和應用分發產業鏈。

　　現在很多通過微信出現在我們面前的 HTML5 頁面都是使用了騰訊的 X5 核心，比如各種 HTML5 招聘微門戶，HTML5 邀請函還有最近的微信連 WiFi 彈出的商家營銷頁面。還有新浪新聞、鳳凰客戶端、知乎等平臺也採用了騰訊 X5 的核心和雲平臺。

　　未來微信利用自己在使用者技術方面的優勢，“挾使用者以定標準”，必然能推動國內 HTML5 開發向前推進。微信的心態也應該更開放。比如微信目前已經開始開放 API，支援從第三方 App 直接跳轉微信公眾號，但是必須經過微信的嚴格稽核。如果未來採用騰訊 X5 核心的 Web 頁面也可以直接跳轉微信的各種服務，那想必也是極好的。

　　對其他手機瀏覽器核心廠商而言，如果面向移動 App 開放核心，同樣可以獲得廣泛的需求空間；其他三方瀏覽器完全可以找到獨特的差異化優勢，也可以與 AppCan、PhoneGap 這些移動 Web 框架引擎巨頭合作獲得廣泛的使用者（應用開發商）資源。

　　除了手機瀏覽器之外，硬體和平臺級廠商也應當對移動 Web 的執行效能和執行效果提供持續的平臺支撐和優化，若干廠商早已在為之投入，例如 Intel 支援基於 CPU SIMD 指令來加速 JS 程式碼的執行，xDK，crossWalk 框架；ARM 一直在持續優化 WebKit 關鍵庫、cocos2d-js，推出 NEON；iOS8 正式開放 webGL；Chrome Mobile 支援 WebGL，並且從 Android4.4 開始，系統自帶 WebView 基於 Chromium（但還沒有支援 webGL）。

　　不過這只是一個開始，未來開放的 Web 和 App 的融合還要解決很多問題：

• 提供針對移動 App 應用（而不僅僅是手機網頁）的功能支援：傳統上，Web 規範的使用物件是 Web 網頁；但在今日，移動 Web 技術的使用者已經遠遠不止是手機網頁，而是大量的 Native App。移動 Web UI 控制元件的形態，應當與 Native App 的控制元件形態看齊，而不是與 PC 瀏覽器的 Web 形態保持規範上的一致。移動 Web 技術平臺，應當更多地考慮如何基於 Web 技術實現 Native App 的內容體現和執行效果。

• 提升 JS 執行效能：JS 非常靈活的高階語言，其開發靈活的代價就是執行效率明顯低於 Native 程式，因為 JS 在設計之初根本沒有料想到將來會在手機這樣的微型裝置上執行。通過系統硬體和軟體的改進不斷提升 JS 執行效能，是需要晶片廠商、作業系統廠商、瀏覽器核心廠商持續解決的。

• 提升基於移動 Web 的渲染效能：筆者認為，作業系統、手機瀏覽器核心應用盡早實現和開放 webGL。webGL 的開放價值遠不止於提供 3D 渲染，而是在於直接向 Web 應用開放硬體渲染能力。未來的渲染框架引擎，可以直接基於 JS+webGL 完成，而不需要依賴 Native 的渲染框架，這將幫助大量具備 HTML5 商用開發經驗的團隊靈活地實現和提供更有針對性的開發框架。甚至，DOM 體系的解析、佈局和渲染，未來也可能基於 JS + webGL 直接實現。

　　本文作者 Hans，移動網際網路開發者

　　via: 36kr