首页分享 Android碎片化问题, Google把它解决了吗?了解什么是碎片化, 碎片化出现的原因, 以及碎片化为何不再重要.

Android碎片化问题, Google把它解决了吗?了解什么是碎片化, 碎片化出现的原因, 以及碎片化为何不再重要.

来源：花匠小妙招时间：2024-12-21 06:33

全面回顾一下Google为解决Android碎片化问题所做出的努力与尝试.

在 Android 13 中出现了一项名为Photo Picker的新功能. 它允许应用程序访问单个用户的照片和视频, 而不允许它们完全访问照片/视频或整个设备内存. 这是一个限制应用程序访问用户个人数据的好功能. 谷歌随即宣布该功能也适用于 Android 11 及更新版本(支持主线更新), 后来又通过 Google Play 服务将该功能添加到了所有 Android 4.4 及以上版本的设备上.

我立刻问自己, 为什么以前没有这样做呢? 答案很简单 -- Android系统不允许实现这一点, 因为谷歌当时正与碎片化问题作斗争, 并致力于实现Android系统独立更新的可能性, 以前不这样做才成为了现实.

在本文中, 我将与大家分享我对 Android 碎片化的看法. 你将了解到什么是碎片化, 碎片化出现的原因, 以及碎片化为何不再重要. 我还会告诉你在 Android 诞生的前 10 年里, 谷歌是如何解决这个问题的, 以及为什么更新版本的 Android 设备更新将不再像以前那么重要.

本文仅代表个人观点, 而且可能是有误的, 对此我乐意在评论中讨论.

Android操作系统简史

要了解操作系统开发人员面临的问题, 我们需要追溯历史. Android的历史始于 2004 年. Andy Rubin决定为当时非常流行的数码相机开发一款操作系统. 然而, 由于资金问题和数码相机市场规模相当小, 该系统被重新聚焦于智能手机, 成为塞班和 Windows Mobile 的竞争对手.

2005 年, 该公司被谷歌收购. 谷歌公司决定进军手机市场, 向设备制造商出售其操作系统. 2007 年, 开放手机联盟成立, 与此同时, Android 作为开源移动平台宣布推出.

Android设备的原型与黑莓智能手机相似: 没有触摸屏和 QWERTY 实体键盘. 简而言之, 就是黑莓. 2007 年, 第一代 iPhone 发布. 这款智能手机改变了智能手机和电脑市场, 至今仍引领着潮流. 谷歌参与了苹果首款智能手机软件的准备工作, 并很快意识到了风向, 于是匆忙开始重建Android系统.

Android智能手机的概念发生了巨大变化: 触摸屏和最少的物理按键. 第一款Android智能手机HTC Dream是谷歌最初的设备理念与苹果所引领的潮流的混合体. 全键盘隐藏在一个大尺寸(按当时的标准)触摸屏下.

第一版 Android 操作系统的任务很简单--在设备上启动并以某种方式运行. 由于资源有限, 开发人员决定使用现有的免费流行技术: Linux 内核, Java, OpenGL, FreeType 和 Skia. Linux 内核并不是原封不动的, 而是根据移动设备内存小, CPU 速度慢的特点进行了修改; 他们还开发了自己的 Java 虚拟机 Dalvik, 与标准的 JVM 不同, 考虑到了内存小, 处理器内核只有一个以及设备电池的使用情况.

要知道, 与 iOS 不同的是, Android 从第一个版本开始就为开发者开放了工具包, 在线应用商店 Android Market(现名为 Google Play)于 2008年10月22日(比 iOS 应用商店晚 4 个月)上线.

这整个复杂而艰难的过程影响了Android系统的功能和架构. 我认为这种情况经常发生在开发人员身上: 我们在创建 MVP 时没有计划扩展, 然后新的需求来了, 最后期限快到了...在开发应用程序时遇到这种问题是一回事. 但当你在构建一个不能轻易更新的操作系统时, 问题就完全不同了.

Android 1.0 架构

我们还需要了解的是, 谷歌只开发操作系统, 而供应商则独立于公司对系统进行开发, 修改和更新. 在开发 Android 操作系统时, 谷歌将重点放在支持现代技术的触摸屏设备上. 有必要提高操作系统的速度, 为开发者和用户提供更多功能.

