在阿里上市，鋒菲復合，李娜退役等頭條的當口，騰訊 QQ 手機瀏覽器 X5 內(nèi)核面向移動 App 開放，這條消息即使在移動互聯(lián)網(wǎng)行業(yè)內(nèi)也似乎并不起眼。不過，在我看來，第三方瀏覽器開始開放內(nèi)核，是移動 Web 的平臺化價值被行業(yè)充分認知的標志性事件，幾乎所有 App 應用領域都可能從中受益，Web App 將融入 Native App 體系，而移動 Web 和手機瀏覽器內(nèi)核技術本身也將迎來新的發(fā)展機遇。

在此背景下，我們需要好好想一想的是：傳統(tǒng) Web App 面臨的問題，開放手機瀏覽器內(nèi)核技術對 App 體系的意義，開放手機瀏覽器內(nèi)核技術對 App 體系的意義。

Web App 與 Native App 之爭

行業(yè)中一直存在一個觀點：在 PC 端大部分互聯(lián)網(wǎng)業(yè)務都只能通過瀏覽器基于 Web 訪問，所以移動端 Web App 也終將復制 PC 的成功——用戶將越來越多地通過手機瀏覽器，而不是 Native App 的方式訪問移動互聯(lián)網(wǎng)業(yè)務。因為，移動 Web App 同樣具備 PC Web App 的優(yōu)勢：

• 對用戶而言：通過 Web 訪問業(yè)務，無需下載安裝，手機上也就無需安裝大量的 Native App
• 對 App 開發(fā)商而言：手機瀏覽器跨操作系統(tǒng)，App 開發(fā)商一次開發(fā)，部署于不同平臺，開發(fā)效率遠超 Native App
• 基于 Web 訪問業(yè)務，可以跨應用訪問和調(diào)用，這一點 Native App 很難做到

這些論點理論上都沒有錯，手機瀏覽器的安裝量遠超大部分垂直應用 App，也在一定程度上提供了佐證。

但現(xiàn)實是，在絕大多數(shù)領域，就特定垂直應用而言，大量用戶都更習慣通過垂直 Native App，而不是以 Web 方式訪問業(yè)務。這是為什么？

當下 Web 技術在手機端有天然局限，主要表現(xiàn)為：

• 執(zhí)行效率：在手機端，無論就 JavaScript 的執(zhí)行效率，還是渲染性能，Web 技術都無法與更直接調(diào)用 OS 功能的 Native App 技術匹配，這是天然的；
• 內(nèi)容呈現(xiàn)能力：在手機端，傳統(tǒng) Web 的 UI 控件與 Native App 的 UI 控件的的形態(tài)和表現(xiàn)能力有較大差距
• 功能覆蓋：一些 I/O 功能調(diào)用如：拍照、音效、視頻…基于 HTML5 的調(diào)用效果仍然不及 Native API

舉個簡單例子：所有的手機地圖 App 包括百度、高德、搜狗…都提供了 Web 版本，但其 Web 版本的功能和體驗對比 Native App 版本，只能說“呵呵”。

接下來的問題是，通過傳統(tǒng)意義上的 Web 平臺訪問業(yè)務，比通過 Native App 更便捷嗎？

雖然 Android/iOS 的 App 都數(shù)以百萬計，但事實上，用戶常用的業(yè)務類型只有 10 種左右（搜索，資訊，SNS，小說/閱讀，地圖，電商，O2O，視頻，音樂，安全，娛樂/時尚…），除游戲外，用戶只需要針對每種業(yè)務類型選擇安裝 1~2 種垂直領域的“超級 App”（例如：手機百度，搜狐新聞，微信/QQ空間，塔讀，高德，淘寶，大眾點評，優(yōu)酷，酷我，360…），就可以滿足日常絕大部分移動互聯(lián)網(wǎng)需求。

行業(yè)內(nèi)各種統(tǒng)計都顯示，絕大部分用戶日常使用的 App，只有 10~20 個左右，并不存在用戶為了日常需求而被迫頻繁安裝大量 App 的情況。

在訪問路徑上，用戶使用 Native App，只需要找到 App 圖標在桌面上的位置；而若要通過手機瀏覽器或者其他移動 Web 平臺，則需要首先找到瀏覽器圖標，再在手機瀏覽器內(nèi)部的找到相應的圖標或鏈接。

Native App 會把大量的資源信息預先下載安裝到本地；而基于傳統(tǒng)移動 Web 的訪問模式，則非常可能需要在訪問內(nèi)容時才同時下載所有資源信息，其訪問效率和內(nèi)容展示效果與 Native App 相比都存在劣勢。

