一年一度的 Google I/O 已落下帷幕，没有了炫目的 Google Glass，没有了惊艳的 Material Design，连任何新硬件都没有提到，今年的 Keynote 似乎乏善可陈，甚至对大洋彼岸熬夜观看的人们来说，简直让人昏昏欲睡。但 Sundai Pichai 时代的 Google，就如同 Cook 治下的 Apple，少了些极客小清新，多了几分彰显的野心。以 Android 来看，今年的 Google I/O，更像是一份胡萝卜加大棒的宣言。
1. Android M
『M』，在 Google 的介绍中，是一个致力于深度完善用户体验的版本，完成了许多用户期待已久的优化。从 Google I/O 的介绍及发布的 Developer Preview 版来看，此言非虚。隐私（权限）控制、后台限制、更多的定制设置，这些过去在第三方ROM以及国产手机中流行的元素，如今已被 AOSP (Android Open Source Project) 正式收编。
除了不断修缮的 AOSP，Android M 花大力气强化的方向是 Android 与 Google 服务的深度集成。Now-on-Tap 和 App Linking 合力打造了 Google Now 与第三方 App 深度互通的机制，GCM 在 Doze Mode 和 App Standby 的联合绞杀下成为唯一可用的『州官』Push 通道。在奠定了语音交互的支配地位之后，Voice Actions + Voice Interactions 顺理成章的让 Google Now 进一步打入 App 内部。
从今年发布的 M 来看，AOSP 之上的改进大部分都成为 Google 掌控 Android 生态的抓手，令人喜忧参半。
2 Google的破局之势
2.1 Android 碎片化
长期以来，Android 在 iOS 的紧逼和第三方派生系统的冲击下，一直面临着一个沉重的历史难题 —— 碎片化。
具体而言，碎片化包含三个维度：版本碎片化、派生碎片化 和 体验碎片化。其中版本碎片化是最受用户诟病的，每年的 WWDC 上也会被例行挤兑一番。在这个问题上，由于 AOSP 的开源属性，Google 所能运用的策略非常有限，除了在手机预装 Google Apps 的认证协议中强制 OEM 厂商在新设备使用新版 Android 外，目前可以看到的其它手段都明显是在开放的道路上逆行渐远：
-
(1) 从 AOSP 中剥离内置应用及独立组件，代之以 Google 的闭源版本和可控的升级。独立组件的剥离是继内置应用之后，近两年来的明显趋势，比如 Location Provider、WebView、SSL。
-
(2) 以暂时性闭源及配套协议确保版本掌控力，如新兴的 Android Wear。
-
(3) 在部分领域撕开 OEM 的口子，直接掌控 OS 的升级，如『Android One』计划。
相比版本碎片化的用户伤害，『派生碎片化』明显更让 Google 更头疼，因为它们就像在开放的平川上脱缰的野马，不仅难以驾驭，而且还极易破坏整个Android生态。同时，派生碎片化还是导致版本碎片化不可忽略的一个重要因素。由于涉及到与 OEM 厂商间复杂的利益博弈，所以在这个问题上，Google 采取了典型的胡萝卜加大棒的策略。
前面几年，Google 一直推陈出新，高速迭代，导致 OEM 厂商跟进的步伐相当吃力，间接对派生的动作施加维护和并轨的压力。这是开源社区的传统做法，但现实中 OEM 厂商往往反其道而行，牺牲版本跟进以期将派生的投资收益最大化，这恰恰是 Google 最不愿看到的局面。
所以，这两年 Google 调整节奏，一方面将重心放在性能优化上（KitKat大幅降低内存消耗，Lollipop显著优化VM性能），抛出让 OEM 厂商垂涎的新版本；另一方面不断修缮 AOSP，收编第三方 ROM 及厂商定制的主流特性，持续削弱第三方 ROM 的核心吸引力，也给手机厂商的 ROM 深度定制给予一定的敲打。过去在Android 深度定制上投入巨大精力试图建立差异化的手机厂商都被证明难以取得商业上的成功，反倒是前 Google 系的 Motorola 在『浅度定制 + 硬件创新』上给其它 OEM 厂商照亮了一条（Google 推崇的）『明路』。
越来越完备的原生体验，让更多手机厂商也懒得在深度定制的泥潭里继续深陷，尤其是一些后来加入的搅局者（如锤子ROM、Oxygen OS），更多关注于上层应用和UI体验的差异化，也就将碎片化的第三个典型维度 —— 体验碎片化，推到了冲突的前沿。
针对UI体验的碎片化，去年 Google I/O 上惊艳发布的 Material Design 再下一城，在 UI 深度定制上将了 OEM 一军。通过营造轰动效应确立 Material Design 的主导地位，通过不断强调 App 的设计元素博取设计师的青睐，再提供高度简化开发的 AppCompat 支持库拉拢开发者，从而调动起整个生态的力量，让定制 UI 陷入了口诛笔伐的包围圈中。（中国除外，后面将详述）在如此强大的攻势之下，三星、HTC 等巨头纷纷收缩定制的战线，回归原生 UI 体验。
今年的 Google I/O 更是百尺竿头，发布了 Design Support Library，进一步掌控 Material Design 在第三方 App 中的表现，将任何碎片化的苗头都孤立在萌芽之中。
通过K、L、M三个版本分别打透性能、视觉和体验，在一定程度上遏制住了 Android 继续碎片化的趋势，再通过 Wear、TV、Auto 及 IoT 等崭新领域中的支配优势对 Android 平台施加强势控制，进一步奠定了破局之势。
2.2 设备体验的质变
在积极应对以 OEM 为主的产业生态之外，Google 在 Android M 里终于真正严肃的开始着手解决 App 生态中那些长期为人诟病的问题。终于向 iOS 看齐的设计，除了大家津津乐道的『运行期权限』外，还有 App 的后台运行限制。iOS 从不支持后台执行起步，在 4.0 开始向 App 开放非常有限的后台运行能力，在而后的几个版本中稍微放宽了后台条件，直到 iOS 7 引入面向所有 App 可用的后台更新机制。而 Android 从诞生时的完全开放后台运行，4.4 才开始对定时任务进行有限的对齐优化，5.0 引入 JobScheduler （类似iOS 7 的后台更新机制），直到此次 M 推出 Doze Mode 和 App Standby。Android 和 iOS 终于从两个不同的起点殊途同归。
Doze Mode 和 App Standby 对 Android 生态注定将有深远的影响，无论是对用户，还是开发者。在去年的 Lollipop 中，Google 公布了 Project Volta，一个看似雄心勃勃的耗电优化项目，但其具体做法却凸显 Google 式的天真。提供一个仅限最新版本才能使用的 API (JobScheduler)，而且还没有相应的版本兼容支持库，有几个闲的蛋疼的开发者会为一年下来才占据 10% 份额的 Android 新版本去做辛苦的额外适配？更何况用户实际很难察觉这一收益。这个想法的靠谱程度甚至连 KitKat 中的定时器对齐优化都不如，后者至少在 App 开发针对的 Android 版本（targetSdkVersion）高于 4.4 时就自动生效，不需要代码修改。
Android M 没有高调的 Project XXX，但却一改过去的天真，第一次采取了真正具有约束和震慑力的做法：无视 App 开发针对的 Android 版本，对全部后台行为进行强行限制，包括定时任务、网络访问能力、CPU唤醒维持、后台任务、同步任务。总之，一旦进入 Doze Mode 或是 Standby，在后台就啥也别想干了，除了充电期间和系统管控的定期『放风』。
2.3 Android M 确立的 App 生存法则
在如此霸道的后台限制面前，需要实时推送的 App 怎么办？Google 相当霸道给出了唯一的选择 —— GCM。自建推送通道和第三方推送通道在 Google 主导的 Android 生态中将彻底没有容身之所，是不是很有 iOS 之风？
除了实时推送，App 的其它后台执行诉求，在 Android M 时代，应当如何应对呢？典型的后台运行需求，可以分为两大类 ——『条件驱动的事务』和『非实时的更新同步』，前者又可细分为『云端驱动』和『终端驱动』。
云端驱动的后台任务，比如实时性敏感的数据同步，可以运用静默推送作为信号，驱动后台任务的执行。在 Android M 之后，推送信号亦有优先级之分，只有高优先级的推送信号才能在 Doze Mode 下实时送达手机，并给予 App 一小段时间完成后台任务。
终端驱动的后台任务，比如各类系统事件，在Doze Mode下仍然能得到后台运行，但无法访问网络，也仅限于 Receiver 的执行时限，因为 WakeLock 会被无视。而另一大类终端驱动的后台任务属于情景感知（Context-aware），典型的触发源是传感器及Google提供的位置和行为感知服务（Activity Recognition）。从目前所能获得的信息来看，它们在 Developer Preview 版中暂时还免于限制。
从设备体验的角度，后台限制是解决设备耗电问题最行之有效的策略，而共享的唯一推送通道则是理论上最省电的推送解决方案。Google 以设备体验的名义控制和垄断 Android 生态的关键基础设施，对开发者和用户而言，到底是福是祸？
3. Android 生态
3.1 后 AOSP 时代的 Android
Android 诞生之初，是由一个开源项目 AOSP（Android Open Source Project）+ 产业联盟 OHA（Open Handset Alliance）共同组成，前者以完全开放的姿态，允许整个社区自由使用 Android 源码，而后者则是 Google 主导的一个 OEM 联盟，受到商业协议的约束，获得 Google 的直接支持。
AOSP 虽然开源，但并未放开对项目的掌控，也至始至终没有非常开放的拥抱社区的参与和贡献。从 3.0 开始，每一个 Android 大版本的代码都有一段长达数月的内部保护期，而后才开放给外部。这两个因素的叠加，使得从社区向 AOSP 的贡献并不那么顺畅，从而变相的鼓励了 fork 的独立发展。早期的这种开放状况，一方面是保证快速迭代发展的必然结果（想想 Symbian 开源后的悲剧），另一方面也释放了 OEM 的潜能，促成了 Android 设备生态的快速樊荣。
但是没有约束力的开放最终也深深的伤害了整个 Android 生态，直接造成了如今的碎片化局面，因而 Google 别无选择的走向了加强控制这条道路。除了 OHA 之外，Google 还打造了与 OEM 深度合作的 Nexus 模式、基于标准化基础硬件的 Android One、疑似夭折的 Android Silver 计划，不断加深与 OEM 厂商的战略合作关系，特别是与三星之间貌合神离的关系。
在另一个战场，对 App 生态的掌控上，Google 则相对得心应手很多。一方面大力打造 Google Play services，以开发便利性为胡萝卜，再辅以 AOSP 逐渐收紧的 App 控制力作为大棒，大量的中小开发者几乎完全没有招架之力。过去尚有 iOS 的领先优势有所牵制，如今已鲜有能让 Google 心存顾忌的制衡力量了。
未来摆在整个 Android 生态面前的一道复杂课题就是『控制与开放的平衡』，它不仅是 Google 的难题，也是每一个生态参与者的共同命题。
3.2 App 生态圈的自我救赎
面对 Google 不断收紧的控制，作为弱势方的 App 开发者，表面上可以享用到 Google 服务带来的开发便利性，但长远来说，则是在削弱竞争，助长垄断，放弃自由。
起初他们打压Android派生系统时，我没有出声，因为我讨厌碎片化。
接着他们统一Android UI风格时，我没有出声，因为我喜欢Material Design。
后来他们封杀第三方推送服务，我也没有出声，因为多个推送通道确实更耗电。
最后当他们开始限制第三方应用，已经没有人能站出来为我发声了……
这绝不是危言耸听。相信『Don't be evil』？别天真了。捆绑 Chrome 浏览器并力推『Chrome Custom Tabs』算不算 evil？对内置的自家 App 永久赦免后台运行限制算不算 evil？排它的接管 Android 定位服务并持续收集用户的位置和行为算不算 evil？这些当然都有一百个理由可以辩称不算 evil，但它们却实实在在的深刻伤害了这个生态中曾经满怀憧憬拥抱开放的 App 开发团队，比如 Mozilla Firefox。你可以不喜欢 Firefox 浏览器，但作为开发者，我们对 Mozilla 心怀尊敬。
当生态中那些 Google 产品和服务曾经的替代者和潜在的竞争者都被挤出后，我们所热爱并为之付出的 Android 生态将不复开放。想想那些在 Apple 的审查大棒之下心生惴惴的 iOS 开发者，每年在 WWDC 前夕默默祈祷 Apple 不要发布一个同类产品的 App 团队。这些都是身为 Android 开发者常常庆幸的，但这种自由与开放只有依靠整个社区的不懈努力甚至斗争才能维系。面对 Google 的咄咄逼人，我们还能如何招架？
既然 Google 希望打造一个以大 G 为中心的星型生态，那么整个社区就应该团结起来，彼此搭肩，构筑一个网状生态。这就需要我们以更开放的心态和行动加强 App 之间的互操作性，在 Android & Google SDK 之外延伸出一个由 App 的开放协同所定义的 Open API，因为 Android 的核心架构就是建立在可替换的互操作组件之上，这也是 Android 系统独特的魅力所在。只有依靠社区力量促成的开放协同与优胜劣汰，才不受一家的意志掌控。
『ROOT』则是 Android 生态中另一个突显自由与平等精神的载体，它破除了 Google 在 AOSP 上设下的 Google 自有组件凌驾于第三方 App 之上的不平等地位（如系统签名级别的权限），让社区的力量可以深入 Android 平台，释放一个开源系统应有的灵活度与想象力。在略显 Geek 的 ROOT 之外，以 CyanogenMod 为代表的社区力量也在重新塑造 AOSP 的开放边界，提供长期被 Google 忽视的 API 和能力，为 App 开发注入更多活力。
一边是开放的自由，另一边是碎片化的深渊，如何才能临渊而行不跌入深渊？这是需要每一个生态中的角色都认真思考的问题。真正的开放绝不是另立标准或破坏兼容，那只是打着开放的幌子想要筑高商业利益的围墙。
3.3 Android的中国国情
Android 生态中的众多问题，无论碎片化，还是封闭的高墙，都在中国格外凸显，生态的任何问题都在这里得到充分放大。这里既是一个 Google 的控制力无法轻易触达的原始丛林，又是一个山头林立、巨头虎视的激战沙场。
过去，这个蛮荒生长的复杂生态一直是 App 开发者的噩梦。好不容易兼容了 MIUI，又要面对 Smartbar 的适配；考虑到了权限限制的交互提示，又可能掉进自启动屏蔽的坑里。但在熬过了各种不易之后，才蓦然发现，原来中国才是整个 Android 开放生态真正的试金石。Android M 中的很多改进优化，从权限控制到后台限制，似乎都在有意无意的填补『中国现象』所暴露出的突出问题，弥合不同 OEM 厂商的独立实现，甚至可以说是受到国内主流 ROM 的影响。而 Google 服务难以入华的大背景，又反过来制约着 Google 不得不继续保持 AOSP 与 Google 服务的相对独立性。Android Wear 这个强绑了 Google 服务的封闭平台，就面临无法打入中国市场的尴尬，催生了国内众多的『刷表』团队。
随着 Android 针对国内生态中突出问题的不断修缮，随着国内一线 OEM 厂商对 CTS 的真正重视，碎片化已然朝着一个不断减弱的良性趋势在发展。不远的将来，在经历了 Android M 的成熟之后，中国或许将会在牵制 Google 对 Android 的控制力和促成更加开放的 Android生态上发挥更为正面的积极作用，这可能是大家都没有想到的中国对于 Android 开放生态的特殊贡献。
作者
冯森林（花名：无锋），阿里资深无线技术专家，有10年的智能手机软件开发经验（从早期的Symbian到今天的Android、iOS），3年的通信设备核心网软件架构经验，3年的大规模分布式系统架构经验。对不同体系环境（通信设备、分布式后端系统、客户端）和不同团队结构下对架构设计的不同诉求与不变理念有着深刻的理解。在工作之外，还积极在技术社区中大力推广普及很少被业界重视的Android『设备体验』，多次分享了设备体验的影响、优化及最佳实践，致力于改善整个Android开发生态对设备体验，尤其是后台耗电及全局性能的重视程度。
