劝学：Android 14 Framework 引入了哪些“新”技术栈-编程知识

2023 年 Google I/O 已于 2023 年 5 月 10 日拉开帷幕，Android 14 Beta 版本近期也已经释放到 Google partners，本文主要分析 Google 在 Android 14 框架代码中引入了哪些新的技术栈，而对于新功能和 API Change，则并不在本文的讨论范围之内。

编译系统：Bazel 使用范围进一步扩大

说到编译，对于独立应用而言，大家接触最多的应该是build.gradle，这个不在此赘述。事实上，Bazel 已经不能说是在 Android 14 首次亮相了，这一点大部分 Java 开发者应该感知不到，因为我们几乎都被 Gradle还有 Make 宠坏了（虽然也不是那么好用），比较关注新技术的搞浏览器或者偏底层的小伙伴，倒是可能早就在用了。

需要首先说明的是，Bazel 并不跟 Android 编译强相关，只不过它碰巧支持构建 Java、C++、Go，Kotlin 等语言，而 Android 开发也基本使用上述这些语言。另外，对 Rust, Python 的支持也在逐渐被加入，Google 对 Bazel 的开发还是十分积极的。

转到框架这边，截止到 Android 13，你写的大部分配置文件应该还是 Android.bp，它经过 Soong 解析成 Ninja，而偏底层配置相关的逻辑，则依然由 Android.mk 定义，并经过 Kati 解析成 Ninja，一个典型的编译流程图如下：

而来到 Android 14，Bazel 的解析流程会被加入进来，流程图如下：

从目前 Google 公布的路线图来看，从 Android 14 开始，所有迁移后的 C++ 模块将默认使用 Bazel 编译，从 Android 15 开始，所有 Mainline 的模块将默认使用 Bazel 编译。

看到这，估计你还是不慌，反正老的还兼容着呢，不急。然而 Google 对这块还是有信心的，如果问题不大，再加上官方自己不弃坑的话（老实说 Google 弃的坑不少了，懂得都懂），等到了 Android 16，整个编译系统应该都会切到 Bazel。

Settings：Kotlin 和 Jetpack Compose 都来了

开始迁移到 `Kotlin`

Google 在 2017 年的 IO 大会上将 Kotlin 定义为 Google 官方支持的开发语言，时至今年，大部分 App 开发者都已经切过来了。然而，Android 框架开发者很多似乎还对这门语言嗤之以鼻，或者换句话说，平时用不到，再加上 Google 似乎一直没在框架里过多使用，所以暂时也没有学的必要。

很”遗憾“，在 android 14 的 Settings 模块，我们开始看到了 Kotlin 的影子。自此，搞框架 App 开发的同学失去了最后一个不学 Kotlin 的借口。

事实上，Settings 模块并不是第一个吃螃蟹的，头部的 SystemUI 模块，早在 2018 年就开始用 Kotlin 改写部分模块了，而且这次 android 14 上还有进一步的演进，这个后面会提到。

我们很多搞框架开发的小伙伴，对于新技术似乎有种本能的排斥，大家的内心 OS 无外乎：

这玩意儿都是折腾 App 用的，框架要的是稳定，完全用不到
Google 自己都没咋在模块里面用到，我干嘛折腾呢？
天生骄傲，觉得自己是搞框架的，比隔壁那些搞 App 的高到不知道哪里去了…

希望看到这篇文章的小伙伴，平时千万不要有以上这些想法。我们的认知永远都是有限的，很多时候你这样想，很可能只是因为没有看过别的模块而已，别的模块说不定早就卷入新的技术栈了，就等着弯道超车呢。

怎么办？怎么办？怎么办？

学！Kotlin 怎么学，这个……这么多年了，网上太多教程了，不说了。

引入 Jetpack Compose

说起来这又是一个新的坑，Google 是在 2019 年的 IO 大会宣布了把 Jetpack Compose 定义为 Android’s recommended modern toolkit for building native UI。然而，写惯了 findViewById 的我们，有可能刚刚学会用 ViewBinding，怎么这次直接上 Jetpack Compose 了？

