Android 工程师如何终结碎片化问题？

距 Android P 正式版还差一步，化零为整的碎片化问题即将解决。

距离 Google 发布 Android P Beta 2 以及终极版 API 不到一个月，近日Google 再次推出第四次更新，Android P Beta 3 版本现已面向开发者开放。

Google 表示最后一个测试版最终确定了开发者为其 App 所需的所有 API、最新的 Bug 修复、稳定性优化以及安全更新，且这个测试版将更接近预计今年夏天即将发布的 Android P 正式版。

Android P Beta 3 还为 Android Studio 构建工具带来了更新，将 D8 作为独立工具。想要使用新 API 构建，将官方 API 28 SDK 和工具下载到 Android Studio 3.1 中，然后将项目的 compileSdkVersion 和 targetSdkVersion 更新为 API 28。此外，Android P 的新功能还包括多摄像头支持、凹口屏幕适配、更好用的推送通知、ImageDecoder、TextClassifier 等等。

开发者可以通过从 developer.android.com/preview 下载最新的预览版进行测试，预览版中包含一个更新的 SDK，即 Pixel、Pixel XL、Pixel 2、Pixel 2 XL 和官方 Android Emulator 的系统映像。如果你已经注册并在 Pixel 设备上收到 Android P 测试版，那么也会自动获得 Beta 3 的更新。

▌适用机型

与过去几年相比，在 Project Treble 下，Android 公测项目可在更多设备上使用：

除谷歌的 Pixel 设备外，Android P beta 还可在索尼 Xperia XZ2、小米 Mix 2S、诺基亚 7 Plus、Oppo R15 Pro、Vivo X21、OnePlus 6 和 Essential PH-1 上使用。

那么为何有史以来，Android 开发者预览版第一次可发布在除 Google 自家的 Pixel 机型外的其他设备上，当然，这其中就涉及到了上述提到的 Google Treble 项目概念问题。

▌何为 Treble 项目？

随着去年 Android 8.0 的发布，Google 向全世界宣布了 Treble 项目。Treble 是 Android 有史以来最大的工程之一，将 Android 操作系统与硬件分离开来，极大地减轻了更新设备所需的工作量。它的目标就是解决 Android 一直存在的碎片化问题，而在 6 个月之后的今天，这个项目似乎起到了很好的作用。

今年的整个 Google I/O 大会到处可见 Treble 革命效果。Android P beta 版发布，不仅限于 Google 自己的 Pixel 设备，Android 的开发者预览版也可发布在上文所述的设备之上，这都要归功于 Treble 项目带来的兼容性。就连汽车制造商这种地球上对新技术最不敏感的物种，都搭上了 Treble 项目的快车。道奇和沃尔沃都有用 Android 作为信息娱乐系统的原型车，而两者都采用了 Android P。

而接下来，我们从外媒 ARS 采访 Treble 项目的负责人 Iliyan Malchev 和 Android 工程副总裁 Dave Burke 的访谈过程中，剖析 Treble 项目解决碎片化问题的手段以及一窥 Android 的未来。

▌伴随 Android P 而来的 Treble 项目

首先来回顾下 Treble 项目的近况。

Iliyan Malchev：Treble 将操作系统分离到一个适配层中，这个适配层根据硬件进行了裁剪。这一点依然保持不变，但细节才是最重要的。我们仍然需要改进许多东西，这正是我们这次 Android P 发布中的重点。关于 Treble 目前的情况，我想许多媒体没有注意到的是，现在任何预装 Google 应用的设备，任何发布时安装了 Oreo 或更新版本的设备，都必须能流畅地运行一个用于认证的 Android 二进制映像。

这个映像并不是产品。我们的意图并不是发布这个映像，而是通过强制任何设备都能运行这个“标准映像”，我们要建立一种向心力，以较为柔和的方式防止合作者们做出对他们的标准没有太大意义的改动。在今年的 Android P 中我们完成了技术部分，现在我们开始与芯片厂商共同完成下一步。

Dave Burke：对，我想这才是最大的变动。在完成技术工作之后，我们需要实际地向芯片厂商推行这一工作，这项工作带来的变动十分巨大。

Google 的“ Android 发布的生命周期”

Malchev：我们在台北、韩国和圣地亚哥分别与联发科、三星和高通合作。我们将我们的成品嵌入他们的 BSP（Board Support Package，板级支持包）。高通等公司拿到我们发布 AOSP（Android Open Source Project， Android 开源项目）之后，就将其嵌入到 BSP，再交给设备制造商。 BSP 才是设备的起点。设备不是从 AOSP 开始做的，因为 AOSP 自身并不是个完整的产品。

