對Web與手機瀏覽器的再思考（一）

在PC時代，Web的主要承載體是占據流量入口地位的PC瀏覽器；然而在智能手機時代，Web依托不同載體呈現出多元形態，手機瀏覽器更要面對微信、垂直 App、移動搜索、應用商店等應用的分流與挑戰。2013年之前，行業對于手機瀏覽器的思考，始終伴隨著一個熱門話題：Web App與Native App，誰代表未來？

2010 年，"Wired" 雜志的一篇 "The web is dead, long live the internet" 被國內行業媒體廣泛轉載；2012 年，搜狗小川總也對媒體表示，“link（鏈接）已死，就是說手機它未來不是靠鏈接構建的網絡環境，瀏覽器是以鏈接為核心驅動的...”。

時至今日，社會化傳播已經成為支撐整個移動互聯網生態運轉的核心力量之一。移動互聯網的任何產業領域，早已無法離開粉絲經濟。當移動互聯網用戶越來越習慣通過微信、朋友圈、微博分享視頻、音樂、購物、資訊乃至天氣、位置...，當越來越多的的 Native App 希望得到社會化媒體的廣泛傳播（并得到回流），他們都需要一個普適的，標準的傳播格式。

我們可以清晰的發現，承載社會化傳播的最廣泛也是最恰當的基礎，恰恰是那個曾經被視為“已死”的 Web 與 Link。優酷客戶端是 Native 的，淘寶客戶端是 Native 的，酷我音樂是 Native 的，百度地圖是 Native 的，Zaker 是 Native 的，搜狐新聞是 Native 的... 但這些 Native App 所提供的分享，傳播，卻是標準的 Link，Page 和實實在在的 Web App。

答案似乎很明顯：在移動互聯網時代，Web與Link都沒有死，相反，卻在社會化傳播的浪潮里爆發出更為強勁的生命力。

此外，在移動互聯網時代，雖然 PC 互聯網基于百度、搜狗等搜索框的訪問形態開始被諸多垂直搜索分流，但傳統的搜索模式依舊是移動互聯網用戶最常用的服務；而能夠承載這種跨領域通用搜索模式的技術基礎，依舊只能是基于 Web 的爬蟲，檢索...... 所以，對任何希望能夠通過通用搜索入口觸及用戶的應用而言，Web 仍須成為其基礎性的內容形態之一。

關于Web App

在 PC 互聯網時代，Web 的承載基本就是瀏覽器。而在移動互聯網，特別是智能手機普及的時代，Web 完全可以繞開傳統意義上的手機瀏覽器，典型的例子是：社會化傳播的承載體（如微信、微博客戶端），在傳播 Web 與 link 的同時，并不要求用戶必須通過手機瀏覽器訪問 Web；相反，集成了瀏覽器內核部件的微信，微博可以讓用戶直接在客戶端訪問鏈接，直接運行 Web App，甚至直接玩 HTML5 游戲。

手機瀏覽器似乎很難完整復制 PC 瀏覽器的卡位優勢，相反，Web在社會化傳播時代的價值卻使得手機瀏覽器不得不面對更多的分流，因為Web在移動互聯網時代呈現出了更多元的形態，或者說，Web已經融入更多的Native App：

1. 基于傳統手機瀏覽器的Web App

從一般定義上講，在手機瀏覽器中通過導航、鏈接打開某種基于 Web 的近似于 Native App 體驗的服務，是 Web App 最正宗的應用場景。這種產品模式的好處一直被行業稱道和期待：跨平臺，無需下載，一點即用。

相對于垂直 Native App，手機瀏覽器具備“覆蓋廣泛，快速到達”的核心優勢，幾乎可以直接到達移動互聯網的絕大多數服務，用戶并不需要事先下載，甚至不需要了解具體應用的存在，打開手機瀏覽器就可以快速到達。所以，對于解決用戶的長尾需求而言，手機瀏覽器始終是必備，難以被替代。

但是，時至今日，（基于傳統手機瀏覽器的）Web App 應用現狀，似乎還未普遍達到行業期待；特別是在部分高頻應用垂直領域，應用的 Web App 形態訪問量還不能與其 Native App 形態比肩。為什么？

1) 問題：

僅從產品層面來說，在手機瀏覽器中運行交互體驗很強的 Web App，至少存在如下先天缺憾（必須要說明，如下問題大都不應算作手機瀏覽器的產品問題，而是 Web App 技術規范在手機端實現的先天缺陷）：

a. 操作可能混淆，交互體驗受影響

Web App 運行在手機瀏覽器上，等于在底層操作系統與 App 之間隔了一層手機瀏覽器；同時，手機瀏覽器必須提供通用的方式操作大部分應用，很難對所有類型的應用都提供定制化的操作體驗。所以，用戶對 App 的若干交互操作可能被視為對手機瀏覽器的通用操作，造成用戶操作預期與實際響應的不對稱。看看如下場景：

Native App 中應用內的前進回退操作，可能被視為手機瀏覽器 Label 頁面的回退操作；

