智能手机和微信时代，对Web与手机浏览器的再思考 2025-10-18 21 summer1986

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

在上篇中，笔者描述了Web App主要产品形态（基于传统手机浏览器，Hybrid形态，轻应用形态以及微信App形态）的特点，本篇将重点谈谈对手机浏览器的一些思考。

关于手机浏览器

1. 传统手机浏览器形态开始逐步接近天花板

功能机时代，UC通过其C/S架构及由此带来的跨时代的产品体验，实现了巨大的成功：手机浏览器成为功能机用户最常用的应用，也一度被认为代表未来，或几乎已经成为了名副其实的第一入口。

智能手机时代已经到来，UC、QQ凭借其出色的产品运营能力和不断完善的产品体验，依然交出了令人信服的答卷。但是…

1) 移动互联网用户红利在减退

传统功能手机快速走向消亡，而智能手机总量增长率在减缓。

三方手机浏览器在功能机时代积累了约3~4亿用户群体，这个群体是其中坚用户，他们对三方手机浏览器有较深的使用经验和习惯；而直接在智能手机体验手机浏览器的用户，他们一开始就会面临海量优质应用的选择，对手机浏览器则更难形成唯一必备入口的印象。

Android手机总量增长减缓，且Android手机增长中还有近半数来自老Android用户换机（数据：《百度移动互联网发展趋势报告2013Q3》）

 2) 用户对手机浏览器的认知逐步向工具转移

全球范围内，三方手机浏览器的分布与智能手机的分布呈现出较明显的关系：

在智能手机渗透率最高的欧美、东亚发达地区，手机浏览器基本是Android, iOS自带浏览器的天下；而在一些人口基数较大，智能机渗透率快速增长的地区如俄罗斯，印度，印尼，巴基斯坦，巴西等，Android自带浏览器份额均在过去2 ~ 3年内发生2 ~ 4倍增长。（数据来自：http://gs.statcounter.com/）

在国内，大多数统计报告都显示，Android平台上UC的整体应用量与微信、QQ同属Top3，远超其他垂直App；但在iOS平台，手机浏览器的应用排名则明显低于其在Android的表现。

随着用户对智能手机使用水平的逐步提升，用户对手机浏览器的认知可能逐步从“综合服务型产品”向“工具型产品”转移。

2. 用户为什么要使用手机浏览器？

手机浏览器依然是访问讯息最为便捷，可切入领域最为广泛的App；作为基础性的工具，手机浏览器也是最不易被删除的App之一；基于传统的使用习惯，手机浏览器几乎是必备App。至少在如下领域，手机浏览器始终是用户认知的最重要入口（或之一）：

a. 移动搜索

Smart Phone时代的移动搜索正在被各种垂直App的内置搜索分流。但是，对用户而言，传统基于搜索框的操作方式，仍然是最为习惯，也是最为简便快捷的通用搜索模式。

在手机上，用户心目中的通用搜索的入口在哪里？至少到目前，这个答案仍然是唯一的：手机浏览器。

移动搜索的需求是智能机时代手机浏览器存在的核心根基之一，也是手机浏览器成为用户最不愿意删除的App的重要原因。

b. 导航

与移动搜索类似，手机浏览器提供的导航仍是移动互联网普通用户按需求到达目的业务的最简捷方式，且无需用户面对新的App操作方法。导肮在未来数年内无法被取代（至少在中国是如此），用户心目中的导航，仍然几乎只与手机浏览器唯一关联。

c. 资讯浏览，包括新闻，图片，小说，视频，也包括电商

这些领域，基于PC互联网以及功能机时代养成的习惯，用户在智能手机上，也会更多地倾向于基于手机浏览器访问。

在手机浏览器上访问这些业务，用户可以方便地进行对比选择，手机浏览器也可以基于此运营自己的内容导航。

另外，这些业务领域的应用，对性能和特殊Native API的需求较小，很多垂直Native App本身就采用了Hybrid App的技术方案，访问同样业务的Native App和Web App，其操作界面和交互方式可能非常接近（典型如新浪微博，优酷，一号店…）

