劝学: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 编译强相关,只不过它碰巧支持构建 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

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 上还有进一步的演进,这个后面会提到。

我们很多搞框架开发的小伙伴,对于新技术似乎有种本能的排斥,大家的内心 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 引入了哪些“新”技术栈_第4张图片

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

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

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

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

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

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

原生实现

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

Jetpack Compose 实现

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

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

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

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

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

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

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

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

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

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

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

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

福利: Android Studio for Platform 要来了

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

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

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

总结

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

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

《Framework 核心知识点汇总手册》:https://qr18.cn/AQpN4J

Handler 机制实现原理部分:
1.宏观理论分析与Message源码分析
2.MessageQueue的源码分析
3.Looper的源码分析
4.handler的源码分析
5.总结

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

Binder 原理:
1.学习Binder前必须要了解的知识点
2.ServiceManager中的Binder机制
3.系统服务的注册过程
4.ServiceManager的启动过程
5.系统服务的获取过程
6.Java Binder的初始化
7.Java Binder中系统服务的注册过程

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

Zygote :

  1. Android系统的启动过程及Zygote的启动过程
  2. 应用进程的启动过程

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

AMS源码分析 :

  1. Activity生命周期管理
  2. onActivityResult执行过程
  3. AMS中Activity栈管理详解

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

深入PMS源码:

1.PMS的启动过程和执行流程
2.APK的安装和卸载源码分析
3.PMS中intent-filter的匹配架构

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

WMS:
1.WMS的诞生
2.WMS的重要成员和Window的添加过程
3.Window的删除过程

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

《Android Framework学习手册》:https://qr18.cn/AQpN4J

  1. 开机Init 进程
  2. 开机启动 Zygote 进程
  3. 开机启动 SystemServer 进程
  4. Binder 驱动
  5. AMS 的启动过程
  6. PMS 的启动过程
  7. Launcher 的启动过程
  8. Android 四大组件
  9. Android 系统服务 - Input 事件的分发过程
  10. Android 底层渲染 - 屏幕刷新机制源码分析
  11. Android 源码分析实战

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

你可能感兴趣的:(Framework,Android,移动开发,android,Android,移动开发,APP框架,framework)