正如 Malchev 所说， Android 的开源部分（AOSP）只包括操作系统代码，并不能在任何硬件上运行。板级支持包（BSP）和 AOSP 结合在一起，再加上其他必要的代码，才能让 Android 在某种硬件上运行起来。这就像是 Linux 内核与驱动程序的关系一样。如上图所示，Google 发布 AOSP，高通等 SoC（System on a Chip，系统芯片）生产商将 AOSP 与特定版本的 Android Linux 内核及驱动程序结合在一起建立 BSP，然后 OEM 厂商将 BSP 加载到手机上，再加上硬件和软件方面的定制。

Malchev：我们这次解决的问题就出在 BSP 上。因为如果我们八月份发布 AOSP，然后高通用三个月时间发布 BSP，这就接近年底了，设备制造商就完全没有机会了。所以我们将所有这些工作都吸收进来，使之在 Android 内部开发阶段同时进行。

Burke：其中一个例子就是 Telecom 和 Telephony。我们在上游做了多少改动？很多很多。

Malchev：对，所以除了这些之外，我们还将原本由合作伙伴完成的大约 150 个功能吸收到了上游，让 AOSP 更像一个完整的产品。这一点非常重要，因为长期维持这些代码的成本非常高。

这里的“上游”的意思是“OEM 制造商的上游”，即 AOSP。Malchev 的意思是，他们在 AOSP 里包含了许多第三方收集的代码，这样 OEm 厂商就无需再维护太多代码了。

Treble 项目基本上就是按照公司分割 Android 系统（图中以不同颜色表示）。Google 是 Android 平台供应商，高通则是典型的 SoC 供应商，而三星等公司则是 OEM 或 ODM。

Burke：另一个巨大的变动就是工作流程。芯片制造商（目前就是我们支持的这三家）实际上会为 AOSP 提交代码。所有公司都在同一个代码仓库上工作。这是我们合作方式上的巨大变更。以前，我们先把 OS 做到某个阶段，然后芯片制造商拿到代码再开发至某个阶段，最后设备制造商再开发至某个阶段，这一切都是串行的。现在，我们可以与芯片制造商在同一个代码上并行工作。我们发布的 Android P 的 RC 版，他们称为“CS 版”，即“商业样品版”（Commercial Sampling），他们也同时可以发布了。这就是巨大的变更。

Burke 和 Malchev 所说的就是我们在 I/O 大会上看到的 Android P Beta 版的发布。Google、高通和其他 SoC 厂商以及 OEM 厂商都在全力合作，把新的 Android 版本带到设备上。以前，“串行”的开发过程意味着每个公司必须等待前一家公司完成之后才能开始工作。现在，只要 Android 中的软硬件之间有了稳定的借口，任何人都可以同时工作，让新版本的 Android 运行在某个硬件上。

关于现在的情况，Google 甚至还给了我们这句来自 Essential 的话，让我们得以了解适配 Android P 大概需要多长时间。

“确保 Essential 的用户使用最新的 OS 更新，对于我们极其重要。现在我们通过 Treble，在 Oreo 上实现了制造商和系统的分离，我们的小团队只用了三天就成功地在 PH-1 上跑起了 Android P。”——Essential 软件开发副总裁 Rebecca Zavin

Essential 的手机可能是升级的最好例子：它的设备与 Treble 项目兼容，运行原厂的 Android 系统，所以无需做任何软件改动。但是，三天完成系统移植，这个进度仍然快得不可思议，因为许多 OEM 都要花费几个月才能完成升级。

Malchev：不过这仅仅是冰山一角。Dave 刚刚提到了与芯片制造商合作，这意味我们都需要大幅度改变工作流程。高通为 Android 工作的部门有 6000 名工程师。对于 Treble 项目，他们紧密地在我们的基础设施上与我们合作。所以我们能共同保证他们的 BSP 是最新的，我们还确保在 Android 完成时，他们的 BSP 也立即可用。这涉及了数不清的变动。我们与联发科和三星半导体也做了同样的事情。

对于 Android P，许多人已经成功地在某些设备，比如华为手机上运行了 Android P，它原本是个深度改造的 Android ，只需用 AOSP 替换掉，就能用了。

Malchev：我在看到第一个报告时感到很高兴，因为这是来自设备厂商之外的证据，证明了通用框架是最佳选择。现在自定义固件极其容易的原因就是，我们为了 Treble 兼容性而强制要求的通用映像，正是自定义固件的基础。所以就算我们不发布任何关于如何创建该映像的说明，它基本上也是个开源的 Android 。