同时，在这些领域，UC、QQ等老牌手机浏览器的运营经验并不逊色于垂直App；手机浏览器也往往会针对这些领域提供特别的功能特性，达成更好的产品体验。

所以，在这些特定的垂直领域，手机浏览器仍可占有很强的优势。

3. 关于HTML5页游

过去几年里，各家手机浏览器还曾在HTML5测评分等领域展开过数次纠斗，行业也曾寄希望手机浏览器复制PC页游的辉煌；时至今日，这些期待仍未达成，原因包括：

1) 技术

如上篇分析Web App的文章所讲，手机浏览器以及系统内核对传统意义上HTML5的支持仍未达到与Native App效果比肩的程度。HTML5测评分仅代表该内核是否支持某种属性，而其支持的程度和性能表现并不能被体现。

2) 娱乐属性

在页游领域，手机浏览器已经很难复制PC页游之路，原因并不主要在技术，更重要的是：与用户对PC浏览器的认知比较，用户认知的手机浏览器本身娱乐属性较低。相较于微信、QQ以及已经切入游戏并迅速形成千万级流水手游的陌陌这类应用而言，大部分手机浏览器还缺乏社交属性。

当然，对游戏开发商而言，页游的技术仍然富有意义，只是其分发渠道不能仅限于页游。行业中有影响力的HTML5手游，其主流分发形态都是Hybrid App下载，只有UC、QQ尚可借助其庞大用户流量和资源的倾斜产生少量有一定用户基数的手机页游。

3) 微信对Web App的影响

触控陈昊芝在2013年曾说“微信是HTML5的最好平台，没有之一”。

微信是几乎所有应用最重要的社会化传播渠道，在微信中传播的Web App必须要适配微信自带浏览器。而微信自带浏览器内核（在Android上就是WebView）在Android 4.*版本下的HTML5测评分仅为355，远低于国内大部分三方手机浏览器（包括其自家兄弟QQ手机浏览器）。

甚至部分HTML5手游，本身就寄希望把微信作为主要渠道，这些游戏在技术层面首要考虑的就是适配微信的“低端内核”。举个有趣的例子，到目前为止，影响力最大的HTML5页游是微信的打飞机，该游戏却并不需要多好的HTML5支持，同样的情况也发生在新浪微博微游戏客户端。（当然，这是非常特殊的例子，不具备广泛参考价值）

4. 哪些产品在分流手机浏览器？

1) 操作系统内置浏览器：分流指数 ★☆☆☆☆

Firefox中国的宫力近期在媒体访谈中提到“Android版的Firefox浏览器在Google Play上所有浏览器中排名第一，比Chrome都好，但只有大概5000万左右的用户。为什么大家不用？因为大家懒，不愿意下载了，要么用APP，要么就用内置的浏览器。”（信息源：《Firefox，操作系统比浏览器更有竞争》）。就全球范围看，内置浏览器的确会对三方浏览器产生抑制。

不过，正如Google Play在欧美和中国市场表现的巨大差异，三方浏览器在中国的表现并不等同于在欧美国家。UC、QQ等手机浏览器在如下几方面存在巨大优势：用户认知度，运营能力，推广特别是预装能力。事实上，对大部分中国智能手机用户而言，所谓“内置浏览器”就是以UC为代表的三方手机浏览器。

智能手机内置浏览器会占据一定市场份额，但很难对三方手机浏览器的份额产生冲击。

当然，在iOS这个封闭系统内，三方浏览器的推广受到抑制， 内置Safari的确对三方浏览器产生了替代的效果；另外，假如Android产业链将chrome mobile作为系统缺省浏览器，则对目前的三方手机浏览器也将产生显性的冲击。

2) 垂直领域App：分流指数 ★☆☆☆☆

手机浏览器可以切入绝大部分应用领域，同时大部分领域的Native App也都会对手机浏览器产生分流。

但是，这种分流对手机浏览器产生的威胁很有限：手机浏览器作为一个“超级应用”，其平台性质、导航、快速到达业务的能力是垂直App无法替代的。

只有那些自身可以成为平台级产品或“超级应用”的App有可能成为用户的常备App，并对手机浏览器产生威胁；而大部分垂直App的长尾入口，仍然会被手机浏览器吸纳。

