巨人的进击 — — Android生态的破与立

一年一度的Google I/O已落下帷幕,没有了炫目的Google Glass,没有了惊艳的Material Design,连任何新硬件都没有提到。2015年的Keynote似乎乏善可陈,甚至对大洋彼岸熬夜观看的人们来说简直昏昏欲睡。但Sundai Pichai时代的Google,就如同Tim Cook治下的苹果,少了些极客小清新,多了几分彰显的野心。以Android来看,Google I/O 2015更像是一份胡萝卜加大棒的宣言。

Android M

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内部。

从今年发布的Android M来看,AOSP之上的改进大部分都成为Google掌控Android生态的抓手,令人喜忧参半。

Google的破局之势

【Android碎片化】

长期以来,Android在iOS的紧逼和第三方派生系统的冲击下,一直面临着一个沉重的历史难题 — — 碎片化(如图1所示)。

具体而言,碎片化包含三个维度:版本碎片化、派生碎片化和体验碎片化。其中版本碎片化最受用户诟病,每年WWDC上也被例行一番挤兑。在这个问题上,由于AOSP的开源属性,Google所能运用的策略非常有限,除了在手机预装Google Apps的认证协议中强制OEM厂商在新设备使用新版Android外,目前可以看到的其它手段都明显是在开放的道路上逆行渐远:

从AOSP中剥离内置应用及独立组件,代之以Google的闭源版本和可控的升级。独立组件的剥离是继内置应用之后近两年来的明显趋势,比如Location Provider、WebView、SSL;

以暂时性闭源及配套协议确保版本掌控力,如新兴的Android Wear;

在部分领域撕开OEM的口子,直接掌控OS的升级,如“Android One”计划。

相比版本碎片化的用户伤害,“派生碎片化”明显让Google更头疼,因为它们就像在开放的平川上脱缰的野马,不仅难以驾驭,而且还极易破坏整个Android生态。同时,派生碎片化还是导致版本碎片化不可忽略的一个重要因素。由于涉及到与OEM厂商间复杂的利益博弈,所以在这个问题上,Google采取了典型的胡萝卜加大棒的策略。

前几年,Google一直推陈出新,高速迭代,导致OEM厂商跟进的步伐相当吃力,间接对派生的动作施加维护和并轨的压力。这是开源社区的传统做法,但现实中OEM厂商往往反其道而行,牺牲版本跟进以期将派生的投资收益最大化,这恰恰是Google最不愿看到的局面。

所以,这两年Google调整节奏,一方面将重心放在性能优化上(KitKat大幅降低内存消耗,Lollipop显著优化VM性能),抛出让OEM厂商垂涎的新版本;另一方面不断修缮AOSP,收编第三方ROM及厂商定制的主流特性,持续削弱第三方ROM的核心吸引力,也给手机厂商的ROM深度定制给予一定的敲打。过去在Android深度定制上投入巨大精力试图建立差异化的手机厂商都被证明难以取得商业上的成功,反倒是前Google系的摩托罗拉在“浅度定制+硬件创新”上给其它OEM厂商指了一条(Google推崇的)“明路”。

越来越完备的原生体验,让更多手机厂商也懒得在深度定制的泥潭里继续深陷,尤其是一些后来加入的搅局者(如锤子ROM、Oxygen OS),更多关注于上层应用和UI体验的差异化,也就将碎片化的第三个典型维度 — — 体验碎片化,推到了冲突的前沿。

针对UI体验的碎片化,2014年Google I/O惊艳发布的Material Design再下一城,在UI深度定制上将了OEM一军。通过营造轰动效应确立Material Design的主导地位,通过不断强调App的设计元素博取设计师的青睐,再提供高度简化开发的AppCompat支持库拉拢开发者,从而调动起整个生态的力量,让定制UI陷入了口诛笔伐的包围圈中(中国除外)。在如此强大的攻势之下,三星、HTC等巨头纷纷收缩定制的战线,回归原生UI体验。

本届Google I/O更是百尺竿头,发布了Design Support Library,进一步掌控Material Design在第三方App中的表现,将任何碎片化的苗头都孤立在萌芽之中。通过三个新版本分别打通性能、视觉和体验,在一定程度上遏制Android继续碎片化的趋势,再通过Wear、TV、Auto及IoT等崭新领域中的支配优势对Android平台施加强势控制,进一步奠定破局之势。

【设备体验的质变】

在积极应对以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生态注定将有深远的影响,在2014年的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,在后台就啥也别想干了,除了充电期间和系统管控的定期“放风”。

【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生态的关键基础设施,对开发者和用户而言,到底是福是祸?

Android生态

【后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的难题,也是每一个生态参与者的共同命题。

【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生态将不复开放。想想那些在苹果的审查大棒之下心生惴惴的iOS开发者,每年在WWDC前夕默默祈祷苹果不要发布一个同类产品的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开发注入更多活力。一边是开放的自由,另一边是碎片化的深渊,如何才能临渊而行不跌入深渊?这是需要每一个生态中的角色都认真思考的问题。真正的开放绝不是另立标准或破坏兼容,那只是打着开放的幌子想要筑高商业利益的围墙。

Android的中国国情

Android生态中的众多问题,无论碎片化还是封闭的高墙,都在中国格外凸显,生态的任何问题都在这里得到充分放大。这里既是一个Google控制力无法轻易触达的原始丛林,又是一个山头林立、巨头虎视的激战沙场。

过去,这个蛮荒生长的复杂生态一直是App开发者的噩梦。好不容易兼容了MIUI,又要面对Smartbar的适配;考虑到权限限制的交互提示,又可能掉进自启动屏蔽的坑里。但熬过各种不易之后,才蓦然发现,原来中国才是整个Android开放生态真正的试金石。Android M中的很多改进优化,从权限控制到后台限制似乎都在有意无意的填补“中国现象”所暴露的突出问题,弥合不同OEM厂商的独立实现,甚至可以说是受到国内主流ROM的影响。而Google服务难以入华的大背景,又反过来制约着Google不得不继续保持AOSP与Google服务的相对独立性。Android Wear这个强绑了Google服务的封闭平台,就面临无法打入中国市场的尴尬,催生了国内众多的“刷表”团队。

随着Android针对国内生态中突出问题的不断修缮,以及国内一线OEM厂商对CTS(Compatibility Test Suite)的真正重视,碎片化已然朝着一个不断减弱的良性趋势在发展。不远的将来,经历Android M的成人礼后,中国或许将会在牵制Google对Android的控制力和促成更加开放的Android生态上发挥更为正面的积极作用,这可能是大家都没有想到的,中国对于Android开放生态的特殊贡献。