浅谈2022Android端技术趋势，什么[值得]学？-CFANZ编程社区

浅谈2022Android端技术趋势，什么[值得]学？_android

引言

回头去看 2021，过的似乎那么快，不敢相信我已经从事 Android 开发两年了，不免生出一些感叹。

那么 2022 ，Android 端会有什么技术趋势吗？或者什么 [新] 技术值得去学? 又或者对我来说，现在什么 [值得] 去学？

本文将通过我个人的技术学习经历去分析我们应该怎么选用某个技术，希望对大家能有所帮助。

回头看

让我们把时间切回过去，最近几年我都给自己加了哪些技术点？

2019-2020

Kotlin，协程
MVP，Hilt，MVVM ,JetPack 相关
热修复
Flutter 浅试
自动化、持续集成相关

2021-2022

JetPack Compose
Epoxy+Mvrx , MVI

看完这个表，是不是惊叹于，我靠，你小子 2021 等于啥都没学啊？

说来尴尬，当我自己从博客记录从翻阅时，也有这份感叹，对于 [新技术] ，真的好像没怎么看了，所以在年终总结上，我发出了这样一句感叹，今年用的组件都是以前学过的，只不过忘了，又翻出笔记看了一眼。

但仔细又想了下，2021新技术真的好像没有多少，对于 Android 端而言，Compose 算一击重拳，而 MVI 又是最近因为 Compose 被正式启用为 Google 推荐 [新] 架构标准，其他的好像真的没有。

Google今年推过的技术

如果我们只将技术定义为 [技术组件] ，那就可能太狭义，所以那就细细列举一下今年 Google 推过的那些技术文章：

如何找到呢，那么 Android开发者 公众号就是最优先的。所以我们就通过其发布过的文章，大致统计一下，Android 官方给我们的建议，我排了一个表，大致如下:

JetPack

Navigation 、Hilt、WorkManager、ActivityResult
Compose 、Wear OS-Compose 、Wear Os-卡片库
WindowsManager、Room、Paging3.0、Glance - Alpha

折叠屏，大屏适配推荐了很多次，Android12 上也推了几次
KotlinFlow、协程
Android12行为变更、隐私安全更新、新的 小组件widget
安全方面数据加密与生物特征、App 合规
Android 启动相关App Startup、延迟初始化
CameraX
Material Desgin

按照推荐频率，我将它们分别列在了上面，总共上面这几大类。不难发现，JetPack 仍然是 Android 官方首推，然后就是折叠屏以及不同屏幕的适配，接着就是 Kotlin 与 Android12 ,当然今年因为 合规 方面的各种问题，Android团队 对于安全方面也提到了，最后就是和性能以及 UI 相关的一些推荐。

趋势预测

折叠屏与大屏适配

严格上这个其实不算是一项技术，而是一项适配工作。但是一直以来，对于大屏的适配，Android 上基本做的很少。自从三星推出第一个折叠屏之后，这个适配就开始被重视起来了。

厂商方面，目前 oppo,华为，小米也都纷纷推出自己的折叠屏手机，以满足先行市场。

官方支持度 方面，如果看过今年的 IO 大会，就会发现，折叠屏适配已经被专门放到了一个栏目，而且专门讲解，官方公众号也已经推了多次。

所以我们姑且可以认为，折叠屏适配应该是2022的一个趋势，但目前对于折叠屏的适配的主流App其实还没有多少,更多的也都是厂商做了相关适配，app开发方面专门针对改动做的其实并不多。

所以可见在2022随着折叠屏手机机型的愈来愈多，某些关键业务的全面适配工作也将随之展开，而不是现在仅仅只是在折叠的时候，同时存在两个APP，或者某个页面展示在另一个屏幕。

技术支持方面，Android团队为此专门准备了一个新的 JetPack 组件，JetPack WindowManager，其主要功能就是监听屏幕的折叠状态，以及当前相应的屏幕信息，目前主要以可折叠设备为目标，不过未来将支持更多屏幕类型及窗口功能，现在处于 rc 版本，当然今年也肯定会推出稳定版。

JetPack Compose

Compose 自从发布第一个稳定版本后，在今年的 IO 大会上也有专门的分区去讲。