碎片化

碎片化是一个问题, 因为市场上有大量的设备运行在不同版本的操作系统上, 而且制造商还对其进行了不同的修改. 因此, 即使应用程序能在模拟器或某一设备上运行, 也不能保证它能在所有设备上正常运行.

这个问题导致开发人员需要花费更多的时间来开发, 调整和测试应用, 而且只能在用户最常用的设备上运行.

Android中的设备碎片化.

你可以看到 2014 年Android设备碎片化的可视化情况, 如今情况只会更糟. 新版本操作系统的适配也有待改进, 但在此之前, 情况更糟.

一方面, 碎片化是一种痛苦, 但另一方面, 它也为设备制造商的创新提供了巨大的机会和空间. 他们可以实现自己的功能, 创造独特的界面, 在众多产品中脱颖而出. 正因为如此, 我们看到了折叠式智能手机, 游戏手机, 电子墨水显示屏, 滑盖手机, 模块化手机和其他形式的手机.

如果你看一下 Windows Mobile 或 Windows Phone 上的智能手机, 它们在软件和外观上都是一样的. 这是因为微软不允许供应商修改操作系统. 诺基亚拥有这项权利, 但他们决定不使用它, 这样微软实现的用户体验就不会被打乱. 这些做法孰好孰坏, 我无权评判, 但时间已经证明 -- Android操作系统生机勃勃, 不仅是移动操作系统中最受欢迎的操作系统, 甚至是所有操作系统中最受欢迎的操作系统. 与此同时, Windows 移动版本的所有开发工作已于 2017 年结束, 2020 年结束支持.

厂商更新

碎片化的另一个原因是, 每个制造商都独立更新自己的设备, 这也是一个问题. 此外, 公司并不总是将新设备更新到最新版本的Android系统, 因为这会影响他们的主要目标(尽快卖出尽可能多的设备).

Android设备制造商无法快速更新他们的设备, 因为更新周期需要几个步骤: 公司需要从 AOSP 获取源代码和设备中微芯片的最新驱动程序, 然后将所有更改与公司的外壳合并; 之后, 公司需要将新版本操作系统的更改调整到他们的外壳中, 然后将所有更改发送到用户设备.

这个过程需要时间; 更新机型的排序是根据设备的新旧程度和价格原则完成的. 经济型机型根本没有更新, 因为制造商不提供支持. 还有一些情况是, 厂商发送了假补丁; 更新实际上已经到了, 但里面什么都没有. 这些更新可以被称为安慰剂, 因为有些用户认为它们能让设备更快, 更安全.

在这一点上, 谷歌似乎本应有所作为, 但在Android系统诞生之初, 他们要么做不到, 要么不敢向设备制造商施压. 不过, 在某些情况下, 谷歌不得不进行干预. 例如, 谷歌曾与宏达电(HTC)摊牌, 因为宏达电一开始根本不更新自己的设备, 无论价格高低.

Android Jetpack

