我们已经讨论过 Android 8.0 的诸多新特性了，包括通知分类、自适应图标、更激进的后台管理策略等等。
但这些都是我们从视觉层面能够看到的更新，事实上，Android 8.0 还引入了一个具有深远意义的新机制——Project Treble。
在理解 Project Treble 的原理、作用及其意义之前，我们很有必要先来了解一下 Android 系统进行大版本升级的大致流程：
近几年，Google 在提交 AOSP 源码这一步做得尤为迅速，甚至有部分芯片制造商和 OEM 厂商在正式版 Android 系统发布前就能拿到源码。
所以上述升级流程的主要问题在于后面几步：有的芯片厂商会在源码适配上遇到技术问题（很少），部分 OEM 厂商的软件开发团队定制新系统的进程偏慢，运营商有时也需要打量了人力和物力来测试新版系统的通讯稳定性……
整个过程所花费的时间，最后都转化成了用户茫茫的等待，以及每个月 Google 发布的 Android 个版本占比报告中，新版本系统那一星半点的设备占有率。
Android 是一个免费、开放的智能手机操作系统，为了让开发者开发的应用可以在不同硬件厂商的手机上正常运行，Google 引入了兼容性定义文档（CDD）和配套的兼容性测试套件（CTS）。经过测试的手机才能被许可安装 Google Play 服务并投入市场。
Project Treble 就可以类比为软件和 Android 系统层面的 CDD/CTS。
Google 引入了一个名为 vendor interface1 的理念，并用它将 Vender Implementation——由芯片制造商编写的设备专属的底层部分，从 Android 系统框架中剥离出来。
在没有进行这个「划分」前，新系统的升级必须要完成大量对底层部分的更新重构（vendor implementation，通常由芯片厂商完成）和对 Android 系统框架的升级（Android OS framework，通常由 OEM 厂商完成），工作量大且难以协调。
有了 Project Treble 以后，当新系统发布时，底层（vendor implementation）部分的工作量就被节省了出来，OEM 厂商在 AOSP 源码发布后只需根据自身需求对 Android 系统框架（Android OS framework）进行升级即可。
由芯片制造商编写的设备专属的底层部分则由 Google 和芯片厂商一起承担，并被设计为不再面向特定版本的 Android 系统。Project Treble 发布后，Google 和部分芯片厂商一起通力合作，将一些原本由芯片厂商独自负责适配的底层代码重构并迁移到了 AOSP（比如高通），还有一些 OEM 厂商也积极参与到了这过程当中，来保证自己的一些特性能够在 Android 系统更新的同时进行无缝整合（参见索尼与 LDAC）。
目前，Google 已经在 Pixel 和 Pixel XL 上实现了 Project Treble。同时，Google 也积极寻求与各芯片厂商的合作，来为当前市场上的主流旗舰机型适配 Project Treble。
采用高通骁龙 801 处理器（MSM8974）的 Android 设备由于高通方面不进行适配而无法升级到 Android Nougat 的情况2 ，将不复存在。
今后发布的新手机，如果想要预装或升级 Android 8.0，都必须先经过 Project Treble 的认证。这个认证过程意味着，在 OEM 厂商对 AOSP 源码进行定制前，这部手机就已经能够运行 AOSP 系统并通过 CDD、CTS、VTS 等一系列测试了。
换句话说，以后开发者通过 AOSP 代码编译的 ROM 几乎可以在任何支持 Project Treble 的新手机上运行，无论它是哪家 OEM 厂商的设备。基于这个 AOSP 操作系统，第三方 ROM（比如 Lineage OS）的适配工作将变得异常简单。
那么老设备能否从中收益呢？这就取决于开发者了。适配 Project Treble 在现阶段看来，是一个工作量浩大且近乎不可能的工作。一旦完成，这台设备就有了升级到未来 Android 系统的基础。
让我们拭目以待吧！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。