Android 的四种用法(只有一种是正确的) 对于手机厂来说，采用 Android 系统的方式一共有四种。 第一种就是 Google 希望各家采用的方式：同时使用 AOPS 和 GMS。提交通过测试，装载全部 Google 的服务和应用套件。这就是三星，HTC 和 LG 采用的方式。这条道路还是给手机厂留下了一些自定义的空间。OEM 厂可以在 Google 应用以外，装载自己的相同的应用。但貌似 Google 对各厂在这点空间搞的花头也不满意了，有报道说 Google 和三星谈判，三星同意减少在手机界面上的各种奇葩修改，特别是移除与 Google 应用重复的其他应用。 这种方式因为提供了完整的 AOPS 和 GMS 的 API， 也就保证了最佳的软件兼容性。同时也最大程度地保证了 Android 系统的用户体验，不管各厂怎么折腾界面，Google 的软件总是存在的，用户体验总是一致的。 这让 Google 也最大程度地保持自己对 Android 系统的控制力，而且这种控制力只会与日俱增。每一次新版本 Android 的发布，Google 就会把更多的 API 弄到 GMS 套件里去，慢慢把 AOSP 上的肉一点点剃掉，只剩一个底层的骨架。 第二种极端做法，整个移除 GMS 服务包，基于 AOSP 开发一些粗制滥造的替代品。当然，这样做的结果，就是用户得到的体验会差很多，所谓能用就行了。在一些低端机上，很多厂家就是这么干的，特别是在中国市场。只要你敢用，厂家提供了自己的软件市场和各种替代软件，填平 Google 软件缺失所留下的空隙，但这些产品和采用 GMS 套件的手机比起来，在水准上要低很多，这些手机不兼容很多基于 GMS 开发的软件，而且数量不少，比如很多软件依赖 GMS 的内购功能。 第三种做法介于第一种和第二种之间：发布基于AOSP的设备，但是开发与 GMS 一样的 API 以保证兼容性，比如GPS和地图服务，但是基于微软而不是 Google 的。很少有厂家选择这条道路，最接近这种做法的只有 Amazon，它们提供了 GMS API 的替代方案(特别是地图服务)，但完全没法跟上 Google 的开发迭代速度。 是从技术上说，如果一家公司足够土豪心，豹子胆，完全开发出自己的 API, 整个端掉 GMS，这代价也绝对没法让人淡定。特别是为了保证兼容性，这活不光是提供与 GMS 想通的功能，还包括提供和 GMS 提供的开发框架和开发者工具。 另外，GMS 还有一些无法替代的东西，比如「Google+ 分享」，很少有公司能提供能与之匹敌的替代方案。又比如，GMS里有一个 API 提供了多人回合游戏功能，虽然厂家可以提供自己的API，并建设自己的后台硬件支持回合制游戏服务，但显然这完全脱离 GMS 的做法，无法让游戏开发者接受。 更不要说这么大费周章搞掉 GMS，定是不小心忘了 Google 和 Oracle 之间关于这些 API 的漫长的专利官司。事实上，能做出这样事情的厂家，不可能不引起 Google 法务部门的疯狂点赞。Google有钱啊，如果他愿意，法庭当茶馆，慢慢和你谈。 除了以上三条路以外，总有狠人能比划出第四条道路：只用 AOSP 的最基础的功能，比如硬件支持层、通讯模块什么的，余下的全部推墙揭瓦，自己开发……但这相当于又把 Android 从头开发了一遍。Amazon 的自有API 可以归入这种「猛人」行列，提供了功能一样，但是实现了与 GMS 完全不兼容的 API。我想不太会有厂家能做出 Amazon 这种事情。虽然还有像 Ubuntu for Android 这种怪东西，但那只是精神可嘉。 嘛？ C.O.S. 比这还猛？但是这货比划的实在太猛了，我连呵呵都不敢。 兼容性与控制权，鱼和熊掌不可兼得 以上四种途径中，第一种 AOSP 加 GMS 的做法是唯一能提供完整 Android 体验的方法，并能保证开发者不会有任何别扭的地方，也是唯一能兼容所有Andoid第三方应用的途径。但显然，这种做法不是微软能接受的，这等于帮 Google 做硬件，让 Google 唱戏，而且这一唱就没有翻身之日了。 第二种 —— 在 AOSP 的基础上提供一些替代应用，这可以让微软在 Android 上集成自己的服务。这样虽然能支持不少 Android 应用，但能支持多少并不确定。但至少肯定没法支持像 植物大战僵尸2，愤怒的小鸟这些依赖 GMS，并且有大量内购利润的大牌应用，但如果这部手机就是设计来主要使用内置应用就行的(比如相机，浏览器，邮件客户端)，那丢掉些兼容性也无大碍。 NOKIA 传说中在开发的 Android 手机可能就是以这种方式实现：AOSP作为底层，上面全是诺基亚自己的服务。 这种做法可能只适合于对软件兼容性要求不高的低端市场，能不能打正版僵尸无所谓的超低价手机，也是很多中国厂家采用的方案。但是对于微软来说，这完全搞错了方向：这家公司已经有了一个不能支持许多高大上赚钱应用的鸡肋系统，干嘛还要再搞一个？！ 而且，能想象这种 Android 手机的用户体验有多差。Google 已经把众多核心功能迁移到 GMS 框架内，比如短信和 Chrome 浏览器。AOSP 是一个多bug、老旧，基本上不会再有后续维护的框架。想要抛开 GMS 从 AOSP 开始重起炉灶，开发出同等用户体验的系统，那前面就是两万五千里长征在欢迎你。因为 Android 开源的部分很差。
Amazon 的 Kindle Fire 就是一个例子告诉你从 AOSP 平地起楼有多难。Kindle Fire 不支持最新最酷的游戏，因为开发者没兴趣去同时维护一个不依赖 GMS 框架的产品线，虽然两者之间看上去很像。Windows Phone 所遇到的问题，换了 Android 也完全没有解决。只能带上 GMS 才能玩得开。 第三条道路，就是在 AOSP 的基础上，从头开发与 GMS 完全兼容的接口——或许可以解决这个问题，但这也把做 Android 分支的工作量放大到极大。但如果能做到完全提供与 GMS 一样的接口，开发者和用户的体验，以及那些只基于 AOSP 的程序的兼容性都可以得到保证。 但这个工作量……打个比方，大概和把 Windows Phone 的壳和 API 全部套在桌面版的 Windows 系统一样。某种程度上，这个工作量可能会更大，比如在 AOSP 上重新开发一遍 IE 浏览器。 更重要的是，Google 还是把着上游控制权，因为 Android 系统的表现，完全是基于底层 API 提供的功能的：比如「分享到」功能，完全是 Android 自己的方法和风格，而这都是由 Google 决定的，这就限制了下游开发者无法反驳 Google 的选择。 最后一个 —— 除了 AOSP，其他全部推翻重来。自由度和灵活度都有了，然后呢？内核其实根本不重要好不好，不就是个内核么！微软已经有了一个手机系统的内核了，在 Window Phone 8 用的好好的。很明显，对微软来说，抛弃整个 Windows Phone 系统不是说连这内核都能不要了。这已经是一个为微软量身打造的手机系统内核，没道理用别人的。而且内核真的不是整件事情最难的部分。 |