3) 应用商店：分流指数 ★☆☆☆☆

功能机时代，三方手机浏览器本身也成为了最佳的应用推广平台。

但智能手机发展到今天，专业的应用商店已经成为了用户获取应用的第一入口，国内的应用分发市场，属于百度、360、豌豆荚以及正在奋起直追的腾讯。在手游分发领域，借助早期投入的九游平台，UC在手游分发平台一直位居第一阵营，并藉此极大提升了盈利能力；但其他手机浏览器要获得同样的机会已经非常困难。

当前的应用商店有一些先天缺陷：

a. 必须要下载安装，难以满足用户长尾的即时应用需求；

b. 对应用开发商而言，应用商店能提供的推广资源非常稀缺，马太效应明显；

c. 有搜索有导航，能够满足用户的搜索需求，但难以满足用户的自然需求；

…

同时，应用商店已经被用户认知为日常重要入口。从自身的战略扩张角度，应用商店也期望能够进一步成为真正的“超级App”。所以，我们会看到如下的产品特性：

a. 豌豆荚明确提出“应用内搜索”“向内容入口转型”的战略；

b. 360手机助手率先引入“轻应用”；

c. 豌豆荚和360手机助手均将搜索扩展到应用、游戏、视频、电子书、壁纸等多个娱乐内容类；

….

结果是：应用商店户会让用户越来越直接地到达内容本身。

而如果应用商店不断扩展其内容领域，并充分利用轻应用的优势，则会逐步侵蚀到手机浏览器的产品根基。（当然，应用商店要做到这一点，面临的问题非常多，此处不赘述）

“应用内搜索”是应用商店必须要解决的技术问题，这是充分释放长尾应用能量的核心手段，也是对用户需求的真正满足。

4) 微信：分流指数 ★★☆☆☆

基于公众号、用户关系和社会化传播，微信早已超越传统IM的范畴，成为开放的超级App（而公众号则成为微信App）和社会化传播的渠道，几乎可以切入它想要切入的任何领域。

面对海量微信App，相对于应用商店、手机浏览器这些平台而言，微信似乎少了一个基础性的运营部件——公共导航，且微信对公众号的搜索也做得非常粗略。

事实上，微信有自己的导航——用户关系和公众号订阅。其他任何平台都难以形成这样的导航——因为这个导航是用户自己建立的。另外，微信固有的IM模式，也使得其内容始终处于高频度更新状态，而用户的自我传播诉求也能得到极大释放。

这使得微信拥有了难以匹敌的高粘性——用户任何时刻进入微信，都可以直接获得和传播与用户个体密切相关的内容。QQ手机浏览器有一个广告词：“我要的现在就要”，这句话放在微信上，似乎特别贴切。

综上，如果把用户对内容的需求消费周期划分为“发现—>查找—>传输—>消费—>管理—>分享”，那么，微信实现了更为完善的闭环，特别是在管理与分享环节。

但是，在发现与消费环节，微信很难对手机浏览器产生替代作用。

首先，至少目前看，微信未有在移动搜索领域的明显动作；即使未来微信推出移动搜索，其形态可能与传统搜索有较大差别，正如微博搜索有其独特优势但无法取代百度搜索一样，微信搜索可能很难对移动搜索的传统应用形态产生根本性影响。

另外，微信对Web App的应用限制和不确定性比手机浏览器要更多，包括：

a. 从用习惯角度：用户并不认为微信会提供系统化的内容供浏览；用户与公众账号的交互更多是在其IM界面中完成，而对其Web部分的使用，用户往往只限于浏览内容，不会进行复杂的交互；

b. 从阅读体验角度：国内三方浏览器提供了大量优化的阅读模式，体验非常出色，用户可以系统化阅读资讯、小说、图片等；而微信提供的阅读体验则非常苍白；

c. 从公众号开发方角度：大部分的应用开发商，都只是将微信视为传播和推广的渠道，并不在微信中提供完整的应用内容；当然也有例外，特别是自媒体；

d. 从技术角度：微信所包含的手机浏览器内核，是操作系统自带内核，在Android上运行效果非常受限；