手機屏幕很小，對一些涉及垂直搜索的 Web App，用戶容易混淆 App 的搜索框與手機瀏覽器的搜索框；

Web App 提供的“對話框”，用戶無法通過回退按鈕退出；

某些應用并不希望提供左右滑屏或上下滾屏（而希望固定頁面），但在手機瀏覽器中，用戶的滑屏操作可能誤引起應用頁面的不當移動，甚至退出應用；

b. 每次都需要下載，消耗流量，且影響界面品質

Web App 無需像 Native App 那樣必須先行下載安裝，這樣的“優勢”實際上意味著：

每次運行 Web App 都需要進行基礎業務數據的下載；

在應用內每個新頁面都需要進行數據下載；

......

簡言之，Web App 的流量消耗可能更大。當然，手機瀏覽器可以通過緩存或 HTML5 本地存儲等方式減少每次啟動運行 Web App 的流量，但這是不可控的。

基于這樣的風險，大部分 Web App，都必須限制啟動流量，帶來的后果就是界面與交互品質難以與 Native App 媲美。

c. HTML5/Web App內核問題

a) 運行效率和渲染能力低：

傳統手機瀏覽器內核對 HTML5 canvas 的渲染基于 CPU 處理，渲染效率無法比肩 Native App；2011 以來，全球范圍內有若干廠商嘗試過基于 GPU 渲染處理 HTML5 canvas，但這類技術仍普遍面臨適配性問題，以及針對非 canvas 頁面的處理問題。

同時，HTML 基于 Java Script，而 Java Script 是實時解釋型語言，語法非常靈活，其設計初衷之一就是犧牲效率換靈活，且其設計之初并未考慮過在移動設備運行，其執行效率天然與 Native App 存在明顯差距，對部分 App 而言，這個差距遠非單純 GPU 渲染可以跨越。

b) 一些HTML5系統接口的處理效果仍欠佳，例如：

調用系統相機，錄音... 當前 HTML5 接口執行效果仍欠佳，支持的參數也有限，很難想象基于 Web 運行類似 camera360，美圖秀秀，嘀嘀打車這樣的 App。

基于 Web 截獲 pinch 或多點觸控消息，其執行效果明顯遜色于 Native 調用，類似百度地圖的 Web App，其交互體驗并不理想。

此外，HTML5 提供的特性仍不能完整覆蓋 Native API，包括：系統推送，調用本地 App 等。

c) HTML5規范尚不統一，影響跨平臺的優勢

理論上，HTML5 是一種跨平臺，跨瀏覽器的技術平臺，可以做到：一次開發，多平臺發布。

但在事實上，由于不同瀏覽器的處理差異，大部分 Web App 都必須對多種不同手機瀏覽器做出若干細節適配；而針對不同的手機，不同屏幕尺寸，不同 CPU 乃至 GPU，可商用的 Web App 都需要進行針對性適配。（與之形成對比的是，基于 Native App 進行開發，跨平臺逐漸成為開發框架的標配，越來越多的 Native 技術引擎天然就支持跨平臺）

2) 解決：

那么，Web App 能否克服上述問題，真正體現其價值？HTML5 能否真正達成 Native App 的應用效果？事實上，行業的既有商用已經給出了清晰答案：能！

a. 當下主流手機瀏覽器往往會針對視頻，閱讀，游戲，圖片 4 種應用提供獨特的訪問模式，特定訪問模式不會受到手機瀏覽器通用操作的影響，在很大程度上解決了操作體驗問題；

b. HTML5 在 Native 功能方面的缺陷，可以通過直接調用 Native API 的橋接方式克服， AppCan，PhoneGap 都提供了相應的解決方案；而在手機瀏覽器中，也逐漸加入了基于 Native 的功能調用，典型如二維碼掃描，調用 Native 形態的特性（如 UC 提供的“找身邊”）；

c. 重構內核，繞開 HTML5 和 Java Script 的性能劣勢。到目前為止，基于傳統內核，試圖在保證 HTML 標準性基礎上達成 Native App 效果的嘗試，都沒有成功的典范。相反，某些內核架構，舍棄一些“標準”，對部分特性進行優化，卻可以達到很好的商用效果。最為典型的商用產品是 cocos2d-html5 + JSB，此種方案對 HTML5 和 Java Script 的使用有諸多限制，本質上提供的是已經是半私有的接口了，但其性能效果和適配性非常出色；另外 UC 開發的 xCanvas，國外的 Ludei 等也在某種程度上采用了類似機制 ;

d. 開發商對應用進行較為深入的優化適配（有資源的話，甚至可以直接閱讀瀏覽器開放內核代碼并找到可優化點），可以考慮舍棄一些不必要的功能例如 DOM+Canvas 混搭，特定的 Web App 完全可以達到 Native App 運行效果。——對開發者而言，“標準性”首先要服從“實用性”。

2. Hybrid形態的Web App

基于 HTML + Java Script 開發，通過 AppCan 或 PhoneGap 等產品打包，生成 Native App 形態的應用；這是 Web App 另一種廣泛存在的形態。它的優勢在于：