Burke：之前的情况是，设备制造商要想生产兼容的设备，就必须通过 CTS，即我们的兼容性测试套件（Compatibility Test Suite）。现在他们必须在芯片实现之上的“标准映像”的基础上去通过 CTS。

“标准映像”是指 AOSP？它必须能启动，并且能正常使用一切功能？

Burke：是的，它必须通过所有这些 CTS 测试，大概有八百多万条测试用例。都必须通过这个标准映像来执行。

2014 年世界移动大会上的一台高通测试机（右）。旁边的是 Nexus 6（左），世界上最大的商用手机之一

Malchev：这就是所有手机的祖先。或者说，每个使用这片 SoC 的手机，就是说使用骁龙 845 的手机，基本上就是这台机器的复制品。就像个人电脑一样，只不过每个芯片都有自己的一套体系。这一台运行的是带有高通的功能的 Android P。基本上这就是个运行 Android P 的 BSP。OEM 厂商可以在它上面做自己的设备了。

而要问我们做了什么来支持自定义固件。他们是从 Oreo 开始做的，对吧？那正是我们这次发布所做的。在 O MR1（ Android 8.1）和 P 中，我们改进了 Treble。从自定义固件的角度来看，在厂商范围内支持 Android 的未来版本基本上是零工作量。所有工作量都紧紧密封在 P 中。而在 Oreo 中，你得在我们所称的 VNDK（Vendor NDK，厂商 NDK）上做一些工作，你上一篇关于 Treble 的稿子也提到了。Oreo 中的 VNDK 的完成度并不高。但在 MR1 和 P 中我们完成了 VNDK。感觉就是，我们拧紧了几个螺丝。

事实上很难。顶层和底层之间的界限非常非常长，而且二十分曲折。因此，定义这个便捷并强制推行需要极大的努力。我们能自动化的工作越多，它就会越好。我觉得我们已经完成了自动化的部分。

关于厂商 NDK：Treble 项目的工作原理是给 Android 的每个子系统一个 HAL（硬件抽象层）。这些是 Google 和硬件厂商共同定制的标准接口，比如可以让 Android 的照相机代码运行在厂商的照相机硬件上。Android Oreo 中大约有 60 个 HAL，分别是照相机、音频、地理位置等等。Oreo 中这些 HAL 并没有覆盖所有设备类型，因此为了让硬件厂商能为自己的设备类型编写 HAL，Google 给 Android 加入了厂商 NDK。想像一下比如三星 Galaxy S9 中的视网膜扫描——如果视网膜扫描器不是 Android O 官方支持的设别类型，三星就要利用 VNDK 定义自己的设备类型。Android P 中的设备类型更多，因此软件开发商和开发者的工作量更少。

Treble 最终发布后有没有让你们感到惊讶的事情？

Malchev：当你创造并坚信的理论被证实正确时，那种感觉非常好。我第一次听到设备厂商之外的正面反馈时，感到十分激动，因为，不论你自己多么坚信，总会有那么一丝怀疑。

但通过来自于开发者的反馈，我们开始十分自信！太不可思议了。这与制造商的反馈完全不同。我们在 Android 中做了些很特别的事情，然后该他们做他们的特别的事情，以发布 beta 版，证明了我们到目前为止的工作足够他们完成他们的工作，并在年内实现发布。

开发者在如此众多的手机上给出反馈的事情每年都会发生？

Malchev：对，我希望以后只会越来越多。

Burke：对，我觉得是。而且时机很有意思。我感觉，整个行业已经越来越成熟，性价比已经成为 CFO、设备制造商和芯片制造商们越来越关心的事情。他们会看着我们的工作然后说，“哦，我要是直接使用标准映像，不做任何改动，似乎能省很多钱？好，那就这么干。”以前最开始时他们会说，“哦这是开源的，我们来做点东西吧！”但现在他们意识到，他们最好是只做小改进，复用已有的东西。如果你看看 streamline 是怎样在硬件领域改变了整个 ODM 行业的，那么我们就是想在软件领域做同样的事情。

Malchev：那句“Be together, not the same”的意思就是，我们不想强迫所有人都一致，但这种灵活性不需要付出修改大量源代码的代价，是吧？因为每次重新编译 Android ，都会花掉无法估计的钱去验证并测试。

▌Android P 有什么新特性？

Google I/O Keynote 上的 Android P 的新特性

Google Play 商店中的应用必须以最新版本的 Android 作为目标版本。如果所有应用都能在最新版本上运行的话，意味着不需要再支持大量过时的 API，那么这会不会改变你们对 Android 未来版本的看法？你们会逐步关闭旧的 API 吗？

