谷歌努力了这么久，Android碎片化还是无力回天

2024-11-05 发布

生态碎片化这件事，早在十年多前就已经在Android社区内被广泛讨论。而在这十年来，作为Android生态的掌舵人，谷歌对这一问题的态度，也从漠不关心、无能为力，转为了正视现实、积极进取。那么到了2023年，Android生态的碎片化问题得到解决了吗？非常遗憾的是，至今为止，Android生态可谓是“碎了一地，且很难破镜重圆”。

日前，谷歌方面通过AndroidStudio公布了截止今年3月，Android各版本的具体占比。其中显示，当前保有量最大的是占比为23.5%的AndroidR（11），位居次席的则是占比18.5%的AndroidQ（10），而AndroidS（12）、AndroidP（9）和AndroidT（13）则分列三四五位，但2017年的AndroidO（8）和2016年的AndroidN（7）还分别占据着6.7%和3.3%的比例。

显而易见，直都2023年，碎片化这一老生常谈的问题依然是摆在Android生态面前的一座大山。那么问题就来了，Android的碎片化为什么会成为一个问题，谷歌为什么非要解决它不可呢？

随便隔壁苹果的iOS由于闭源生态的缘故，可以通过将老版本验证关闭来阻止用户回滚，可为何PC端的Windows就没有受到如此严重的碎片化问题困扰呢？

事实上，Android之所以因为“碎片化”饱受诟病，是因为这一现状给开发者增加了不少开发上的成本和麻烦。而Windows的环境则更强调“窗口”这个概念，每个程序也都被视为是在独立的窗口中，因而应用的分辨率不必与屏幕分辨率保持一致。然而Android根植于移动端，“窗口”的概念被极大弱化，除了弹出对话框和通知外，应用基本都是全屏运行的，即Android设备的分辨率和应用的分辨率高度捆绑。

因此在设计应用界面时，开发者和UI设计师需要根据不同的分辨率，来调整界面中各个控件的位置、间距、大小等。尽管Android针对“碎片化”问题为应用的适配提供了不少解决方案，但还是给开发者带来了不小的工作量。再加上Android系统版本的迭代实质上是不停叠加功能的一个过程，碎片化导致开发者为了照顾存量用户，往往很难在应用中使用新的技术。

在解决了编译器、虚拟机等，更影响Android使用的问题后，此前在Android8时代，谷歌将弥合Android生态作为了头等大事，并带来了ProjectTreble机制。而ProjectTreble则将“系统层”和“驱动层”拆分，解除了驱动与系统版本的强绑定，并允许芯片厂商推出长期兼容未来新版本的驱动，并且确保它能在后续新的Android版本中无需修改也能正常使用。

然而理想很丰满、现实很骨感，即便后来问世的Android手机确实都支持ProjectTreble，可由于整个Android生态的历史欠账问题，使得手机厂商对于老机型的改造兴趣缺缺。此前一加的工程师更是曾在论坛中直白的指出，厂商对跟进ProjectTreble没兴趣的难点，是Android7以及更早的老机型需要修改底层分区才能适配ProjectTreble机制。

在Android7之前，谷歌没有强制要求手机厂商在打造自家ROM时进行分区，这就使得厂商的私有文件和Android系统文件混在了一起。而一台手机想要支持ProjectTreble就需要在底层增加一个分区，将system和vendor这两个分区的相关镜像分开，便于能方便的更新和升级system，并且不依赖vendor等底层。

如果手机厂商想要让老机型支持ProjectTreble，就需要通过OTA的方式对于分区进行重划。但在这一过程中，手机存储的数据会被直接抹掉，并且这种对于手机“大脑”进行的手术稍有闪失，就可能会出现“脑死亡”、让设备直接变砖。而老机型没有ProjectTreble，谷歌想要快速部署新版系统的通道也就不复存在了。

ProjectTreble除了在实际操作层面面临技术和用户体验方面的难题外，这一机制本身则是一整套符合Android开发规范，但会随着每次新版本系统的推出，而不断添加新特性的动态体系。可这一“动态”，就让手机厂商颇为头疼了。

原来的情况，是谷歌老师画一幅画，下面的手机厂商通过临摹再添加点细节后，自己的ROM就出炉了。现在则是谷歌从.jpg变成了.gif，稍有一点变化就会出现连锁反应，最后就导致手机厂商的工作量成倍提升。

手机厂商对ProjectTreble不感兴趣，谷歌当然也看在眼里。为了避免ProjectTreble成为“上有政策下有对策”的牺牲品，在Android9推出时，谷歌方面就要求所有预装Android9的机型都必须支持ProjectTreble框架，并且手机厂商需要在至少2年的时间内，为旗下的主要手机和平板电脑产品定期更新系统。同时还邀请了更多的手机厂商参与新版系统的早期测试，让后者能够提早熟悉新版系统。

必须要承认的是，谷歌的这一操作是有一定效果的，自AndroidP以来推出的机型确实也都获得了更长的维护周期，而且手机厂商加入Android新版系统的前期阶段，也确实让Android的易用性得以大幅提升。

到了Android10时代，谷歌则引入了ProjectMainline、将系统功能模块化，并把Android的12个核心组件，也就是媒体编解码器、Conscrypt、权限控制器、模块元数据等模块化。事实上，高通骁龙Adreno以及ARMMaliGPU能够将GPU驱动单独在GooglePlay更新，就是得益于这一设计。

后续更具有里程碑意义的变化，则出现在Android11上，谷歌开始对Android的Linux内核动刀了，并试图将Android的内核统一至Linux内核主线。而Linux内核对于Android而言无疑是大厦的基石，Linux内核的升级也会获得BUG和漏洞修复带来的安全性、新的硬件驱动、新特性，以及效率的提升。然而，运行在Android设备上的内核其实与谷歌选择的LTS（长期支持）版本Linux内核，有很大的不同。

所以最终的结果，就是Android设备使用的内核相较Linux内核主线，要滞后两到三年的时间。在Android11中，谷歌将系统内核进行了模块化修改，内核被分成了通用内核镜像（GenericKernelImage,GKI）和其他GKI模块，特定硬件的驱动程序（可能是闭源驱动）则作为内核模块加载，从而提供了一个稳定的写入接口，使得硬件供应商能够轻松的插入代码，并最终消除特定的设备内核。

为了确保新版Android系统能无限拉近与主流Linux的距离，在LinuxPlumbers大会（LPC2021）上，谷歌软件工程师、知名Linux内核技术大牛ToddKjos还宣布，未来Android内核开发将转向上游优先（Upstreamfirst）策略，并正在努力让所有新品的内核都基于AndroidGenericKernelImage(通用内核镜像)，确保新的代码首先进入Linux内核Mainline，而不是直接在Android源码树中寻找宿主。

那么问题来了，谷歌做出如此多的努力后，为什么最终仍改变不了Android的碎片化问题呢？此时的根源，其实就是Android的开放。

从某种意义上来说，wintel联盟主导的Windows生态和苹果控制的iOS生态，其实都是强干弱枝的中央集权模式。Android则是典型强枝弱干的联邦模式，而强枝弱干的顶层设计也是开放手机联盟得以建立的基础。

既然都已经是强枝弱干了，Android的碎片化也就成为了必然，所以在许多业内人士看来，谷歌的努力或许也很难改变此事。