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

智能手机和微信时代，对Web与手机浏览器的再思考（上）编者按：在PC时代，Web的主要承载体是占据流量入口地位的PC浏览器；然而在智能手机时代，Web依托不同载体呈现出多元形态，手机浏览器更要面对微信、垂直App、移动搜索、应用商店等应用的分流与挑战。2013年之前，行业对于手机浏览器的思考，始终伴随着一个热门话题：WebApp与NativeApp，谁代表未来？在本文作者看来，Web与Link都没有死，它们在微博、微信引爆的社会化传播浪潮里表现出了更为强劲的生命力。通过上、下两篇文章，作者分别呈现了在新的阶段对Web和手机浏览器做出的思考。在上篇中，作者分析了当前WebApp主要应用形态的特点，及各自在应用开发方面的优劣势。【本文作者Hans（QQ/微信：1396255225），移动互联网从业者和观察者，关注TMT各领域。】2010年，Wired杂志的一篇Thewebisdead,longlivetheinternet被国内行业媒体广泛转载；2012年，搜狗小川总也对媒体表示，“link（链接）已死，就是说手机它未来不是靠链接构建的网络环境，浏览器是以链接为核心驱动的...”。时至今日，社会化传播已经成为支撑整个移动互联网生态运转的核心力量之一。移动互联网的任何产业领域，早已无法离开粉丝经济。当移动互联网用户越来越习惯通过微信、朋友圈、微博分享视频、音乐、购物、资讯乃至天气、位置...，当越来越多的的NativeApp希望得到社会化媒体的广泛传播（并得到回流），他们都需要一个普适的，标准的传播格式。我们可以清晰的发现，承载社会化传播的最广泛也是最恰当的基础，恰恰是那个曾经被视为“已死”的Web与Link。优酷客户端是Native的，淘宝客户端是Native的，酷我音乐是Native的，百度地图是Native的，Zaker是Native的，搜狐新闻是Native的...但这些NativeApp所提供的分享，传播，却是标准的Link，Page和实实在在的WebApp。答案似乎很明显：在移动互联网时代，Web与Link都没有死，相反，却在社会化传播的浪潮里爆发出更为强劲的生命力。此外，在移动互联网时代，虽然PC互联网基于百度、搜狗等搜索框的访问形态开始被诸多垂直搜索分流，但传统的搜索模式依旧是移动互联网用户最常用的服务；而能够承载这种跨领域通用搜索模式的技术基础，依旧只能是基于Web的爬虫，检索......所以，对任何希望能够通过通用搜索入口触及用户的应用而言，Web仍须成为其基础性的内容形态之一。关于WebApp在PC互联网时代，Web的承载基本就是浏览器。而在移动互联网，特别是智能手机普及的时代，Web完全可以绕开传统意义上的手机浏览器，典型的例子是：社会化传播的承载体（如微信、微博客户端），在传播Web与link的同时，并不要求用户必须通过手机浏览器访问Web；相反，集成了浏览器内核部件的微信，微博可以让用户直接在客户端访问链接，直接运行WebApp，甚至直接玩HTML5游戏。手机浏览器似乎很难完整复制PC浏览器的卡位优势，相反，Web在社会化传播时代的价值却使得手机浏览器不得不面对更多的分流，因为Web在移动互联网时代呈现出了更多元的形态，或者说，Web已经融入更多的NativeApp：1.基于传统手机浏览器的WebApp从一般定义上讲，在手机浏览器中通过导航、链接打开某种基于Web的近似于NativeApp体验的服务，是WebApp最正宗的应用场景。这种产品模式的好处一直被行业称道和期待：跨平台，无需下载，一点即用。相对于垂直NativeApp，手机浏览器具备“覆盖广泛，快速到达”的核心优势，几乎可以直接到达移动互联网的绝大多数服务，用户并不需要事先下载，甚至不需要了解具体应用的存在，打开手机浏览器就可以快速到达。所以，对于解决用户的长尾需求而言，手机浏览器始终是必备，难以被替代。但是，时至今日，（基于传统手机浏览器的）WebApp应用现状，似乎还未普遍达到行业期待；特别是在部分高频应用垂直领域，应用的WebApp形态访问量还不能与其NativeApp形态比肩。为什么？1)问题：仅从产品层面来说，在手机浏览器中运行交互体验很强的WebApp，至少存在如下先天缺憾（必须要说明，如下问题大都不应算作手机浏览器的产品问题，而是WebApp技术规范在手机端实现的先天缺陷）：a.操作可能混淆，交互体验受影响WebApp运行在手机浏览器上，等于在底层操作系统与App之间隔了一层手机浏览器；同时，手机浏览器必须提供通用的方式操作大部分应用，很难对所有类型的应用都提供定制化的操作体验。所以，用户对App的若干交互操作可能被视为对手机浏览器的通用操作，造成用户操作预期与实际响应的不对称。看看如下场景：NativeApp中应用内的前进回退操作，可能被视为手机浏览器Label页面的回退操作；手机屏幕很小，对一些涉及垂直搜索的WebApp，用户容易混淆App的搜索框与手机浏览器的搜索框；WebApp提供的“对话框”，用户无法通过回退按钮退出；某些应用并不希望提供左右滑屏或上下滚屏（而希望固定页面），但在手机浏览器中，用户的滑屏操作可能误引起应用页面的不当移动，甚至退出应用；b.每次都需要下载，消耗流量，且影响界面品质WebApp无需像NativeApp那样必须先行下载安装，这样的“优势”实际上意味着：每次运行WebApp都需要进行基础业务数据的下载；在应用内每个新页面都需要进行数据下载；......简言之，WebApp的流量消耗可能更大。当然，手机浏览器可以通过缓存或HTML5本地存储等方式减少每次启动运行WebApp的流量，但这是不可控的。基于这样的风险，大部分WebApp，都必须限制启动流量，带来的后果就是界面与交互品质难以与NativeApp媲美。c.HTML5/WebApp内核问题a)运行效率和渲染能力低：传统手机浏览器内核对HTML5canvas的渲染基于CPU处理，渲染效率无法比肩NativeApp；2011以来，全球范围内有若干厂商尝试过基于GPU渲染处理HTML5canvas，但这类技术仍普遍面临适配性问题，以及针对非canvas页面的处理问题。同时，HTML基于JavaScript，而JavaScript是实时解释型语言，语法非常灵活，其设计初衷之一就是牺牲效率换灵活，且其设计之初并未考虑过在移动设备运行，其执行效率天然与NativeApp存在明显差距，对部分App而言，这个差距远非单纯GPU渲染可以跨越。b)一些HTML5系统接口的处理效果仍欠佳，例如：调用系统相机，录音...当前HTML5接口执行效果仍欠佳，支持的参数也有限，很难想象基于Web运行类似camera360，美图秀秀，嘀嘀打车这样的App。基于Web截获pinch或多点触控消息，其执行效果明显逊色于Native调用，类似百度地图的WebApp，其交互体验并不理想。此外，HTML5提供的特性仍不能完整覆盖NativeAPI，包括：系统推送，调用本地App等。c)HTML5规范尚不统一，影响跨平台的优势理论上，HTML5是一种跨平台，跨浏览器的技术平台，可以做到：一次开发，多平台发布。但在事实上，由于不同浏览器的处理差异，大部分WebApp都必须对多种不同手机浏览器做出若干细节适配；而针对不同的手机，不同屏幕尺寸，不同CPU乃至GPU，可商用的WebApp都需要进行针对性适配。（与之形成对比的是，基于NativeApp进行开发，跨平台逐渐成为开发框架的标配，越来越多的Native技术引擎天然就支持跨平台）2)解决：那么，WebApp能否克服上述问题，真正体现其价值？HTML5能否真正达成NativeApp的应用效果？事实上，行业的既有商用已经给出了清晰答案：能！a.当下主流手机浏览器往往会针对视频，阅读，游戏，图片4种应用提供独特的访问模式，特定访问模式不会受到手机浏览器通用操作的影响，在很大程度上解决了操作体验问题；b.HTML5在Native功能方面的缺陷，可以通过直接调用NativeAPI的桥接方式克服，AppCan，PhoneGap都提供了相应的解决方案；而在手机浏览器中，也逐渐加入了基于Native的功能调用，典型如二维码扫描，调用Native形态的特性（如UC提供的“找身边”）；c.重构内核，绕开HTML5和JavaScript的性能劣势。到目前为止，基于传统内核，试图在保证HTML标准性基础上达成NativeApp效果的尝试，都没有成功的典范。相反，某些内核架构，舍弃一些“标准”，对部分特性进行优化，却可以达到很好的商用效果。最为典型的商用产品是cocos2d-html5+JSB，此种方案对HTML5和JavaScript的使用有诸多限制，本质上提供的是已经是半私有的接口了，但其性能效果和适配性非常出色；另外UC开发的xCanvas，国外的Ludei等也在某种程度上采用了类似机制;d.开发商对应用进行较为深入的优化适配（有资源的话，甚至可以直接阅读浏览器开放内核代码并找到可优化点），可以考虑舍弃一些不必要的功能例如DOM+Canvas混搭，特定的WebApp完全可以达到NativeApp运行效果。——对开发者而言，“标准性”首先要服从“实用性”。2.Hybrid形态的WebApp基于HTML+JavaScript开发，通过AppCan或PhoneGap等产品打包，生成NativeApp形态的应用；这是WebApp另一种广泛存在的形态。它的优势在于：1)充分利用HTML的跨平台优势，一次开发，可以生成Android,iOS,WinPhone的NativeApp；2)HybridApp内的内容，都可以直接通过URL分享到社会化媒体；相较于纯NativeApp，非常便于社会化传播；3)相对于传统NativeApp，基于HTML和JavaScript的开发部署更为灵活，资源可以部署在服务器端，也可以打包在客户端，同时应用升级也更为简便；而且，HTML内容可以预先打包在HybridApp中，无需每次运行都下载；4)基于AppCan,PhoneGap提供的统一内核（例如WebView），不用考虑针对多种三方手机浏览器进行适配；5)AppCan,PhoneGap提供了丰富的插件和增强API，帮助应用达成Native的商用效果；而这种模式最为显著的弱点在于：它采用的内核运行性能较差，一般难以支撑性能要求较高的应用，特别是手机游戏。3.轻应用形态的WebApp轻应用是2013年360，百度，UC一度热炒的概念，至今并无确切的定义，三家巨头所提的逻辑也并不完全相同。不过大体上，轻应用是基于WebApp的一种创新应用封装方式。1)360的轻应用，关键词：应用分发将WebApp封装为基于操作系统桌面的快捷方式，更重要的是可以通过360的手机分发渠道进行分发，这是360对传统智能手机应用分发形态的一种创新尝试。对用户，特别是小白用户而言，这种应用获取方式与在应用商店下载安装达成的效果基本相当，但省却了下载的流量和安装的过程。同时，这种应用形态，也可以规避在手机浏览器中运行WebApp需要兼顾多种交互操作的问题。2)百度的轻应用，关键词：移动搜索百度强调传统NativeApp应用分发模式存在大量长尾的信息孤岛，难以被用户在应用商店检索到（比如用户根本就不知道这些应用的名字），即使被下载安装其使用频度亦极低。而基于应用商店之外的移动搜索则可以在用户需求与应用之间建立起即时关联。这种搜索必然不是传统应用商店基于名称、类别的检索，而是面向用户自然语言的搜索，同时也必然涉及应用内信息检索。百度的搜索能力+基于WebApp形态的应用，本身就已经实现了这种关联。另外，百度针对其轻应用，亦提供多种增强API，帮助WebApp提供类似NativeApp的功能特性。同时，基于91，安卓市场，百度手机助手带来的市场份额，百度已经成为第一大应用分发商，轻应用形态也有可能得到其众多移动客户端、分发渠道的支持。3)UC的轻应用，关键词：超级App移动App的使用越来越集中，用户更习惯访问