e. 从微信的业务发展角度：2014年的微信重点在哪些领域？微信究竟是带自家产品多，还是更加开放？

5) 移动搜索：分流指数 ★★☆☆☆

在PC端，浏览器与（通用）搜索有着天然的紧密关系、360和搜狗的PC浏览器都为自家的搜索作出了无可替代的贡献。

移动搜索同样是一个有想象空间的Big Deal，也是2014巨头移动大战的重要战场。但是，传统PC端通过浏览器为搜索构筑护城河的模式已经很难复制，原因在于：手机浏览器大格局基本已经确定，很难发生颠覆性的改变；随着阿里入股UC，这个巨大的搜索入口对其他巨头显得更加不可控；更重要的是，移动搜索的入口形态并不单纯表现为手机浏览器。

对百度、搜狗、360而言，必须要不断发展或巩固其在移动搜索的入口。

百度已经迈出了最为显著的步骤。2012年底，百度手机浏览器声称3个月用户过亿，被普遍当作笑谈。直到2013年下半年，百度告诉行业，他们已经有14个移动客户端用户过亿，其中最大是手机百度，月活过亿。

手机百度是什么？百度说“用手机，随时随地百度一下”。从产品定位和用户认知角度，这是一个搜索客户端；但从其产品形态看，手机百度与手机浏览器区别有多大？

在iPhone的AppStore中，排名最高的手机浏览器是哪几家？UC还是QQ？

看看免费榜总排名：

2014年2月6日，手机百度，22；UC浏览器，24；QQ浏览器，87。

2014年3月2日，UC浏览器，26；手机百度，31；QQ浏览器，110。

移动搜索对手机浏览器的挑战在于：移动搜索入口形 态不一定表现为手机浏览器，但其结果形态却一定需要覆盖手机浏览器的内容形态即Web；这样的入口，加上导航，轻应用，很容易形成事实上的手机浏览器；更重要的是，用户对移动搜索、百度的认知并不弱于手机浏览器。

总结和建议

智能手机和微信时代， Web技术依然拥有无可替代的应用价值。

1. 对手机浏览器

智能手机和微信时代，Web被各种App分流，手机浏览器不再是Web的唯一承载，其入口和平台地位受到更大挑战。但同时，这些挑战本身就蕴藏机会。

三方手机浏览器在技术、用户量，在用户心目中形成的入口地位…积累了巨大的优势，这些优势仍将持续释放。基于这些优势，对功能与定位的进行新的延伸或转型，这是2014年三方手机浏览器必须要思考的问题。例如：

1) 发挥作为移动（通用）搜索入口的优势：

移动搜索对手机浏览器的挑战同时也是手机浏览器的机遇。手机浏览器能否借助此入口地位，充分优化和提升移动搜索，让用户更方便地到达内容和应用（不管是Web、轻应用还是Native App），充分发挥出超级App的长尾优势？

2) 利用在Web领域的技术优势：

UC、QQ、百度、欧朋、海豚都对其内核投入过研发力量。当Web出现在越来越多的App中，三方手机浏览器的内核能否随之以Hybrid App甚至轻应用的形态嵌入到更多的App？关键在于，三方浏览器可以藉此向海量App提供更为广泛的服务。一个极端的例子是，Firefox直接把移动端的重点从手机浏览器转向Firefox OS。

……

我们也可以看到，轻应用首先在手机浏览器领域提出，UC向PC浏览器和电视浏览器迈出了步子…这些，都是手机浏览器的有益探索。

2. 对应用开发商

而对应用开发商而言，Web和HTML5在智能手机和微信时代则呈现出了更大的机遇。如何充分利用Web与HTML5获得更多的推广渠道，如何更便捷地到达用户，是值得好好实践的。

3. 对Web应用产业链

智能手机时代，Web应用的范畴已经广泛渗透到多个垂直领域；为HTML5/Web提供更好的发展平台，对整个产业链都具备良性价值——但同时，这已经不仅仅是手机浏览器的责任。

最后，对”Wired”杂志说一句，”The web is living and sparking, long live the HTML”。

来源：36氪 2014-03-15