1) 充分利用 HTML 的跨平臺優勢，一次開發，可以生成 Android, iOS, WinPhone 的 Native App；

2) Hybrid App 內的內容，都可以直接通過 URL 分享到社會化媒體；相較于純 Native App，非常便于社會化傳播；

3) 相對于傳統 Native App，基于 HTML 和 Java Script 的開發部署更為靈活，資源可以部署在服務器端，也可以打包在客戶端，同時應用升級也更為簡便；而且，HTML 內容可以預先打包在 Hybrid App 中，無需每次運行都下載；

4) 基于 AppCan, PhoneGap 提供的統一內核（例如 WebView），不用考慮針對多種三方手機瀏覽器進行適配；

5) AppCan, PhoneGap 提供了豐富的插件和增強 API，幫助應用達成 Native 的商用效果；

而這種模式最為顯著的弱點在于：它采用的內核運行性能較差，一般難以支撐性能要求較高的應用，特別是手機游戲。

3. 輕應用形態的Web App

輕應用是 2013 年 360，百度，UC 一度熱炒的概念，至今并無確切的定義，三家巨頭所提的邏輯也并不完全相同。不過大體上，輕應用是基于 Web App 的一種創新應用封裝方式。

1) 360的輕應用，關鍵詞：應用分發

將 Web App 封裝為基于操作系統桌面的快捷方式，更重要的是可以通過 360 的手機分發渠道進行分發，這是 360 對傳統智能手機應用分發形態的一種創新嘗試。

對用戶，特別是小白用戶而言，這種應用獲取方式與在應用商店下載安裝達成的效果基本相當，但省卻了下載的流量和安裝的過程。同時，這種應用形態，也可以規避在手機瀏覽器中運行 Web App 需要兼顧多種交互操作的問題。

2) 百度的輕應用，關鍵詞：移動搜索

百度強調傳統 Native App 應用分發模式存在大量長尾的信息孤島，難以被用戶在應用商店檢索到（比如用戶根本就不知道這些應用的名字），即使被下載安裝其使用頻度亦極低。

而基于應用商店之外的移動搜索則可以在用戶需求與應用之間建立起即時關聯。這種搜索必然不是傳統應用商店基于名稱、類別的檢索，而是面向用戶自然語言的搜索，同時也必然涉及應用內信息檢索。百度的搜索能力 + 基于 Web App 形態的應用，本身就已經實現了這種關聯。

另外，百度針對其輕應用，亦提供多種增強 API，幫助 Web App 提供類似 Native App 的功能特性。

同時，基于 91，安卓市場，百度手機助手帶來的市場份額，百度已經成為第一大應用分發商，輕應用形態也有可能得到其眾多移動客戶端、分發渠道的支持。

3) UC的輕應用，關鍵詞：超級App

移動 App 的使用越來越集中，用戶更習慣訪問頻繁極少數超級 App，而大量的長尾應用極難被用戶訪問。作為毋庸置疑的超級 App，UC 同樣可以通過其成熟的導航、檢索、搜索機制建立起用戶需求與長尾應用之間的即時關聯。這就是 UC 的 Super App + Light App 生態。

同樣的，UC 所提的輕應用概念也不是傳統意義上的純 Web App，例如作為 UC+ 組成部分的插件，本身就可以基于 Native App 技術架構完成。

QQ手機瀏覽器5.0引入了輕應用概念。但是，如果 QQ 手機瀏覽器的輕應用不被引入應用寶，不被搜狗移動搜索支持，其實用價值將仍被局限在手機瀏覽器的傳統使用范疇。反之，如果這個輕應用能被引入到微信，那么... 也就不需要那么了...

此外，點心桌面也提供了類似的輕應用中心。

這幾家巨頭都有能力在應用分發和搜索等領域相互滲透，2014 年，輕應用有可能得到進一步探索和演進。對應用開發商而言，輕應用可以成為新的發布渠道。

4. 微信App

微信提供的公眾賬號開發架構，就包含了基于 Web App 的實現部分；而任何可以提煉出 URL 的 Web App，都可以在微信中自由傳播并直接在其自帶瀏覽器中打開，微信本身就可以作為 Web App 的傳播渠道。

作為名符其實的第一入口，微信劍鋒所指皆是 App 開發者唯恐趨之不及的方向。微信 App 的存在，是對 Web App 應用的極大促進。

但同時，基于微信的 Web App，在技術和產品層面也至少面臨的如下問題：

1) 目前微信所帶內核為系統自帶內核，例如在 Android 上就是一個 WebView，支持能力和運行性能都非常有限；

2) 微信產品基于 IM，始終保持信息流動狀態，難以形成針對特定 URL 的固定入口，所以，在微信上，很難形成針對特定 Web App 頁面的沉淀的用戶。（當然，收藏功能以及微信自身提供的應用列表如游戲可以提供固定入口，但前者需要用戶自行操作，而后者只屬于極個別有特殊資源的應用。）