其是用于构建 原生Android 的一个 工具包 ，以 声明式 写法，搭配 Kotlin,可大大简化并加快原生的 UI 开发工作。

目前 Compose 已经对如下几个方面做了支持：

Android UI 支持
Wear 可穿戴设备支持
Android Widget 小组件支持

非官方方面，jetbrains 也对桌面版，以及网页做了相关支持，具体见：Compose Multiplatform

桌面版目前已经发布了正式版本1.0.1

得益于 Compose 的声明式开发，使得其做折叠屏适配也是较为简单。在与原生 View 的交互上，Compose 支持的也非常不错。

所以我们可以认为，2022，如果从事原生开发，那么 Compose 势必是一个比较适合你学习的新技术，它的上手难度并不大，只要你熟悉Kotlin ,也就能很快上手，只不过目前其在ide上的预览功能比较慢，还有待后续优化。

Kotlin

协程

协程其实在前几年已经被广泛使用，我第一次使用协程是在2020年，也见证了其逐渐替代 AsyncTask 及相关线程池工具的过程。

Flow

Flow 今年来被 Android团队 推荐了多次，其主要以协程为基础构建，某种意义上而言，我个人觉得其似乎有点替代 RxJava 的意思。得益于 Kotlin 的强大与简洁，Flow 今年出现最多的场景反而是 Android团队 推荐其用于替代 LiveData ,以增强部分情况下的使用。

当然 Flow 不止于此，如果你正在使用 Kotlin ,并且协程用的也比较多，那么 Flow 肯定是绕不开的一个话题。

所以我们可以预估，在2022，协程与 Flow 依然值得学习，并且也是能很快感受到效益的组件。

但是相比协程，Flow 其实还有很长一段时间要走，毕竟常见开发场景里，LiveData 就可以满足，而 Flow 却显得不是那么必需。

ASM

这项技术其实并不新奇，但是因为其本身需要的前备知识挺多，比如 Android打包流程 ，APK打包流程，字节码，自定义 Gradle 插件，Transform API ，导致细分为了好多领域，大佬们依然在热追，而像我这样的菜鸟其实还是一脸吃瓜。

那为什么我认为其是一个技术趋势呢？

主要是合规带来的影响，大的环境下，可能以后打包时，我们都会监测相应的权限声明与隐私调用，否则如何确保后续的改动不会导致违规呢？但如何确定某个 sdk 没有调用？而且我们也不可能每次都让相关第三方去检测。

所以，维护一个相应的监测组件，是大环境下的必需。而实现上述插件最好的方式就是 Hook 或者 ASM ，所以如果你目前阶段比较高，ASM 依然是你避不开的技术选题。

什么[值得]你去学？

这个副标题其实有一点夸张，但仔细想想，其实就是这样，我们应该明白，到底什么是更适合自己当下学习的。

以我个人为例，大家可以从中体会一下，自己应该关注哪些技术，当然,我个人的仅只能作为和我一样的同学做参考：

就像最开始说的，其实这些新组件，很多我都已经用过或者记录过，在最开始的两年，我一直在追寻组件越新越好的道路上，所以每当新出一个组件，总会在项目中进行实践，去尝试。

但是我也逐渐发现了一些问题，当经历了[使用工具]的这个阶段，当我要去解决某些特定情况下问题时，突然发现，自己似乎什么都不会，或者就只会基础，比如：

在集成某些 gradle 插件时，如果要满足 CI 下的一些便捷，要去写一些 Task 去满足动态集成，而自己对 Gradle 仅仅处于Android常见使用阶段，这时候就需要去学相关；
我自己也会维护一些组件库，当使用的同学逐渐增多，大家提到的问题也越来越多，那如何解决这些问题，如何优雅的兼容，组件的组合方式，如何运用合适的设计模式去优化，这些又是我需要考虑的问题；
当我们开始对音视频组件进行相关时，此时又出现了很多方向，最终的方案选型也是需要你再次进入一个未知领域，从0到0.1；

新技术会让我当前编码变得开心，能节省我很多事，但其不能解决一些非编码或者复杂问题，而这些问题，是每个同学前进道路上也都会遇到的，所以我们常常会看到，做 Android 真难，啥都要会。

总体对我而言，今年会主要将一些精力放在如下几个方面：