Google 的 Android Jetpack 新库发布节奏，哪些值得追

Google 的 Android Jetpack 新库发布节奏，哪些值得追

上个月把项目里的 Kotlin 版本从 1.9.0 升到 1.9.22，本来只是例行升级，想着小版本号能出什么岔子。结果 CI 直接挂掉，Compose Compiler 抛出来一行红字：e: This version (1.5.8) of the Compose Compiler requires Kotlin version 1.9.22 but you appear to be using Kotlin version 1.9.10。我盯着这行报错看了半天，突然意识到这已经成了 Jetpack 新库的常态——Google 在前面飙车，开发者在后面捡零件。Jetpack 这些年的发布节奏，尤其是 Compose、CameraX、Media3 这一批新库，早就不是"值不值得追"的问题，而是"追不追得上"的问题。

Compose Compiler：Kotlin 版本的"紧箍咒"

Compose 的问题不用多说，Google I/O 上年年吹，文档里句句夸，实际落地到项目里，最大的拦路虎往往不是@Composable的学习曲线，而是那个躲在幕后、脾气极差的 Compose Compiler。它跟 Kotlin 版本的绑定关系，几乎到了病态的地步。

Compose Compiler 1.4.x 严格锁死 Kotlin 1.8.x，1.5.x 系列又必须精准匹配 Kotlin 1.9.x 的每一个小版本。你想试试 Kotlin 1.9.20 的新语法？可以，先去看看 Compose Compiler 1.5.2 的发布说明，确认它对上了。手滑把 Kotlin 升级了 0.1 个版本号，整个构建链路直接崩溃，错误信息还写得像审讯笔录，摆明了告诉你："是你先动的手。" 更讽刺的是，其他 Jetpack 库从来没这毛病。Room 2.6.0 不在乎你用 Kotlin 1.8 还是 1.9，WorkManager 2.9.0 也不会因为你切了 Kotlin 版本就罢工。唯独 Compose，像一个被宠坏的孩子，要求全家围着它转。

这种强绑定的理由，Google 工程师在 Issue Tracker 上解释过，说是为了确保编译期插桩的稳定性。这个技术理由我认，但工程代价是不是太高了点？现实情况是，一个中等规模的 Android 项目，Kotlin 版本往往不是团队能独立决定的。如果依赖的某个 SDK（比如某厂的视频编解码库、某金融安全组件）内部也绑了特定 Kotlin 版本，你就得在"用最新 Compose 特性"和"第三方 SDK 不冲突"之间做选择。这种二选一的局面，本不该出现在一个号称"现代 UI 工具包"的库身上。

而且 Compose 的版本矩阵本身也是一团乱麻。Compose Compiler、Compose Runtime、Compose UI、Foundation、Material3，这些库理论上可以混用不同版本，但谁敢真这么干？Material3 从 1.0 到 1.2 把主题配色 API 改了个底朝天，BottomSheet 的行为在 1.1 和 1.2 之间完全不是同一个实现。你要是 Compiler 用 1.5.8、UI 用 1.6.0、Material3 用 1.2.0，构建是能过，运行时出来什么妖孽就只能听天由命了。Google 的版本发布节奏快得像是 KPI 驱动，每两个月一个版本号往上跳，但真正的稳定性却没人背书。我现在处理 Compose 升级，已经养成了癖好：必须等到某个版本发布至少六周、GitHub issue 区骂声小下去之后，才敢往主分支合。

CameraX：三年 beta 骑脸，stable 难等

如果说 Compose 的问题是版本绑定太死，那 CameraX 的问题就是 stable 承诺太假。这个库从 2019 年 I/O 登场，口号喊得震天响："让 Camera2 的开发变得简单。" 结果 1.0.0 stable 拖到了 2021 年才正式发布，中间的 alpha 和 beta 周期里，API 改得像过家家。

`ImageAnalysis.set