应用商店危机：BAT选择同时变身“轻”量化

　　

 

　　事情从UC的去留说起，上周，俞永福终于不用再费劲地向澄清，“我们不卖”。

　　几个月前的某节点，百度一心想全盘收购这一流量聚合大户，摆脱移动端的窘境，没成;换成阿里“退一步海阔天空”，只增持不控股，改为战略合作。不想退休的俞永福自然选择了后者。

　　真正好玩的是后续发展，百度转而收购91，但在2013年的百度世界大会上却几乎只字未提，反倒是持续抨击应用商店的弱点，并把所有人的注意力引向“轻应用(其实说的就是Web App)”这一概念。而阿里巴巴这次选择的小伙伴UC，则以控制Web和插件著称;最后，再加上一直不遗余力推广微信公众账号的腾讯，你就会发现BAT三巨头的某条思路已经无限接近——应用商店已经“着火”，不堪重负，开发者怨声载道，移动互联网是时候变“轻”了。

　　然后就出现了这种全新架构的解决方案：开放平台，即App的SOA化(面向服务的架构)。所谓SOA，就是把软件各个功能打包成一个个服务，整个系统由不同功能的服务互相通信完成，这样，整个系统就不会因为过于庞大而难以维护。各个服务都单独完成一项小小的功能，非常易于维护，而不同服务连接起来又可以完成复杂的任务。

　　这一点在手机上尤其重要，过去几年如果查看一些使用量庞大App的用户评论，必然会出现的吐槽点就是“臃肿”，连微信也躲不过这一枪。

　　但事实上，这个问题已经在解决的路上了。功能性和简约的平衡点是一种感官感受，而要找到这个点的，不应该是标准化生产产品的企业，而应该是非标准化使用产品的用户。在这种准则下，臃肿与否的标准是用户来决定的:以浏览器为例，是要个布满插件的“变形金刚”，还是连首页都用空白页，照着自己口味来就行。

　　应用商店本质上也是SOA，但问题是其与外部服务的连接过于简单——仅限于流量的一次性推广而已，无他，单一的机制就导致了这个平台只属于少数者，用李彦宏的话说，“0.1%的应用却吸引了70%的眼球”。

　　反过来说，SOA中内部系统与外部服务的连接如果能多一些，那么对于开发者来说就更容易获得价值。

　　在BAT最新的SOA架构中，*改变之一就是服务形态的“轻量化”，并且连接方式更多更紧密。很显然，与Object C或者JAVA(Native App)比起来，HTML或JavaScript(Web)带给开发者和用户双方的压力都要小得多——开发简易、无需安装、体验足够，*够“轻”;而发现推广和调用方面，由于承载服务的平台本身就是使用频度极高的超级App，因此面向开发者的流量推广就不是一次性，而是无限次。不用费劲心思地花钱刷榜，这点也够“轻”。

　　现在看来，BAT都对这种产业走势给出了足够的重视，从自身的主力产品中衍生出SOA进行试水。

　　百度绕了很多弯后，又回归到老本行搜索，通过百度App和百度网页以类似于PC端框计算的形式在移动端分发“轻应用”;腾讯擅长即时通讯，微信的SOA也采用了对话的交互方式来设计公众账号服务。

　　最后的阿里则有些特殊，因为它的立身之本是个电商平台，并不是某种工具类应用，在这方面必须依靠合作伙伴来布局。UC浏览器的主基因是“展示”，提供了网页应用中心(Web App)和插件系统(浏览器Plug-in，整合快播、迅雷、翻译等)，正在不断网罗开发者，转变为新型的轻量级移动生态平台，对阿里来说就是理想的战略同盟。

　　三者的整体方向几乎是一致的：超级App 非客户端功能(插件/公众账号/轻应用等)，“ ”后面原来就是“臃肿”的根本原因所在，现在交出来让用户自己看着办;至于前面的超级App，理论上应该就是个“光杆司令”，但出于风格的不同，三家有些出入。比如媒体上经常出现的桥段：腾讯上百个产品经理盯着微信，嗷嗷待哺，张小龙则苦苦支撑不断否决各种功能接入需求。相比之下，搜索引擎和浏览器倒是没有那么大的麻烦，前端的一个框和一个内核能从感官上觉得“轻”了。

　　总体来说，能同时让推着BAT针对性布局，至少证明现在应用商店主导的移动互联网生态，确实存在着很大的瓶颈——App还是很重要，但开发推广成本高，已经进入竞争惨烈的红海期，插件或者Web等“轻服务”完全可以替代现在很大一部分Native App(游戏等重度应用除外)。

　　移动互联网整体会变“轻”，因为在现有生态规则下，有资格“重”的玩家只是少数。　　

 

