2023 年 Google I/O 已于 2023 年 5 月 10 日 拉开帷幕,Android 14 Beta 版本近期也已经 释放 到 Google partners,本文主要分析 Google 在 Android 14 框架代码中引入了哪些新的技术栈,而对于新功能和 API Change,则并不在本文的讨论范围之内。
说到编译,对于独立应用而言,大家接触最多的应该是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
。
Kotlin
Google 在 2017 年的 IO 大会上将 Kotlin 定义为 Google 官方支持的开发语言,时至今年,大部分 App 开发者都已经切过来了。然而,Android 框架开发者很多似乎还对这门语言嗤之以鼻,或者换句话说,平时用不到,再加上 Google 似乎一直没在框架里过多使用,所以暂时也没有学的必要。
很”遗憾“,在 android 14 的 Settings 模块,我们开始看到了 Kotlin 的影子。自此,搞框架 App 开发的同学失去了最后一个不学 Kotlin 的借口。
事实上,Settings 模块并不是第一个吃螃蟹的,头部的 SystemUI
模块,早在 2018 年就开始用 Kotlin 改写部分模块了,而且这次 android 14 上还有进一步的演进,这个后面会提到。
我们很多搞框架开发的小伙伴,对于新技术似乎有种本能的排斥,大家的内心 OS 无外乎:
希望看到这篇文章的小伙伴,平时千万不要有以上这些想法。我们的认知永远都是有限的,很多时候你这样想,很可能只是因为没有看过别的模块而已,别的模块说不定早就卷入新的技术栈了,就等着弯道超车呢。
怎么办?怎么办?怎么办?
学!Kotlin 怎么学,这个……这么多年了,网上太多教程了,不说了。
说起来这又是一个新的坑,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
,看不懂那些运算符是啥意思。等你后面学会了,再回过头来看,那种感觉跟初学的时候就完全不一样了。事实上,学习声明式编程也是如此。
当看到这个标题的时候,你一定会觉得很晦涩,但我相信看到下面这张图,你一定不会感到陌生。
没错,这就是 Google 这几年一直在 App 开发层推崇的架构最佳实践。从 Android 14 开始,这套架构被引入 SystemUI
模块,用来解决之前状态栏各 item 的 Controller
和状态之间混乱不堪的问题。
对于 SystemUI
而言,状态栏的每一个 item,无外乎都关联着一个个回调,而回调进来的数据,往往都是外部对象,而 item 本身可能更关心的是自己的内部对象,并且状态一旦变了, UI 是一定要跟着变的,而这个需求恰好是这套架构最佳的使用场景。来看 Google 是怎么重构的:
近年来,Android App 应用开发已经从最开始那种兵荒马乱的年代,慢慢过渡到大家都开始重视应用架构了。从最开始的啥都往 Activity
/Fragment
里塞,慢慢到后来有了 MVC
,再后来到 MVP
,现在又流行的 MVVM
,Google 似乎最终也站稳了立场。
文章最后带来一个好消息,那就是 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……等知识点记录。
https://qr18.cn/AQpN4J
Handler 机制实现原理部分:
1.宏观理论分析与Message源码分析
2.MessageQueue的源码分析
3.Looper的源码分析
4.handler的源码分析
5.总结
Binder 原理:
1.学习Binder前必须要了解的知识点
2.ServiceManager中的Binder机制
3.系统服务的注册过程
4.ServiceManager的启动过程
5.系统服务的获取过程
6.Java Binder的初始化
7.Java Binder中系统服务的注册过程
Zygote :
AMS源码分析 :
深入PMS源码:
1.PMS的启动过程和执行流程
2.APK的安装和卸载源码分析
3.PMS中intent-filter的匹配架构
WMS:
1.WMS的诞生
2.WMS的重要成员和Window的添加过程
3.Window的删除过程
https://qr18.cn/AQpN4J