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