新版本 Android SDK 的开发和设备更新缓慢导致市场上充斥着各种版本的 Android 设备. 对企业来说, 支持所有这些设备非常重要, 因此开发人员被赋予了一项任务. 代码中充斥着检查设备上 Android 版本的if...else语句.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { // CODE for Android 5.0 Lollipop and higher } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) { // CODE for Android 4.X } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { // CODE for Android 3.X } else { // CODE for all other Android versions supported by the application // (minSdk from AndroidManifest and higher) }

对于 Android SDK 中最流行的 API, 谷歌决定自己来做这件事, 推出了 Android 支持库, 后来又将其改革为 Android Jetpack, 也称为 AndroidX.

它包含许多不同的 Compat API, 允许应用程序在旧版本上调用新版本 Android 的 API. 在旧版本的操作系统上, 这通常会导致调用被直接忽略, 不过有些 API 调用会被重新调用到旧版本 Android SDK 中的类似程序.

下一个重要步骤是移植新的应用程序接口, 因为旧版本的 SDK 中没有类似的应用程序接口. 社区较早开始了这项工作; 例如, 让Jake Wharton成为传奇的最受欢迎的库之一--ActionBarSherlock. 该库是 AppCompat 的第一个版本, 并将 Action Bar 从 Android 3.0 移植到了 Android 2.X.

摩托罗拉 Xoom 是首款 Android Honeycomb 平板电脑

为什么是发烧友而不是谷歌? Android 3.0 的发布极大地改变了Android系统, 因为它是第一个正式支持平板电脑的操作系统, 也是谷歌历史上第一次没有开放Android系统的源代码.

这是因为谷歌担心将最新的平板电脑版Android系统移植到智能手机上. 在 Honeycomb 中, 推出了第一个 Holo 版本 -- 品牌化的Android设计, 这种设计一直沿用到 2014 年. 当 Android 5.0 和至今仍适用的 Material design 推出时, 它的第三个版本 Material You 也发布了.

Google Play Services用于分发功能

Android开源项目(AOSP) 是Android操作系统的空白版本, 在这里你找不到许多常用的应用程序和服务.

在三星, 谷歌, 小米和其他流行的Android智能手机制造商的设备上, 你能找到的是经过谷歌认证的带有谷歌移动服务的Android版本: Google Play 应用程序商店, Google 搜索, Chrome 浏览器, Google Play 服务以及其他默认的 Google 软件.

Google Play 服务是一个框架, 允许开发人员在其应用程序中使用谷歌的各种功能和服务. 该框架包括 Google 授权, 定位, Firebase 服务, 推送消息, 分析和其他服务等功能, 开发人员可以利用这些功能改进自己的应用程序. 没有 Google Play 服务, 你就无法运行 Google WearOS, 它通过专有服务提供设备间的数据传输以及 Android SDK 的一些功能.

Google Play 服务会接受常规的更新, 包括改进和错误修复.

公司的品牌服务允许你发布更新或提供跨所有操作系统版本的功能. 例如, 如果你正在学习如何获取用户的位置, 那么在官方文档中, 你会发现一份基于 Google Play 服务的Fused Location Provider而不是 Android SDK 的位置 API 的指南.

大多数 Android 设备上都安装了 Google Play 服务, 并通过 Google Play 商店自动更新. 无论设备制造商, 运营商和 Android 版本如何, 服务中的所有更新都会交付. 这一点很重要, 因为谷歌可以自行提供错误修复, 新功能和其他改进, 而不像固件和应用程序开发人员插入的库那样. 当谷歌不与设备制造商绑定, 可以独立控制 API 的更新过程时, 这也是对抗碎片化的一种方法. 这是一个可行的解决方案, 但它要求开发者将库连接到客户端 API, 以便与 Google Play 的服务进行交互.

现在看起来一切正常, 但事实并非如此. 随着时间的推移, 谷歌服务也变得邪恶起来. 要安装 Google Play 和同名服务, 任何厂商都必须遵守谷歌的严格规定, 其中包括预装 Google Play 应用程序, 在默认启动器的主屏幕上设置一个包含谷歌应用程序的文件夹, 以及其他许多隐藏条款和针对厂商的特殊条件. 为什么大家都这么做? Google Play 拥有最大的 Android 应用程序目录, 最受欢迎的 Android 应用程序排名前 1000 位. 谷歌的所有指导方针都是受这些服务的启发而制定的, 所有开发者都以使用谷歌服务为目标, 即使他们的软件是通过其他应用商店发布的. 这是因为在中国以外的几乎所有流行设备上都可以使用谷歌服务. 谷歌服务是Android设备上的王者和上帝, 开发者只能基于谷歌服务创建功能. 不要以为如果其他公司有机会让自己的服务享有同样的特权, 他们就不会使用. 任何开发者, 无论是固件开发者还是第三方开发者, 都希望自己的应用程序能在设备上正常运行.

你可以说"但我们有 AOSP! 为什么厂商不使用它? 那不是 Android 的开放版本吗? 首先, 它有自己的许可证, 这一点也需要研究. 在整个文档中, 你会发现开放源代码这个短语, 但这并不意味着可以普遍使用. 你使用过 AOSP 设备吗? Nexus 和 Pixel 上的裸 Android 并不是 AOSP. AOSP 是一种没有应用商店的 Android 构建; 没有用于处理电子邮件和短信的普通标准应用, 也就没有推送通知, 谷歌宣传的某些功能也就不存在了. 因此, 厂商只有两个选择: 接受谷歌的条款, 或者自己创建所有服务, 希望人们购买设备, 开发商改编软件. 中国的华为和厂商设备被迫选择第二条路, 因为中国从来没有谷歌 Play 服务.

对于普通用户来说, 谷歌服务已经成为 Android 操作系统体验不可或缺的一部分, 谷歌获得了对所有设备的控制权, 这些设备甚至是自己不生产的, 尽管这种控制权并不完整. 这是有道理的. 毕竟, 该公司花费巨资开发和支持操作系统, 而其他公司几乎只为自己做所有的开发工作.

A/B 系统更新

A/B 更新是一种可以在不中断应用程序或不影响用户数据的情况下更新设备的功能. 它们的工作原理是下载一个额外的系统镜像, 安装在非活动分区上, 然后在重启设备后切换到活动分区. 它允许设备在不同版本的系统之间快速切换, 而无需完全重启.

你可能会想: "这和碎片有什么关系? 问题是: 新系统允许用户进行透明的系统更新. 这些更新不会强迫用户在设备启动时等待更新. 相反, 系统会在用户不使用设备时进行一次不易察觉的重启. 当设备要求输入解锁密码而又不允许使用指纹或面部扫描仪时, 这一点就很明显了. 更新安装在设备后台运行时进行. 虽然速度仍然很慢, 但如果你能使用自己喜欢的应用程序和玩游戏, 这也就无所谓了.

直接启动

如果设备重启可以在用户毫无察觉的情况下进行, 那么应用程序如何在悄无声息的重启后继续工作呢? 为此, 谷歌创建了直接启动机制, 允许在用户输入设备密码前启动应用程序. 应用程序可以使用部分存储空间, 无需用户解锁设备; 只需启动智能手机即可. 这样就可以轻松接收短信, 电话, 闹钟, 推送通知等. 这一功能可以让关键功能保持运行, 防止用户怀疑设备被重启. 这是谷歌的一大创举, 因为它为Android系统未来的变革做好了准备, 使更新与设备制造商脱钩.

Treble项目(Android 8)

在Android 9 之前, Android系统的更新过程一直很缓慢. 原因在于, 设备制造商必须获得设备中所有微芯片的驱动程序更新, 新操作系统的源代码, 然后调整他们的外壳和其他开发. 谷歌决定打破这些部分之间的依赖关系.

Treble项目之前的Android发布流程.

Project Treble是Android架构的一项重大变革, 在Android 8 Oreo 中实现, 它将操作系统分为两部分: Android系统和运行设备的底层软件(它们也被称为厂商实现). 在它们之间, 增加了一个新的层, 即厂商接口, 类似于代码中的接口. 设备开发人员可获得一个保证向后兼容性并通过特殊测试的层--[厂商测试套件]

Treble之前和之后的设备更新.

由于 Project Treble 通用系统映像 (GSI) 的出现, 它由 Android 源码编译而成, 并保证与厂商实现的前 3 个版本向后兼容. 这意味着 GSI Android 13 可以安装在任何运行 Android 12, 11 和 10 的设备上.

所有使用Android 8 或更高版本发布的设备显然都支持 Project Treble. 对于从上一版本升级的设备, 这一要求是可选的.

系统架构的重构使制造商能够更快地将设备更新到新版本的Android系统, 因为他们不再需要等待驱动程序更新. 取而代之的是, 他们可以使用标准化接口, 完成固件适配工作.

新版Android系统的发布速度

从图中可以看出, Treble 对设备更新的速度产生了影响, 从而对降低设备碎片化程度产生了直接影响, 但这仍无法解决旧版本操作系统的问题. 它们就像死物一样悬挂着, 但随着时间的推移, 新版本最终还是被成功取代了.

2023年6月6日Android设备上的版本分布情况

如果你看看今天, Android 8 及以下版本的份额并没有增长, 但较新版本的势头只增不减. Android 10 及更高版本占据了整个市场三分之二以上的份额.

操作系统组件的模块化系统

Project Treble 是一个很好的解决方案, 但它仍然让谷歌依赖于厂商及其响应速度和更新设备的意愿. 他们需要找到一种不受制于制造商的设备更新解决方案.

解决方案显而易见, 那就是将系统划分为多个部分, 通过具有完全权限的设备上的系统服务进行交付. 这就是Android 10 中的主线项目(Project Mainline), 它将系统组件分离开来, 允许它们独立于正常的操作系统更新周期进行更新.

现在的问题是: Android系统中谁有足够的权限更新模块? 当然是 Google Play 服务! 但并不是只有他们能这么做. 设备制造商提供的任何具有相同权限的服务都适用.

模块更新不能引入新的 API, 但可以改变行为. 在新版本中, API 可以扩展, 但保证向后兼容. 这种行为由兼容性测试套件(CTS) 保证, 这是一套特殊的测试, 谷歌通过它检查设备厂商对 API 的实施情况. 所有模块都会自动更新或回滚.

例如, 这样的系统可以接收网络协议栈和时区的更新, 而无需等待厂商进行更新或应用程序开发人员上传新版本的数据库.

APEX

为了分发 Android SDK 中的模块, 我们引入了一种新的文件格式 APEX, 以及一种在设备启动时进行安装的实用程序 APEX Manager(apexer). APEX 格式在结构上与 APK 相似, 但 APK 并不适用, 因为它无法在操作系统加载阶段安装.

APEX 文件是有效的 APK 文件, 因为它使用相同的签名方案, 并包含任何 APK 都需要的AndroidManifest. 所有这些都是完全使用 APK 文件的所有工具所必需的: 设备上的 APK 安装程序, adb, 签名工具, PackageManager API.

APEX文件结构

Android SDK 扩展

在 Android 11 中, 框架开发人员更进一步, 决定实现为旧版本 Android 添加新 API 的功能. 事实上, 这一功能开始用新的 API 扩展 Android SDK. 现在, 可更新模块可以添加新功能, 而 Android SDK 扩展则为开发人员使用这些功能添加了 API.

// Check if we have Android 13 if (Build.VERSION.SDK_INT >= Build.VERSION_CODE.TIRAMISU) { // Launch PhotoPicker context.startActivity(Intent(MediaStore.ACTION_PICK_IMAGES)) } // The code runs on Android 11 and higher // Check that the extension is available and that it is the proper version if (SdkExtensions.getExtensionVersion(Build.VERSION_CODES.R) >= 2) { // Launch PhotoPicker context.startActivity(Intent(MediaStore.ACTION_PICK_IMAGES)) }

结果是在操作系统中引入了 SDK 扩展模块. SDK 扩展模块的版本类似于我们使用 Build.VERSION_CODE 检查 API 的方式, 但由于有了扩展模块, 现在在文档中可以看到, 描述的不仅是 API 级别, 即 API 可用的地方. 而且还包括将包含该 API 的 SDK 扩展集及其版本.

SDK扩展中可用性描述示例

设置项目时, 我们需要指定 compileSdk 版本以及 SDK 扩展的版本. 别忘了先在 Android Studio SDK 管理器中安装. 在使用某些 Android 功能时, 系统现在检查的不是 Android SDK 级别, 而是扩展的版本. Android Lint 一定会提醒你注意这一点.

// build.gradle.kts android { compileSdk = 33 // Android 13 T // T Extensions will be used // Specify the version of the extensions. Not connected by default compileSdkExtension = 5 }

我们真的需要新的Android版本吗?

主要问题仍然是, 是否值得等待新版本的操作系统, 以及何时更新到你的智能手机? 我认为不值得. 每个版本的Android系统都会为用户带来较少的新功能, 而为开发者提供的许多新 API 都是通过 Jetpack 和 Google Play Services 中的库实现的. 谷歌的所有努力都是为了全面控制操作系统的更新, 与设备制造商无关. 后者不可能轻易跳出 Android, 因为根本没有可替代的操作系统. 开发自己的操作系统既耗时又昂贵. 谷歌的管理者们做得非常好, 他们给予了大量的自由和机会来吸引制造商和开发者, 但他们多年来一直在努力重新夺回对自己的完全控制权, 正如我所说, 他们正在取得成功.

每年, 我都会查看Android操作系统的下一个版本, 我看到它的内部发生了多少变化: Mainline模块新的发布, 整合从Jetpack到Android框架级的技术, 整合与硬件相关的新技术. 这表明, 谷歌开发Android系统是为了自己, 部分是为了合作伙伴, 追求的是自己的商业利益.