在阿里上市，鋒菲復合，李娜退役等頭條的當口，騰訊 QQ 手機瀏覽器 X5 內核面向移動 App 開放，這條消息即使在移動互聯網行業內也似乎并不起眼。不過，在我看來，第三方瀏覽器開始開放內核，是移動 Web 的平臺化價值被行業充分認知的標志性事件，幾乎所有 App 應用領域都可能從中受益，Web App 將融入 Native App 體系，而移動 Web 和手機瀏覽器內核技術本身也將迎來新的發展機遇。
在此背景下，我們需要好好想一想的是：傳統 Web App 面臨的問題，開放手機瀏覽器內核技術對 App 體系的意義，開放手機瀏覽器內核技術對 App 體系的意義。
Web App 與 Native App 之爭
行業中一直存在一個觀點：在 PC 端大部分互聯網業務都只能通過瀏覽器基于 Web 訪問，所以移動端 Web App 也終將復制 PC 的成功——用戶將越來越多地通過手機瀏覽器，而不是 Native App 的方式訪問移動互聯網業務。因為，移動 Web App 同樣具備 PC Web App 的優勢：
對用戶而言：通過 Web 訪問業務，無需下載安裝，手機上也就無需安裝大量的 Native App
對 App 開發商而言：手機瀏覽器跨操作系統，App 開發商一次開發，部署于不同平臺，開發效率遠超 Native App
基于 Web 訪問業務，可以跨應用訪問和調用，這一點 Native App 很難做到
這些論點理論上都沒有錯，手機瀏覽器的安裝量遠超大部分垂直應用 App，也在一定程度上提供了佐證。
但現實是，在絕大多數領域，就特定垂直應用而言，大量用戶都更習慣通過垂直 Native App，而不是以 Web 方式訪問業務。這是為什么？
當下 Web 技術在手機端有天然局限，主要表現為：
執行效率：在手機端，無論就 JavaScript 的執行效率，還是渲染性能，Web 技術都無法與更直接調用 OS 功能的 Native App 技術匹配，這是天然的；
內容呈現能力：在手機端，傳統 Web 的 UI 控件與 Native App 的 UI 控件的的形態和表現能力有較大差距
功能覆蓋：一些 I/O 功能調用如：拍照、音效、視頻…基于 HTML5 的調用效果仍然不及 Native API
舉個簡單例子：所有的手機地圖 App 包括百度、高德、搜狗…都提供了 Web 版本，但其 Web 版本的功能和體驗對比 Native App 版本，只能說“呵呵”。
接下來的問題是，通過傳統意義上的 Web 平臺訪問業務，比通過 Native App 更便捷嗎？
雖然 Android/iOS 的 App 都數以百萬計，但事實上，用戶常用的業務類型只有 10 種左右（搜索，資訊，SNS，小說/閱讀，地圖，電商，O2O，視頻，音樂，安全，娛樂/時尚…），除游戲外，用戶只需要針對每種業務類型選擇安裝 1~2 種垂直領域的“超級 App”（例如：手機百度，搜狐新聞，微信/QQ空間，塔讀，高德，淘寶，大眾點評，優酷，酷我，360…），就可以滿足日常絕大部分移動互聯網需求。
行業內各種統計都顯示，絕大部分用戶日常使用的 App，只有 10~20 個左右，并不存在用戶為了日常需求而被迫頻繁安裝大量 App 的情況。
在訪問路徑上，用戶使用 Native App，只需要找到 App 圖標在桌面上的位置；而若要通過手機瀏覽器或者其他移動 Web 平臺，則需要首先找到瀏覽器圖標，再在手機瀏覽器內部的找到相應的圖標或鏈接。
Native App 會把大量的資源信息預先下載安裝到本地；而基于傳統移動 Web 的訪問模式，則非常可能需要在訪問內容時才同時下載所有資源信息，其訪問效率和內容展示效果與 Native App 相比都存在劣勢。
傳統 Web App 的應用模式是在操作系統與應用之間插入一個自有的操作體系和業務體系；這在 PC 上可行，在手機端則面臨挑戰。
首先是操作邏輯上的混淆，相對于 PC 上可以通過鼠標、鍵盤、菜單等豐富的操作方式，手機上的操作方式非常有限。用戶在手機瀏覽器等 Web 平臺中針對 Web App 的操作，一部分將會被平臺本身截獲，產生不符合用戶預期的執行結果。典型的被截獲操作是系統回退和左右滑屏——這使得 Web App 在傳統應用模式下無法實現應用內回退或側邊欄等設計。
傳統手機瀏覽器、移動搜索等 Web 平臺一直試圖在其自身操作范疇內建設一個大而全的 Web App Store 體系，甚至，部分手機瀏覽器和移動搜索 App 將其 Home 頁面設計為非常接近系統桌面的形態。這本身就可能混淆用戶的認知，既然用戶在系統桌面上就可以滿足絕大部分日常需求，為什么還要進入某個 App 去訪問一個跟系統桌面非常類似的 Web App 體系呢？
“輕應用”一度成為 Web App 切入系統桌面的探索，但各個巨頭推出的“輕應用”仍然試圖將 Web App 限定在其手機瀏覽器的操作范疇內。當用戶從系統桌面打開“輕應用”快捷圖標后，應用界面中往往會出現與該應用自身毫無關系的手機瀏覽器操作菜單。這樣的設計，反而會給用戶增加理解和操作的負擔。
那么 PC 瀏覽器的操作元素在智能手機上是否必要？所有的手機瀏覽器，基本操作元素都來自 PC 瀏覽器，包括：菜單欄、網址&搜索框、多窗口（Lable）等。不過，在寸土寸金的手機屏幕，這些元素都是必須的嗎？
事實上，當下主流的 App，包括與手機瀏覽器類似同樣支持 Web 訪問的 App 例如：微信、QQ 空間、資訊類 App（今日頭條、Zaker…）、移動搜索客戶端（百度，搜狗，360…），都不提供（或刻意回避）單個 App 內多窗口、多任務的設計，而采用更為簡單的單一內容訪問模式。手機瀏覽器基于其歷史原因，多窗口似乎不得不成為標配，但用戶真的需要嗎？
在功能機時代，系統桌面不是多任務的，手機瀏覽器的多任務會給用戶帶來極大的便利；但智能手機系統本身就是多任務、多窗口的，單一 App 內的多窗口，給手機應用帶來了多級多任務體系，是否仍然會讓用戶感到便利？
當下，PC 端游、PC 頁游、手游（“手機端游”）三大領域各領風騷，而手游的市場空間更是年年翻番。但是，基于 Web App 的“手機頁游”的發展卻遠不能與之匹配，為什么？
首要的還是帶寬的影響：高品質的手機游戲，需要大量的資源（動輒幾十甚至數百 M 圖片和音效）。如果完全基于傳統 Web App 即時下載的運行模式，根本無法啟動運行。如果手機頁游基于預下載等技術手段，則用戶訪問的體驗其實就等同于 Native App。
而針對一些輕小的休閑游戲，微信、QQ 空間、微博等平臺基于其社交屬性，很容易引起用戶的交流和分享，給“打飛機”“神經貓”“2048”等看似簡陋卻極易傳播的 HTML5 游戲帶來了巨大的訪問量，但這樣的游戲又很難找到持久粘性。
更深的原因則是行業對移動 HTML5 游戲技術的認知存在信息不對稱：HTML5 標準的一個重要組成部分是 canvas 元素，標準的設計者認為 canvas 就是 2D HTML5 游戲的技術基礎；但在實際的開發中，絕大部分 HTML5 手游開發商卻選擇 DOM 作為運行基礎。要知道，DOM 是為網頁的布局而不是根本不是為游戲定義的，這是為什么？
事實上，canvas 的 API 非常底層，如果基于 canvas 開發游戲，必須從最基礎的元素開始構建幀畫面，游戲程序必須自行構建和對象體系，其開發成本并不亞于基于 Native；同時，canvas 的 API 體系與智能手機的硬件渲染機制 OpenGL 并不匹配，很難有一種通用的模式能夠提升基于 canvas 的手游游戲運行效率。所以，基于 canvas 開發高品質游戲，對研發人員有很高的要求。當然，行業中有大量的基于 canvas 的框架引擎，但其學習成本本身就是一種負擔。
而基于 DOM 開發游戲，雖然執行性能遠遠無法與 Native 游戲匹配，但由于 DOM 體系本身就基于對象化機制，實現頁面元素的布局、操作事件的獲取都極其方便，其開發成本大大低于基于 canvas 或 Native App；對于實時性能要求不高的手游（典型如類游戲），DOM 是極好的技術選擇。
要知道：DOM 是 HTML 的基本組成部分，所有的前端開發人員都會；而擁有 canvas 商用開發經驗的前端人員則鳳毛菱角。
所以，HTML5 手游領域發生了一個并沒有被行業普遍意識到的問題：若干技術平臺開發商聚焦在提升 canvas 游戲的執行和渲染效率；而大量真正基于 HTML5 的手游開發商卻不使用 canvas。同時，大量的 HTML5 手游并不是基于傳統意義上的 Web App 形態運行，而是打包為 Native App 形態，甚至從不宣傳其基于 HTML5。
綜上，傳統意義上的 Web App 應用模式，面臨諸多挑戰。
但是，傳統 Web App 應用模式的問題并不意味著移動 Web 缺乏應用價值。恰恰相反，移動 Web 具備其他平臺技術很難有的獨特優勢。基于開放的應用模式，移動 Web 可以在更大的應用場景下，充分實現其平臺化價值。
在移動端，Web App 與 Native App 最終將不是孰優孰劣的問題，而是 Web App 自身將融入操作系統的大平臺中。
開放手機瀏覽器內核：Web App 融入 Native App 體系的契機
讓我們看兩頁 2014 年 iWeb 大會某 App 開發商的 PPT，它清楚地描述了 App 開發商面臨的典型問題和解決方案：
在移動端，社交平臺（微信、微博、QQ 空間、QQ）內傳播的內容形態，當前移動搜索可以訪問的內容形態，當然還有手機瀏覽器，都是基于 Web 的。所以，在幾乎所有的 App 應用領域（除手機游戲，系統類應用，以及有特殊技術需求的應用外），幾乎所有的 App 開發商都必須提供基于移動 Web 的內容呈現形態，否則，將失去社交平臺、手機瀏覽器、移動搜索等重要的流量入口——這就是移動 Web 技術的平臺化價值。
所以，對于移動 App 開發商而言，存在一個普遍的需求：只開發一套基于 Web 的應用，就可以同時部署在應用商店、社交平臺、手機瀏覽器，可以被移動搜索訪問，甚至還可以被其他應用直接調用。
但是，當前智能手機操作系統并不能很好地滿足這個需求，用下面的圖表就可以看出，當前應用 App 開發可用的內核平臺運行效果差：
而且，基于移動 Web 規范開發具有 Native 表現力的 App，有大量尚未被滿足的需求，包括：App 執行效率、Native UI 控件、一些移動 Web 規范尚未支持的 Native 功能調用。
解決問題并滿足這些需求，就是三方手機瀏覽器開放其內核的意義所在。
同時，Web App 與瀏覽器內核打包為 Native App，Web App 在手機瀏覽器中運行可能存在的問題將得到自然解決，例如：
功能缺陷可以通過 Native API 調用實現（Hybrid App 技術）
杜絕與業務本身無關的操作元素，不產生操作混淆
資源可以預先下載到本地，不需要運行時下載大量資源
QQ 手機瀏覽器首先開放 X5 內核，在我看來，只是行業的第一步。
當然，QQ 手機瀏覽器 X5 內核有一個非常獨特的優勢，它本身已經成為微信、QQ、QQ 空間的內核。對移動 App 開發商而言，只需要開發一次，就可以順利適配微信、QQ、QQ 空間并打包為 Native App。對騰訊而言，借助這個內核，甚至可以直接打通包括應用寶、微信、QQ、QQ 空間、QQ 手機瀏覽器的完整的應用開發服務和應用分發產業鏈。
面對移動 Web 技術的可能趨勢，怎么辦？
移動 Web 技術仍然面臨諸多需求，需要不斷解決。第一，需要提供針對移動 App 應用（而不僅僅是手機網頁）的功能支持：傳統上，Web 規范的使用對象是 Web 網頁；但在今日，移動 Web 技術的用戶已經遠遠不止是手機網頁，而是大量的 Native App。移動 Web 技術平臺，應當更多地考慮如何基于 Web 技術實現 Native App 的內容體現和運行效果。
第二，需要提升 JS 運行性能：JS 是非常靈活的高級語言，其開發靈活的代價就是運行效率明顯低于 Native 程序，因為 JS 在設計之初根本沒有料想到將來會在手機這樣的微型設備上運行。通過系統硬件和軟件的改進不斷提升 JS 運行性能，是需要芯片廠商、操作系統廠商、瀏覽器內核廠商持續解決的。
最后，需要提升基于移動 Web 的渲染性能：我認為，操作系統、手機瀏覽器內核應用盡早實現和開放 webGL。webGL 的開放價值遠不止于提供 3D 渲染，而是在于直接向 Web 應用開放硬件渲染能力。未來的渲染框架引擎，可以直接基于 JS+webGL 完成，而不需要依賴 Native 的渲染框架，這將幫助大量具備 HTML5 商用開發經驗的團隊靈活地實現和提供更有針對性的開發框架。甚至，DOM 體系的解析、布局和渲染，未來也可能基于 JS + webGL 直接實現。
綜上，產業鏈各個環節的現狀和我的建議如下：
w3c 標準組織：移動 Web 規范的制定，不能只考慮基于手機瀏覽器的運行規范，不能局限在保持跨瀏覽器規范一致；而應當把更多的精力投向移動 App 的實際商用需求。例如：移動 Web UI 控件的形態，應當與 Native App 的控件形態看齊，而不是與 PC 瀏覽器的 Web 形態保持規范上的一致。
芯片廠商和操作系統廠商：應當對移動 Web 的運行性能和運行效果提供持續的平臺支撐和優化，若干廠商早已在為之投入。例如：intel 支持基于 CPU SIMD指令來加速 JS 代碼的執行，xDK，crossWalk 框架；ARM 持續優化 WebKit 關鍵庫、cocos2d-js，推出 NEON；iOS 8 正式開放 webGL；Android中，Chrome Mobile 支持 webGL；Android4.4 開始，系統自帶 WebView 基于 Chromium（但還沒有支持 webGL）。
手機瀏覽器內核和其他類似技術的提供廠商：一旦開放內核給三方 App，三方瀏覽器內核即可能面臨巨大的需求壓力，因為移動 Web 技術和規范本身還存在大量需求和優化空間。對 QQ 手機瀏覽器而言，應當充分利用作為微信內核的優勢，爭取給 App 開發商提供真正一站式的應用開發服務支撐。對其他手機瀏覽器內核廠商而言，如果面向移動 App 開放內核，同樣可以獲得廣泛的需求空間；其他三方瀏覽器完全可以找到獨特的差異化優勢，也可以與 AppCan、PhoneGap 這些移動 Web 框架引擎巨頭合作獲得廣泛的用戶（應用開發商）資源。
一言以蔽之，移動 Web 的平臺價值將在更大更開放的應用場景中實現。
(新聞稿 2014-09-28)