Burke：这个问题很有意思。我的回答是，这不是我们的主要目的。主要目的只是让应用开发者使用最新的功能。例如，在 Marshmallow（Android 6.0）中引入运行时权限时，许多应用的目标都是 pre-N（Android 7.0），而当时这种情况不应该发生。 所以其实这是个我们没控制好的环节。我们在引入这个规则时考虑了许多情况。现在的结果是，8 月份之后新提交的应用必须遵守该原则，而已有的应用必须在 11 月之后完成更新。

我觉得有个很有意思的问题，比如说想想未来几年的事情，再想想 32 位和 64 位的问题。你当然可以改变应用的生态系统以便随时紧跟芯片的发展。这种情况给了我们一些改变的动力，但并不是我们的主要目标。

你这个问题提得很对，这的确是个删除旧 API 的好机会。只不过，我们最不愿意做的事情就是放弃开发者。建立一个成功的应用十分困难，这正是建立业务的最大的挑战。我们最不愿意做的事情就是为难别人。从另一个角度来看，每个人都可以按照自己的意愿前进，因此我们会全面考虑这个问题，嗯，对，这会给我们一些选择，但还是那句话，并不是我们的主要目的。

Android P 会支持 Wi-Fi RTT 吗？这个不是在 Android 5.0 就支持了吗？我记得有个 RTT 管理器是吧？

Burke：对，以前就有。这个是 802.11mc。以前只给系统使用，但现在我们加上了公开的 API，所以应用也可以使用 RTT 的信息了。

所以说以前不是公开的，而现在公开了？

Burke：对。以前不对第三方应用开放，而现在开放了。稍后会有个演讲是关于米级定位的。我记得那个演讲里有一段室内导航的视频，酷极了。那个视频就像是，一个人在楼里随时进行定位，而一切都只需要通过 RTT 实现。这个点子确实很棒。

难点之一就是，这个点子看上去似乎很容易。其实是，嗯，是两个方向上的 RTT。你的手机发给无线访问点（AP）一条消息，AP 给消息加上时间戳然后返回给你。光速是已知的，这样就能计算出距离。但实际的问题是，要想知道具体位置，你得给多个访问点发消息，而难点是，这些消息并不会同时返回。所以你得解个约束方程才能知道你在哪儿，我记得这个叫“多点定位”（multilateration）吧。这个确实太酷了。

确实有个关于 Wi-Fi RTT（Round Trip Time，来回通信延迟）的 Google I/O 演讲。GPS 需要能看得到天空，并且精度只能到大约 5 米左右，但如果附近有多个 Wi-Fi 热点的话，Wi-Fi RTT 能提供更好的定位，最终的精度能到达１～２米左右。室内导航的视频大约在演讲的 5:30 开始。Android P 不仅会开放 802.11mc API 供开发者直接使用，还会将其包含在 Google 简单易用的“混合位置服务”API 中，从而自动通过多个信号源（GPS、Wi-Fi、蜂窝网络、陀螺仪）确定位置。

尽管 Android 会支持 Wi-Fi RTT，你还需要几台支持 Wi-Fi RTT 的路由器，或者叫信标（Google Wi-Fi 在今年年底会支持 802.11mc），而且还得知道这些 Wi-Fi 热点在地图上的位置。在 Google I/O 的 RTT 演讲中，Google 提到他们打算以后以众包的方式提供 Wi-Fi 路由器的位置，以让 RTT 变得更实用。Google 地图目前已经用众包方式提供不太精确的 Wi-Fi 地点了。

以前在 Android O 中有个开发者选项，可以切换 GPU 渲染方式为“default”或“Skia”。现在这个选项没有了，我记得 Android P 默认运行的就是 Skia 吧？

Burke：以前 Android 的标准窗体不支持硬件渲染的。基本上是建立在 Skia 之上，而 Skia 是软件渲染。同时我们还做了个“GL 渲染器”，是基于 OpenGL 的。所以以前有两种方法。系统里有一种使用硬件加速器的方法，这得放弃 Skia 去使用 GL 渲染器。而其他部分可以使用 Skia。不过说来话长，其实一部分 GL 渲染器也在使用 Skia。听起来是有点怪。

Malchev：一些 Skia 在慢慢地迁移到 GL 上，但并不是所有的都迁移了。

Burke：我们在给 Skia 做一个 GL 后台。我们在清理架构。简单来说，整个架构的目标是让 Android 的 UI 框架直接与 Skia 对话，然后 Skia 负责与硬件加速的后台对话。而不是像现在这个奇怪的世界一样，一些窗体得自己去找 GL 渲染器。这就是我们要清理的东西。我只是想不起来这是 P 里的功能还是以后版本的功能了。我记得还没完全完成呢，但这是我们的目标。源代码里看得见，也不是什么大秘密。

