智能手机和微信时代_对Web与手机浏览器的再思考

智能手机和微信时代_对Web与手机浏览器的再思考

智能手机和微信时代，对Web与手机浏览器的再思考（上）

编者按：在PC时代，Web的主要承载体是占据流量入口地位的PC浏览器；然而在智能手机时代，Web依托不同载体呈现出多元形态，手机浏览器更要面对微信、垂直 App、移动搜索、应用商店等应用的分流与挑战。2013年之前，行业对于手机浏览器的思考，始终伴随着一个热门话题：Web App与Native App，谁代表未来？

在本文作者看来，Web与Link都没有死，它们在微博、微信引爆的社会化传播浪潮里表现出了更为强劲的生命力。通过上、下两篇文章，作者分别呈现了在新的阶段对Web和手机浏览器做出的思考。在上篇中，作者分析了当前Web 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。