旗下微信矩阵:

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

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

  

应用商店危机: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(游戏等重度应用除外)。

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

应用商店危机: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(游戏等重度应用除外)。

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

【本文由投资界合作伙伴创事记授权发布,本平台仅提供信息存储服务。】如有任何疑问,请联系(editor@zero2ipo.com.cn)投资界处理。