　　事情从UC的去留说起，上周，俞永福终于不用再费劲地向澄清，“我们不卖”。

　　几个月前的某节点，百度一心想全盘收购这一流量聚合大户，摆脱移动端的窘境，没成;换成阿里“退一步海阔天空”，只增持不控股，改为战略合作。不想退休的俞永福自然选择了后者。

　　真正好玩的是后续发展，百度转而收购91，但在2013年的百度世界大会上却几乎只字未提，反倒是持续抨击应用商店的弱点，并把所有人的注意力引向“轻应用(其实说的就是Web App)”这一概念。而阿里巴巴这次选择的小伙伴UC，则以控制Web和插件著称;最后，再加上一直不遗余力推广微信公众账号的腾讯，你就会发现BAT三巨头的某条思路已经无限接近——应用商店已经“着火”，不堪重负，开发者怨声载道，移动互联网是时候变“轻”了。

　　然后就出现了这种全新架构的解决方案：开放平台，即App的SOA化(面向服务的架构)。所谓SOA，就是把软件各个功能打包成一个个服务，整个系统由不同功能的服务互相通信完成，这样，整个系统就不会因为过于庞大而难以维护。各个服务都单独完成一项小小的功能，非常易于维护，而不同服务连接起来又可以完成复杂的任务。

　　这一点在手机上尤其重要，过去几年如果查看一些使用量庞大App的用户评论，必然会出现的吐槽点就是“臃肿”，连微信也躲不过这一枪。

　　但事实上，这个问题已经在解决的路上了。功能性和简约的平衡点是一种感官感受，而要找到这个点的，不应该是标准化生产产品的企业，而应该是非标准化使用产品的用户。在这种准则下，臃肿与否的标准是用户来决定的:以浏览器为例，是要个布满插件的“变形金刚”，还是连首页都用空白页，照着自己口味来就行。

　　应用商店本质上也是SOA，但问题是其与外部服务的连接过于简单——仅限于流量的一次性推广而已，无他，单一的机制就导致了这个平台只属于少数者，用李彦宏的话说，“0.1%的应用却吸引了70%的眼球”。

　　反过来说，SOA中内部系统与外部服务的连接如果能多一些，那么对于开发者来说就更容易获得价值。

　　在BAT最新的SOA架构中，*改变之一就是服务形态的“轻量化”，并且连接方式更多更紧密。很显然，与Object C或者JAVA(Native App)比起来，HTML或JavaScript(Web)带给开发者和用户双方的压力都要小得多——开发简易、无需安装、体验足够，*够“轻”;而发现推广和调用方面，由于承载服务的平台本身就是使用频度极高的超级App，因此面向开发者的流量推广就不是一次性，而是无限次。不用费劲心思地花钱刷榜，这点也够“轻”。

　　现在看来，BAT都对这种产业走势给出了足够的重视，从自身的主力产品中衍生出SOA进行试水。

　　百度绕了很多弯后，又回归到老本行搜索，通过百度App和百度网页以类似于PC端框计算的形式在移动端分发“轻应用”;腾讯擅长即时通讯，微信的SOA也采用了对话的交互方式来设计公众账号服务。

　　最后的阿里则有些特殊，因为它的立身之本是个电商平台，并不是某种工具类应用，在这方面必须依靠合作伙伴来布局。UC浏览器的主基因是“展示”，提供了网页应用中心(Web App)和插件系统(浏览器Plug-in，整合快播、迅雷、翻译等)，正在不断网罗开发者，转变为新型的轻量级移动生态平台，对阿里来说就是理想的战略同盟。

　　三者的整体方向几乎是一致的：超级App 非客户端功能(插件/公众账号/轻应用等)，“ ”后面原来就是“臃肿”的根本原因所在，现在交出来让用户自己看着办;至于前面的超级App，理论上应该就是个“光杆司令”，但出于风格的不同，三家有些出入。比如媒体上经常出现的桥段：腾讯上百个产品经理盯着微信，嗷嗷待哺，张小龙则苦苦支撑不断否决各种功能接入需求。相比之下，搜索引擎和浏览器倒是没有那么大的麻烦，前端的一个框和一个内核能从感官上觉得“轻”了。

　　总体来说，能同时让推着BAT针对性布局，至少证明现在应用商店主导的移动互联网生态，确实存在着很大的瓶颈——App还是很重要，但开发推广成本高，已经进入竞争惨烈的红海期，插件或者Web等“轻服务”完全可以替代现在很大一部分Native App(游戏等重度应用除外)。

　　移动互联网整体会变“轻”，因为在现有生态规则下，有资格“重”的玩家只是少数。