傳統(tǒng) Web App 的應用模式是在操作系統(tǒng)與應用之間插入一個自有的操作體系和業(yè)務體系；這在 PC 上可行，在手機端則面臨挑戰(zhàn)。

首先是操作邏輯上的混淆，相對于 PC 上可以通過鼠標、鍵盤、菜單等豐富的操作方式，手機上的操作方式非常有限。用戶在手機瀏覽器等 Web 平臺中針對 Web App 的操作，一部分將會被平臺本身截獲，產(chǎn)生不符合用戶預期的執(zhí)行結(jié)果。典型的被截獲操作是系統(tǒng)回退和左右滑屏——這使得 Web App 在傳統(tǒng)應用模式下無法實現(xiàn)應用內(nèi)回退或側(cè)邊欄等設計。

傳統(tǒng)手機瀏覽器、移動搜索等 Web 平臺一直試圖在其自身操作范疇內(nèi)建設一個大而全的 Web App Store 體系，甚至，部分手機瀏覽器和移動搜索 App 將其 Home 頁面設計為非常接近系統(tǒng)桌面的形態(tài)。這本身就可能混淆用戶的認知，既然用戶在系統(tǒng)桌面上就可以滿足絕大部分日常需求，為什么還要進入某個 App 去訪問一個跟系統(tǒng)桌面非常類似的 Web App 體系呢？

“輕應用”一度成為 Web App 切入系統(tǒng)桌面的探索，但各個巨頭推出的“輕應用”仍然試圖將 Web App 限定在其手機瀏覽器的操作范疇內(nèi)。當用戶從系統(tǒng)桌面打開“輕應用”快捷圖標后，應用界面中往往會出現(xiàn)與該應用自身毫無關系的手機瀏覽器操作菜單。這樣的設計，反而會給用戶增加理解和操作的負擔。

那么 PC 瀏覽器的操作元素在智能手機上是否必要？所有的手機瀏覽器，基本操作元素都來自 PC 瀏覽器，包括：菜單欄、網(wǎng)址&搜索框、多窗口（Lable）等。不過，在寸土寸金的手機屏幕，這些元素都是必須的嗎？

事實上，當下主流的 App，包括與手機瀏覽器類似同樣支持 Web 訪問的 App 例如：微信、QQ 空間、資訊類 App（今日頭條、Zaker…）、移動搜索客戶端（百度，搜狗，360…），都不提供（或刻意回避）單個 App 內(nèi)多窗口、多任務的設計，而采用更為簡單的單一內(nèi)容訪問模式。手機瀏覽器基于其歷史原因，多窗口似乎不得不成為標配，但用戶真的需要嗎？

在功能機時代，系統(tǒng)桌面不是多任務的，手機瀏覽器的多任務會給用戶帶來極大的便利；但智能手機系統(tǒng)本身就是多任務、多窗口的，單一 App 內(nèi)的多窗口，給手機應用帶來了多級多任務體系，是否仍然會讓用戶感到便利？

當下，PC 端游、PC 頁游、手游（“手機端游”）三大領域各領風騷，而手游的市場空間更是年年翻番。但是，基于 Web App 的“手機頁游”的發(fā)展卻遠不能與之匹配，為什么？

首要的還是帶寬的影響：高品質(zhì)的手機游戲，需要大量的資源（動輒幾十甚至數(shù)百 M 圖片和音效）。如果完全基于傳統(tǒng) Web App 即時下載的運行模式，根本無法啟動運行。如果手機頁游基于預下載等技術手段，則用戶訪問的體驗其實就等同于 Native App。

而針對一些輕小的休閑游戲，微信、QQ 空間、微博等平臺基于其社交屬性，很容易引起用戶的交流和分享，給“打飛機”“神經(jīng)貓”“2048”等看似簡陋卻極易傳播的 HTML5 游戲帶來了巨大的訪問量，但這樣的游戲又很難找到持久粘性。

更深的原因則是行業(yè)對移動 HTML5 游戲技術的認知存在信息不對稱：HTML5 標準的一個重要組成部分是 canvas 元素，標準的設計者認為 canvas 就是 2D HTML5 游戲的技術基礎；但在實際的開發(fā)中，絕大部分 HTML5 手游開發(fā)商卻選擇 DOM 作為運行基礎。要知道，DOM 是為網(wǎng)頁的布局而不是根本不是為游戲定義的，這是為什么？

