对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 页面的沉淀的用户。（当然，收藏功能以及微信自身提供的应用列表如游戏可以提供固定入口，但前者需要用户自行操作，而后者只属于极个别有特殊资源的应用。）