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的若干交互操作可能被視為對手機瀏覽器的通用操作，造成用戶操作預期與實際響應的不對稱?？纯慈缦聢鼍埃?/p>

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頁面的沉淀的用戶。（當然，收藏功能以及微信自身提供的應用列表如游戲可以提供固定入口，但前者需要用戶自行操作，而后者只屬于極個別有特殊資源的應用。）

來源：36氪