题外话，Skia 是个主要由 Google 开发的开源图形引擎。在演讲中提了几个问题之后，我得到了更多的细节，如 Skia 能加速 Material Design 里广泛应用的阴影渲染等。希望我能找到个更完整的答案，不过研究过程的第一步走得不错。

更新：在这次访谈结束后，Burke 澄清 Skia GL 后台实际上在 Android P 中已经完成了。

为什么 Android P 的 API 里有个新的指纹读取 API？旧的有什么问题？看上去似乎没问题。

Burke：有好几个原因，但最主要的是我们看到一些设备制造商（如 Vivo）希望支持屏下指纹识别。所以你得有个标准的 UI，否则其他应用就乱了。如果能回到当初我们肯定会这么做，如提供标准的系统对话框，这样厂商们就能采用了。

就像是“请按这里”一样的 UI？

Burke：是的。这就是主要的原因。而且新 API 对生物识别提供了更通用的支持，因为以后会有越来越多的生物识别技术，所以这也是主要原因。所以，现在“FingerprintManager”API 已经不建议使用了，改成了“BiometricPrompt”。

应用会“乱”这个点不错。屏下指纹识别会要求在当前应用上弹出一个窗口，而手指放上去不能触发应用本身的东西。由于 Android 安全原因而锁定了浮动窗口，因此没有 Google 的参与和标准的 API，这个弹出窗口就很难实现。

Dave Burke 喜欢更长的续航时间，我们也喜欢

关于后台 Activity 的改动。你们现在会利用 AI 来更激进地关闭应用吗？

Burke：对，我们想尽量节省电池。有四个桶，第一个桶里是未来三小时内会用到的应用，最后一个桶是至少 24 小时之内不会用到的桶，中间的以此类推。然后我们利用 AI 根据用户的使用习惯来预测哪个应用放到哪个桶里。每个桶里的应用对于网络和 CPU 的访问级别都不一样。因此简单来说，我们希望系统中只有那些马上会用到的应用才能更多地使用电池、网络和 CPU。

上述提及对手机的“访问”，是指 JobScheduler 窗口吗？

Burke：对，基本上就是 JobScheduler 窗口。为什么要更新 API，因为我们想把所有应用都放到 JobScheduler 下，这样就能统一管理，而不是像以前那样。

这个其实很有意思。我们其实可根据每个人的使用习惯训练个模型，它能告诉你使用 Twitter 的习惯。但我们不想这么做，所以我们在设备内部精心打造了一个系统。它有个通用的使用模型，当你使用手机时，我们会检查你的使用情况。比如说，你正在用 Twitter，我们就会检查你怎样用 Twitter，然后找到最接近的模型。其实更像是个性化，而不是在设备上进行训练。而保证在设备上完成这切，可以解决很多隐私方面的问题。

JobScheduler 是从 Android 5.0 Lolipop 开始，作为 Volta 项目的一部分提供的 API。它守护着后台 CPU 活动和网络访问的使用情况。应用不是自己去访问网络，而是交给 JobScheduler，后者将不重要的请求放到后台做批量处理，从而让设备能休眠更长时间，以节省电池，然后在特定的窗口内定期唤醒设备供所有应用的后台活动使用。以前，JobScheduler 还负责关闭那些不使用的应用，但现在 Android P 有了“自适应电池”（Adaptive Battery）功能，似乎将会有个更合理的功能负责根据应用的使用情况来关闭应用。

▌Treble 项目感悟

Burke：我个人花费了很多时间与设备制造商和芯片制造商打交道，他们都很喜欢 Treble 项目，貌似对他们来说这是最大的改进。这个项目很难，它涉及了太多部分，而且要求团队里每个人都必须做出改动，包括媒体框架、位置服务、UI 工具包等等。我们投入了相当大的经理，这就是为什么在 O 中我们推出的面向消费者的功能较少，因为我们的工程预算都花在了 Treble 上。

而在 P 中，我们又开始提供更多面向消费者、面向普通用户的功能。但是，最棒的不仅是这次发布有许多新特性，而且我们终于可以收获 Android O 时的投入，让设备制造变得更快了。

Malchev：更重要的是，我们需要引导 Treble 的企业化过程。我想指出的是，只有与全世界的大公司通力合作，我们才能证明这个过程。一旦我们证明了 Treble 能在任何设备上运行，他们就会越来越多地接纳 Treble，直到所有人都使用 Treble。

“征稿啦”

CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。

如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（[email protected]）。