Android应用生态系统的控制

文章转载只能用于非商业性质，且不能带有虚拟货币、积分、注册等附加条件。转载须注明出处：http://blog.csdn.net/flowingflying/

之前看了VisionMobile的两篇文章，也在本博进行了翻译，分别是VisionMobile：命运反转：让设备兼容应用以及VisionMobile：剥光Android。就此进行了思路的整理和分析。

现状

在功能手机时代，开发者开发一个应用，需要适配到不同的设备。而在智能手机时代，庞大的应用生态系统为用户提供数以百万计的应用，用户需要能够运行应用的设备，即如今是设备要能让应用运行。

手机或平板要要能吸引消费者，必须有丰富的应用，不仅包括热门应用，还包括各类长尾应用来满足不同的应用场景，但仅此还不够，应用必须质量好，即界面好看，交互友好，功能全面。一个新平台要说服开发者将应用移植过来很困难，最好的方式就是能够直接兼容应用,利用Android的生态系统（而iOS对其他厂家封闭）。

设备能够兼容Android应用，除了使用Android原生系统外，有下面两种方式：

一、系统是Android的分支系统，即平台是Android的衍生平台，比较著名例子就是国内小米的MIUI，国外的亚马逊的Kindle Fire。

二、系统提供兼容Dalvik的虚拟机，即平台的Android应用的兼容平台。Android应用的兼容平台一般是基于linux上开发，通过提供能够兼容Dalvik的Java虚拟机来实现Android应用的兼容，例如已经有手机上市的从MeeGo发展过来的Jolla Sailfish（剑鱼）操作系统，又例如Ubutun、阿里云操作系统，以及可能的COS（China Operating System）系统。

控制

Android虽然是开源操作系统，但是从最初就受到Google严格管控。Google通过Android商标的授权进行管控。设备制造商必须符合兼容定义文档（CDD）并通过兼容测试套件（CTS）测试才可获准使用Android商标和Google Play Store。

然而随着时间的推移，这个控制点已经变得松动。Amazon和Yandex成功用自己的应用和内容商店替代了Google Play商店。三星不遗余力地建立自己 Galaxy品牌。此外，还有不少Android的衍生平台和Android应用的兼容平台打着各自的品牌，使用替代的应用商店。

为了重新控制Android平台，或者更准确地说是控制Android生态系统，Google公司对控制点进行了调整，从平台商标和应用发布转移到对应用开发的控制。Google将Android系统的某些关键API移入Google Play Services中，Google已经将数十个自己的应用和API从开源Android项目（AOSP）中移走，因此依赖特定Google应用和APIs的应用，包括日历、位置API、地图、消息推送、帐号同步和认证，将再不能在Android的分支版本中直接运行。

Google Play Services是私有的软件开发包（SDK）和应用程序编程接口（API）。 在开发者文档中，也称为Google移动服务（Google Mobile Services，GMS）。最早在2012年引入，为开发者提供直接集成Google业务的API，如帐号同步，Google+，Google地图，位置APIs，Google Play游戏，云消息，Android设备管理等等。Google Play Services是系统级进程，它和其他Google应用是相互独立的，它可以通过Google Play Store进行更新，因此当将部分API转入Google Play Services可以部分解决Android操作系统的碎片化问题。

要指出的是AOSP上仍可以提供照相、电子邮件、日历等一些应用，但是这些应用和来自Google Play Service的应用相比，界面和体验存在显著的差异。Google在Google Play Services中优化了APIs，进行创新和增添新价值，因此，从用户角度看，AOSP应用的体验是过时。在ARS Technica的文章中有详细说明，下面是当中的几个例子。

此举对开发者开发应用有深远影响，形成了Android生态系统的新控制点。开发者如今同时使用Android OS和Google Play Services的API。对于Android分支版本能够支持前者，但不能支持后者。之前，Android的Google版本和分支版本API之间差异主要是应用内计费 ；现在，差异包括了很多重要的服务，这些服务是被很多开发者所使用的，如果开发者要将应用发布给Android分支，就要向功能手机时代那样，重写他们应用的部分代码去适配这些衍生平台。

这种做法将直接威胁到依赖Android生态系统的平台，它们无法继续支持某些关键API，无法保证长期对API的支持。移动应用开发者要将Android应用适配这些平台，需要进行额外的应用移植工作，但因此要说服开发者进行移植，需要收买成本或用户量进行吸引。

反制

通过服务和API的替代，可以降低Google新生态系统控制点的影响。

前面我们看到AOSP上提供应用在功能和体验上都不如Google Play Services上提供的应用，用户自然会选择后者。三星在打造Galaxy品牌的同时，花费大量精力重建了所有Google业务，减少Google控制影响。

亚马逊利用其电商的优先对部分Google业务进行替代。亚马逊的Kindle Fire生态系统同样加载Android的修改版本，因此直接受到将关键API移出AOSP的影响。为了维持Android和Kindle Fire之间的应用兼容性，Amazon需要为非AOSP的所有Google API提供自己的版本，应用开发者需要在应用中明确支持这些APIs。Amazon已经这样做了，最近在在API列表中增加分析和分割测试能力，API列表包括登录、后端服务、计费、消息推送、广告，当然还有用来发布的Amazon Appstore。这使得Amazon对于新的Android API控制有免疫能力。

国内，Google的云服务并没有本土服务流行，事实上，各品牌的Android手机都是提供替代的应用商店，替代的地图服务，替代的搜索服务。这些服务由国内不同的移动互联网企业所持有，不少已经向对开发者开放API，但是与Google Play Services向比较，有下面的欠缺：

一、国内移动互联网业务API由不同的企业提供，没有统一集成起来，缺乏统一的文档，缺乏统一开发者社区和论坛；

二、国内移动互联网业务没有形成系统级进程，没有作为统一的开发套件向开发者提供。国内有一些分支平台，但是没有向开发者提供格外的开发jar包，提供额外的API调用。事实上，面对Google公司咄咄逼人的严格控制，他们可以尝试用搭建自有服务来替代Google Play Services。而由于Google在中国市场的影响是弱小的，和国外相比，薄弱的环节包括Google应用以及Google Play Service，正好在此作为分支平台的在应用生态系统的突破口。

替代Google Play Services，需要作为系统级服务，这样从开发者视图看，减少底层原生操作系统对API的影响，同时可以广泛地适用不同版本的Android衍生系统中。困难终于这些服务有不同厂家提供，需要将分散的国内移动互联网业务开发的API集成起来，为开发者提供统一提供自由服务的jar包，开发者可在现有的Eclipse开发环境中调用自由服务的API，并进行安装和调测。但是将这些市场上直接或间接的竞争者纠合在一起来一起办事，是困难的。即使国家层面成立的产业联盟，多半也是面和心不和，应付应付。

思考

Google对生态系统的控制从平台向应用转移，这给我们重要的启示，我们可以通过应用开发的控制来界入生态系统。要利用现有的生态系统，最直接的方式是兼容Android应用，此外我们还可以利用跨平台HTML5技术，支持HTML5应用，通过降低开发工作量和扩大适配设备提升用户量来吸引开发者，Firefox OS，Windows Phone 8、黑莓10采用了这条策略。目前HTML5还没有向原生操作系统那样出现寡头，它作为一种跨平台技术也尚未发展为成熟的系统平台，相关的生态链正在构建过程中，正是切入的好机遇。

 

相关链接：我的产业生态链和杂谈文章