从 Android 14 目前释放的代码来看，Google 新建了一个 spa 包，这个包里面尝试把“应用管理”、“应用通知管理”，还有“使用情况”页用 Jetpack Compose 重写了，这些页面几乎都是纯列表页面，拿它们优先下手理论上不会有太多坑，我猜 Google 也是这么考虑的？

除此之外，还有3个主页面也进行了重写，这三个页面本质上也是列表页：

出于稳健考虑，Google 没有默认使能这些页面。如果你想提前吃螃蟹，可以使用以下命令来开启： adb shell settings put global settings_enable_spa true 通过搜索代码，也可以轻松找到这个开关在哪里被使用：

然后我们可以去到相关页面看一下前后对比：

原生实现

Jetpack Compose 实现

由于 Jetpack Compose 的各个组件一直都在很好地践行 Material Design 3 ，可以看到后者的视觉还原要更好，也不会出现前者那样 MenuItem 背景颜色不正确的问题。

好了，让我们回到技术本身。其实我知道很多小伙伴拒绝学习 Jetpack Compose，本质上是拒绝学习声明性编程，一看到那种样式的代码就脑阔疼。而我完全理解你痛苦。就像当初学习 RxJava，好不容易从函数式编程过渡到了响应式编程，这次又来了一个新概念，确实内心是拒绝的。

其实编程思维的转变，说难也难，说简单也简单。回过头想一下，当初你看着别人写的 RxJava 代码，一气呵成，感觉很厉害的样子，其实本质上还是因为那个时候你没学会，看不懂 lambda，看不懂那些运算符是啥意思。等你后面学会了，再回过头来看，那种感觉跟初学的时候就完全不一样了。事实上，学习声明式编程也是如此。

SystemUI：使用架构最佳实践（Best Practise）重写

当看到这个标题的时候，你一定会觉得很晦涩，但我相信看到下面这张图，你一定不会感到陌生。

没错，这就是 Google 这几年一直在 App 开发层推崇的架构最佳实践。从 Android 14 开始，这套架构被引入 SystemUI 模块，用来解决之前状态栏各 item 的 Controller 和状态之间混乱不堪的问题。

对于 SystemUI 而言，状态栏的每一个 item，无外乎都关联着一个个回调，而回调进来的数据，往往都是外部对象，而 item 本身可能更关心的是自己的内部对象，并且状态一旦变了， UI 是一定要跟着变的，而这个需求恰好是这套架构最佳的使用场景。来看 Google 是怎么重构的：

近年来，Android App 应用开发已经从最开始那种兵荒马乱的年代，慢慢过渡到大家都开始重视应用架构了。从最开始的啥都往 Activity/Fragment 里塞，慢慢到后来有了 MVC，再后来到 MVP，现在又流行的 MVVM，Google 似乎最终也站稳了立场。

福利： Android Studio for Platform 要来了

文章最后带来一个好消息，那就是 Google 在今年总算良心发现，想起了我们这帮苦巴巴的搞 Android 框架的平台开发者，在继 AIDEGEN 之后，他们正在搞 Android Studio for Platform 。

从目前放出的预览图来看，整体应该至少是基于 IDEA 2022.3，因为默认启用了 NEW UI，然后平台开发会用到的应该都会支持，但何时能放出下载官方暂时还没有说，希望 Google 能好好搞，求别弃坑。

总结

写到这里，我想回到本文的标题，细心的读者会发现，我给”新技术栈的”新“字打了引号，为什么？因为对于那些关注技术发展，同时在 Android 应用层和框架层之间工作的同学来讲，这些其实早就不是新技术了，有些甚至可以说是应用层”玩剩下的“。为什么这些技术时至今日才被引入 Android 框架？我想无外乎还是为了追求稳定，就像当年 Kotlin 也是在社区，在 App 开发层火了好多年，Google 后面才参与进来，并最终引入框架一样，很多东西的可行性和稳定性也需要时间去验证。我个人很欣赏国外大厂在技术上的务实，不像国内很多厂商弄东西，还没稳定，或者还没经过时间验证，总是拿出来先吹为敬，可能也是大环境导致吧。

如果你还没有掌握Framework，现在想要在最短的时间里吃透它，可以参考一下《Android Framework核心知识点》，里面内容包含了：Init、Zygote、SystemServer、Binder、Handler、AMS、PMS、Launcher……等知识点记录。