生态碎片化这件事,早在十年多前就已经在Android社区内被广泛讨论。而在这十年来,作为Android生态的掌舵人,谷歌对这一问题的态度,也从漠不关心、无能为力,转为了正视现实、积极进取。那么到了2023年,Android生态的碎片化问题得到解决了吗?非常遗憾的是,至今为止,Android生态可谓是“碎了一地,且很难破镜重圆”。
日前,谷歌方面通过Android Studio公布了截止今年3月,Android各版本的具体占比。其中显示,当前保有量最大的是占比为23.5%的Android R(11),位居次席的则是占比18.5%的Android Q(10),而Android S(12)、Android P(9)和Android T(13)则分列三四五位,但2017年的Android O(8)和2016年的Android N(7)还分别占据着6.7%和3.3%的比例。
显而易见,直都2023年,碎片化这一老生常谈的问题依然是摆在Android生态面前的一座大山。那么问题就来了,Android的碎片化为什么会成为一个问题,谷歌为什么非要解决它不可呢?
随便隔壁苹果的iOS由于闭源生态的缘故,可以通过将老版本验证关闭来阻止用户回滚,可为何PC端的Windows就没有受到如此严重的碎片化问题困扰呢?
事实上,Android之所以因为“碎片化”饱受诟病,是因为这一现状给开发者增加了不少开发上的成本和麻烦。而Windows的环境则更强调“窗口”这个概念,每个程序也都被视为是在独立的窗口中,因而应用的分辨率不必与屏幕分辨率保持一致。然而Android根植于移动端,“窗口”的概念被极大弱化,除了弹出对话框和通知外,应用基本都是全屏运行的,即Android设备的分辨率和应用的分辨率高度捆绑。
因此在设计应用界面时,开发者和UI设计师需要根据不同的分辨率,来调整界面中各个控件的位置、间距、大小等。尽管Android针对“碎片化”问题为应用的适配提供了不少解决方案,但还是给开发者带来了不小的工作量。再加上Android系统版本的迭代实质上是不停叠加功能的一个过程,碎片化导致开发者为了照顾存量用户,往往很难在应用中使用新的技术。
在解决了编译器、虚拟机等,更影响Android使用的问题后,此前在Android 8时代,谷歌将弥合Android生态作为了头等大事,并带来了Project Treble机制。而Project Treble则将“系统层”和“驱动层”拆分,解除了驱动与系统版本的强绑定,并允许芯片厂商推出长期兼容未来新版本的驱动,并且确保它能在后续新的Android版本中无需修改也能正常使用。
然而理想很丰满、现实很骨感,即便后来问世的Android手机确实都支持Project Treble,可由于整个Android生态的历史欠账问题,使得手机厂商对于老机型的改造兴趣缺缺。此前一加的工程师更是曾在论坛中直白的指出,厂商对跟进Project Treble没兴趣的难点,是Android 7以及更早的老机型需要修改底层分区才能适配Project Treble机制。
在Android 7之前,谷歌没有强制要求手机厂商在打造自家ROM时进行分区,这就使得厂商的私有文件和Android系统文件混在了一起。而一台手机想要支持Project Treble就需要在底层增加一个分区,将system和vendor这两个分区的相关镜像分开,便于能方便的更新和升级system,并且不依赖vendor等底层。
如果手机厂商想要让老机型支持Project Treble,就需要通过OTA的方式对于分区进行重划。但在这一过程中,手机存储的数据会被直接抹掉,并且这种对于手机“大脑”进行的手术稍有闪失,就可能会出现“脑死亡”、让设备直接变砖。而老机型没有Project Treble,谷歌想要快速部署新版系统的通道也就不复存在了。
Project Treble除了在实际操作层面面临技术和用户体验方面的难题外,这一机制本身则是一整套符合Android开发规范,但会随着每次新版本系统的推出,而不断添加新特性的动态体系。可这一“动态”,就让手机厂商颇为头疼了。
原来的情况,是谷歌老师画一幅画,下面的手机厂商通过临摹再添加点细节后,自己的ROM就出炉了。现在则是谷歌从.jpg变成了.gif,稍有一点变化就会出现连锁反应,最后就导致手机厂商的工作量成倍提升。
手机厂商对Project Treble不感兴趣,谷歌当然也看在眼里。为了避免Project Treble成为“上有政策下有对策”的牺牲品,在Android 9推出时,谷歌方面就要求所有预装Android 9的机型都必须支持Project Treble框架,并且手机厂商需要在至少2年的时间内,为旗下的主要手机和平板电脑产品定期更新系统。同时还邀请了更多的手机厂商参与新版系统的早期测试,让后者能够提早熟悉新版系统。
必须要承认的是,谷歌的这一操作是有一定效果的,自Android P以来推出的机型确实也都获得了更长的维护周期,而且手机厂商加入Android新版系统的前期阶段,也确实让Android的易用性得以大幅提升。
到了Android 10时代,谷歌则引入了Project Mainline、将系统功能模块化,并把Android的12个核心组件,也就是媒体编解码器、Conscrypt、权限控制器、模块元数据等模块化。事实上,高通骁龙Adreno以及ARM Mali GPU能够将GPU驱动单独在Google Play更新,就是得益于这一设计。
后续更具有里程碑意义的变化,则出现在Android 11上,谷歌开始对Android的Linux内核动刀了,并试图将Android的内核统一至Linux内核主线。而Linux内核对于Android而言无疑是大厦的基石,Linux内核的升级也会获得BUG和漏洞修复带来的安全性、新的硬件驱动、新特性,以及效率的提升。然而,运行在Android设备上的内核其实与谷歌选择的LTS(长期支持)版本Linux内核,有很大的不同。
所以最终的结果,就是Android设备使用的内核相较Linux内核主线,要滞后两到三年的时间。在Android 11中,谷歌将系统内核进行了模块化修改,内核被分成了通用内核镜像(Generic Kernel Image,GKI)和其他GKI模块,特定硬件的驱动程序(可能是闭源驱动)则作为内核模块加载,从而提供了一个稳定的写入接口,使得硬件供应商能够轻松的插入代码,并最终消除特定的设备内核。
为了确保新版Android系统能无限拉近与主流Linux的距离,在Linux Plumbers大会(LPC2021)上,谷歌软件工程师、知名Linux内核技术大牛Todd Kjos还宣布,未来Android内核开发将转向上游优先(Upstream first)策略,并正在努力让所有新品的内核都基于Android Generic Kernel Image (通用内核镜像) ,确保新的代码首先进入Linux内核Mainline,而不是直接在Android源码树中寻找宿主。
那么问题来了,谷歌做出如此多的努力后,为什么最终仍改变不了Android的碎片化问题呢?此时的根源,其实就是Android的开放。
从某种意义上来说,wintel联盟主导的Windows生态和苹果控制的iOS生态,其实都是强干弱枝的中央集权模式。Android则是典型强枝弱干的联邦模式,而强枝弱干的顶层设计也是开放手机联盟得以建立的基础。
既然都已经是强枝弱干了,Android的碎片化也就成为了必然,所以在许多业内人士看来,谷歌的努力或许也很难改变此事。
【以上内容转自“三易生活网”,不代表本网站观点。如需转载请取得三易生活网许可,如有侵权请联系删除。】
延伸阅读:
驱动中国2023-06-13 17:2306-13 17:23
驱动中国2023-06-13 17:2306-13 17:23
TOM2023-06-13 17:2206-13 17:22
TOM2023-06-13 17:1306-13 17:13
TOM2023-06-13 16:5506-13 16:55