事實上，canvas 的 API 非常底層，如果基于 canvas 開發(fā)游戲，必須從最基礎的元素開始構建幀畫面，游戲程序必須自行構建和對象體系，其開發(fā)成本并不亞于基于 Native；同時，canvas 的 API 體系與智能手機的硬件渲染機制 OpenGL 并不匹配，很難有一種通用的模式能夠提升基于 canvas 的手游游戲運行效率。所以，基于 canvas 開發(fā)高品質(zhì)游戲，對研發(fā)人員有很高的要求。當然，行業(yè)中有大量的基于 canvas 的框架引擎，但其學習成本本身就是一種負擔。

而基于 DOM 開發(fā)游戲，雖然執(zhí)行性能遠遠無法與 Native 游戲匹配，但由于 DOM 體系本身就基于對象化機制，實現(xiàn)頁面元素的布局、操作事件的獲取都極其方便，其開發(fā)成本大大低于基于 canvas 或 Native App；對于實時性能要求不高的手游（典型如棋牌類游戲），DOM 是極好的技術選擇。

要知道：DOM 是 HTML 的基本組成部分，所有的前端開發(fā)人員都會；而擁有 canvas 商用開發(fā)經(jīng)驗的前端人員則鳳毛菱角。

所以，HTML5 手游領域發(fā)生了一個并沒有被行業(yè)普遍意識到的問題：若干技術平臺開發(fā)商聚焦在提升 canvas 游戲的執(zhí)行和渲染效率；而大量真正基于 HTML5 的手游開發(fā)商卻不使用 canvas。同時，大量的 HTML5 手游并不是基于傳統(tǒng)意義上的 Web App 形態(tài)運行，而是打包為 Native App 形態(tài)，甚至從不宣傳其基于 HTML5。

綜上，傳統(tǒng)意義上的 Web App 應用模式，面臨諸多挑戰(zhàn)。

但是，傳統(tǒng) Web App 應用模式的問題并不意味著移動 Web 缺乏應用價值。恰恰相反，移動 Web 具備其他平臺技術很難有的獨特優(yōu)勢?；陂_放的應用模式，移動 Web 可以在更大的應用場景下，充分實現(xiàn)其平臺化價值。

在移動端，Web App 與 Native App 最終將不是孰優(yōu)孰劣的問題，而是 Web App 自身將融入操作系統(tǒng)的大平臺中。

開放手機瀏覽器內(nèi)核：Web App 融入 Native App 體系的契機

讓我們看兩頁 2014 年 iWeb 大會某 App 開發(fā)商的 PPT，它清楚地描述了 App 開發(fā)商面臨的典型問題和解決方案：

在移動端，社交平臺（微信、微博、QQ 空間、QQ）內(nèi)傳播的內(nèi)容形態(tài)，當前移動搜索可以訪問的內(nèi)容形態(tài)，當然還有手機瀏覽器，都是基于 Web 的。所以，在幾乎所有的 App 應用領域（除手機游戲，系統(tǒng)類應用，以及有特殊技術需求的應用外），幾乎所有的 App 開發(fā)商都必須提供基于移動 Web 的內(nèi)容呈現(xiàn)形態(tài)，否則，將失去社交平臺、手機瀏覽器、移動搜索等重要的流量入口——這就是移動 Web 技術的平臺化價值。

所以，對于移動 App 開發(fā)商而言，存在一個普遍的需求：只開發(fā)一套基于 Web 的應用，就可以同時部署在應用商店、社交平臺、手機瀏覽器，可以被移動搜索訪問，甚至還可以被其他應用直接調(diào)用。

但是，當前智能手機操作系統(tǒng)并不能很好地滿足這個需求，用下面的圖表就可以看出，當前應用 App 開發(fā)可用的內(nèi)核平臺運行效果差：

而且，基于移動 Web 規(guī)范開發(fā)具有 Native 表現(xiàn)力的 App，有大量尚未被滿足的需求，包括：App 執(zhí)行效率、Native UI 控件、一些移動 Web 規(guī)范尚未支持的 Native 功能調(diào)用。

解決問題并滿足這些需求，就是三方手機瀏覽器開放其內(nèi)核的意義所在。

同時，Web App 與瀏覽器內(nèi)核打包為 Native App，Web App 在手機瀏覽器中運行可能存在的問題將得到自然解決，例如：

• 功能缺陷可以通過 Native API 調(diào)用實現(xiàn)（Hybrid App 技術）
• 杜絕與業(yè)務本身無關的操作元素，不產(chǎn)生操作混淆
• 資源可以預先下載到本地，不需要運行時下載大量資源

QQ 手機瀏覽器首先開放 X5 內(nèi)核，在我看來，只是行業(yè)的第一步。

