劝学:Android 14 Framework 引入了哪些“新”技术栈

作者:Mr_万能胶

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 编译强相关,只不过它碰巧支持构建 JavaC++GoKotlin 等语言,而 Android 开发也基本使用上述这些语言。另外,对 Rust, Python 的支持也在逐渐被加入,Google 对 Bazel 的开发还是十分积极的。

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第1张图片

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第2张图片

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

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

怎么办?怎么办?怎么办?

学!怎么学?看官网!官网给我们提供了非常丰富的例子,不管你的项目是 Java 的,还是 Kotlin 的,常见的问题,比如第三方库怎么引用,NDK 项目怎么配置等,都能找到依葫芦画瓢的答案。

Settings:Kotlin 和 Jetpack Compose 都来了

开始迁移到 Kotlin

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

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第3张图片

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第4张图片

我们很多搞框架开发的小伙伴,对于新技术似乎有种本能的排斥,大家的内心 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 也是这么考虑的?

劝学:Android 14 Framework 引入了哪些“新”技术栈_第5张图片

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第6张图片

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第7张图片

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第8张图片

原生实现

劝学:Android 14 Framework 引入了哪些“新”技术栈_第9张图片

Jetpack Compose 实现

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

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第10张图片

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

怎么办?怎么办?怎么办?

学!幸运的是,Google 给我们提供了详细的指导,大家可以参考 developer.android.com/jetpack/com…来快速入门上手。而且,这波 Google 自己带节奏,不学看起来是真的不行了。

SystemUI:使用架构最佳实践(Best Practise)重写

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第11张图片

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

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第12张图片

劝学:Android 14 Framework 引入了哪些“新”技术栈_第13张图片

劝学:Android 14 Framework 引入了哪些“新”技术栈_第14张图片

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

怎么办?怎么办?怎么办?

学!关于 app 架构最佳实践 的详细内容,可以参考 Google 官网的这篇介绍。需要注意的是,要想更方便地运用这套结构,依赖注入(DI) 往往是必不可少的,SystemUI 其实很早就在用依赖注入了,目前依然是 Dagger,而其实 Google 这几年一直在推进他们基于 Dagger 演变的 Hilt,这是一套更适合 Android 平台的依赖注入框架,大家可以从这里了解到具体详情。另外,Kotlin 协程,和对数据流(Flow)的理解也是必不可少的,这部分大家也可以参考官网。

我的个人建议是,大家先学习依赖注入(DI),再学习 Kotlin Flow,最后再回过头来入门这套架构,这套学习路线应该是比较正确的。

福利: Android Studio for Platform 要来了

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

劝学:Android 14 Framework 引入了哪些“新”技术栈_第15张图片

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

总结

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

Android 学习笔录

Android 性能优化篇:https://qr18.cn/FVlo89
Android 车载篇:https://qr18.cn/F05ZCM
Android 逆向安全学习笔记:https://qr18.cn/CQ5TcL
Android Framework底层原理篇:https://qr18.cn/AQpN4J
Android 音视频篇:https://qr18.cn/Ei3VPD
Jetpack全家桶篇(内含Compose):https://qr18.cn/A0gajp
Kotlin 篇:https://qr18.cn/CdjtAF
Gradle 篇:https://qr18.cn/DzrmMB
OkHttp 源码解析笔记:https://qr18.cn/Cw0pBD
Flutter 篇:https://qr18.cn/DIvKma
Android 八大知识体:https://qr18.cn/CyxarU
Android 核心笔记:https://qr21.cn/CaZQLo
Android 往年面试题锦:https://qr18.cn/CKV8OZ
2023年最新Android 面试题集https://qr18.cn/CgxrRy
Android 车载开发岗位面试习题:https://qr18.cn/FTlyCJ
音视频面试题锦:https://qr18.cn/AcV6Ap

你可能感兴趣的:(逆向,移动开发,Android,android,移动开发,音视频,Framework,逆向)