浅析：应用商店危机 BAT选择同时变“轻”

浅析：应用商店危机BAT选择同时变“轻”

几个月前的某节点，百度一心想全盘收购这一流量聚合大户，摆脱移动端的窘境，没成；换成阿里“退一步海阔天空”，只增持不控股，改为战略合作。不想退休的俞永福自然选择了后者。真正好玩的是后续发展，百度转而收购91，但在2013年的百度世界大会上却几乎只字未提，反倒是持续抨击应用商店的弱点，并把所有人的注意力引向“轻应用(其实说的就是WebApp)”这一概念。而阿里巴巴这次选择的小伙伴UC，则以控制Web和插件著称；最后，再加上一直不遗余力推广微信公众账号的腾讯，你就会发现BAT三巨头的某条思路已经无限接近——应用商店已经“着火”，不堪重负，开发者怨声载道，移动互联网是时候变“轻”了。然后就出现了这种全新架构的解决方案：开放平台，即App的SOA化(面向服务的架构)。所谓SOA，就是把软件各个功能打包成一个个服务，整个系统由不同功能的服务互相通信完成，这样，整个系统就不会因为过于庞大而难以维护。各个服务都单独完成一项小小的功能，非常易于维护，而不同服务连接起来又可以完成复杂的任务。这一点在手机上尤其重要，过去几年如果查看一些使用量庞大App的用户评论，必然会出现的吐槽点就是“臃肿”，连微信也躲不过这一枪。但事实上，这个问题已经在解决的路上了。功能性和简约的平衡点是一种感官感受，而要找到这个点的，不应该是标准化生产产品的企业，而应该是非标准化使用产品的用户。在这种准则下，臃肿与否的标准是用户来决定的:以浏览器为例，是要个布满插件的“变形金刚”，还是连首页都用空白页，照着自己口味来就行。应用商店本质上也是SOA，但问题是其与外部服务的连接过于简单——仅限于流量的一次性推广而已，无他，单一的机制就导致了这个平台只属于少数者，用李彦宏的话说，“0.1%的应用却吸引了70%的眼球”。反过来说，SOA中内部系统与外部服务的连接如果能多一些，那么对于开发者来说就更容易获得价值。在BAT最新的SOA架构中，最大改变之一就是服务形态的“轻量化”，并且连接方式更多更紧密。很显然，与ObjectC或者JAVA(NativeApp)比起来，HTML或JavaScript(Web)带给开发者和用户双方的压力都要小得多——开发简易、无需安装、体验足够，绝对够“轻”；而发现推广和调用方面，由于承载服务的平台本身就是使用频度极高的超级App，因此面向开发者的流量推广就不是一次性，而是无限次。不用费劲心思地花钱刷榜，这点也够“轻”。现在看来，BAT都对这种产业走势给出了足够的重视，从自身的主力产品中衍生出SOA进行试水。百度绕了很多弯后，又回归到老本行搜索，通过百度App和百度网页以类似于PC端框计算的形式在移动端分发“轻应用”；腾讯擅长即时通讯，微信的SOA也采用了对话的交互方式来设计公众账号服务。最后的阿里则有些特殊，因为它的立身之本是个电商平台，并不是某种工具类应用，在这方面必须依靠合作伙伴来布局。UC浏览器的主基因是“展示”，提供了网页应用中心(WebApp)和插件系统(浏览器Plug-in，整合快播、迅雷、翻译等)，正在不断网罗开发者，转变为新型的轻量级移动生态平台，对阿里来说就是理想的战略同盟。三者的整体方向几乎是一致的：超级App非客户端功能(插件/公众账号/轻应用等)，“”后面原来就是“臃肿”的根本原因所在，现在交出来让用户自己看着办；至于前面的超级App，理论上应该就是个“光杆司令”，但出于风格的不同，三家有些出入。比如媒体上经常出现的桥段：腾讯上百个产品经理盯着微信，嗷嗷待哺，张小龙则苦苦支撑不断否决各种功能接入需求。相比之下，搜索引擎和浏览器倒是没有那么大的麻烦，前端的一个框和一个内核能从感官上觉得“轻”了。总体来说，能同时让推着BAT针对性布局，至少证明现在应用商店主导的移动互联网生态，确实存在着很