當然，QQ 手機瀏覽器 X5 內(nèi)核有一個非常獨特的優(yōu)勢，它本身已經(jīng)成為微信、QQ、QQ 空間的內(nèi)核。對移動 App 開發(fā)商而言，只需要開發(fā)一次，就可以順利適配微信、QQ、QQ 空間并打包為 Native App。對騰訊而言，借助這個內(nèi)核，甚至可以直接打通包括應用寶、微信、QQ、QQ 空間、QQ 手機瀏覽器的完整的應用開發(fā)服務和應用分發(fā)產(chǎn)業(yè)鏈。

面對移動 Web 技術的可能趨勢，怎么辦？

移動 Web 技術仍然面臨諸多需求，需要不斷解決。第一，需要提供針對移動 App 應用（而不僅僅是手機網(wǎng)頁）的功能支持：傳統(tǒng)上，Web 規(guī)范的使用對象是 Web 網(wǎng)頁；但在今日，移動 Web 技術的用戶已經(jīng)遠遠不止是手機網(wǎng)頁，而是大量的 Native App。移動 Web 技術平臺，應當更多地考慮如何基于 Web 技術實現(xiàn) Native App 的內(nèi)容體現(xiàn)和運行效果。

第二，需要提升 JS 運行性能：JS 是非常靈活的高級語言，其開發(fā)靈活的代價就是運行效率明顯低于 Native 程序，因為 JS 在設計之初根本沒有料想到將來會在手機這樣的微型設備上運行。通過系統(tǒng)硬件和軟件的改進不斷提升 JS 運行性能，是需要芯片廠商、操作系統(tǒng)廠商、瀏覽器內(nèi)核廠商持續(xù)解決的。

最后，需要提升基于移動 Web 的渲染性能：我認為，操作系統(tǒng)、手機瀏覽器內(nèi)核應用盡早實現(xiàn)和開放 webGL。webGL 的開放價值遠不止于提供 3D 渲染，而是在于直接向 Web 應用開放硬件渲染能力。未來的渲染框架引擎，可以直接基于 JS+webGL 完成，而不需要依賴 Native 的渲染框架，這將幫助大量具備 HTML5 商用開發(fā)經(jīng)驗的團隊靈活地實現(xiàn)和提供更有針對性的開發(fā)框架。甚至，DOM 體系的解析、布局和渲染，未來也可能基于 JS + webGL 直接實現(xiàn)。

綜上，產(chǎn)業(yè)鏈各個環(huán)節(jié)的現(xiàn)狀和我的建議如下：

w3c 標準組織：移動 Web 規(guī)范的制定，不能只考慮基于手機瀏覽器的運行規(guī)范，不能局限在保持跨瀏覽器規(guī)范一致；而應當把更多的精力投向移動 App 的實際商用需求。例如：移動 Web UI 控件的形態(tài)，應當與 Native App 的控件形態(tài)看齊，而不是與 PC 瀏覽器的 Web 形態(tài)保持規(guī)范上的一致。

芯片廠商和操作系統(tǒng)廠商：應當對移動 Web 的運行性能和運行效果提供持續(xù)的平臺支撐和優(yōu)化，若干廠商早已在為之投入。例如：intel 支持基于 CPU SIMD指令來加速 JS 代碼的執(zhí)行，xDK，crossWalk 框架；ARM 持續(xù)優(yōu)化 WebKit 關鍵庫、cocos2d-js，推出 NEON；iOS 8 正式開放 webGL；Android中，Chrome Mobile 支持 webGL；Android4.4 開始，系統(tǒng)自帶 WebView 基于 Chromium（但還沒有支持 webGL）。

手機瀏覽器內(nèi)核和其他類似技術的提供廠商：一旦開放內(nèi)核給三方 App，三方瀏覽器內(nèi)核即可能面臨巨大的需求壓力，因為移動 Web 技術和規(guī)范本身還存在大量需求和優(yōu)化空間。對 QQ 手機瀏覽器而言，應當充分利用作為微信內(nèi)核的優(yōu)勢，爭取給 App 開發(fā)商提供真正一站式的應用開發(fā)服務支撐。對其他手機瀏覽器內(nèi)核廠商而言，如果面向移動 App 開放內(nèi)核，同樣可以獲得廣泛的需求空間；其他三方瀏覽器完全可以找到獨特的差異化優(yōu)勢，也可以與 AppCan、PhoneGap 這些移動 Web 框架引擎巨頭合作獲得廣泛的用戶（應用開發(fā)商）資源。

一言以蔽之，移動 Web 的平臺價值將在更大更開放的應用場景中實現(xiàn)。