Google 通过 R8 加速 Android 协程路径
Google 表示，Android 开发者升级到 Android Gradle Plugin 9.2.0 或 R8 9.2.0 后，可以获得更快的协程启动和取消路径。在 2026 年 7 月 27 日发布的文章中，Android Toolkit 工程师 Andrei Shikov 和 R8 团队工程师 Jonathan Starup 解释说，当编译器能够证明相关模式是安全的时，R8 现在会把大多数 Atomic*FieldUpdater 调用优化为开销更低的 Unsafe 变体。
这项变化主要面向大量使用 Kotlin 协程的 Android 代码。Google 称，它对 kotlinx.atomicfu 影响明显，而该库为 kotlinx.coroutines 提供原子操作支持；协程的启动和取消速度最高可提升 2 倍。最容易感受到变化的是频繁创建短生命周期协程的 UI 路径，包括 Jetpack Compose 的 effect 和交互处理。
这个瓶颈为何出现
Android Developers 的文章描述了一次 Compose 性能调查：在方法跟踪中，协程的创建和销毁成本变得很明显。Google 以 Modifier.clickable 为例称，在相关优化工作之前，创建和更新这个 modifier 的大部分时间都消耗在为 InteractionSource 更新启动和取消内部协程上。
开销来源并不只是协程逻辑本身。文章指出，kotlinx.atomicfu 使用 JVM 原语 AtomicReferenceFieldUpdater 来实现无锁原子操作。这类 updater 依赖运行时字段名和类引用，因此在真正执行底层原子操作之前，需要进行反射访问检查。在 Google 基于 Pixel 5、API 33 的 benchmark 中，kotlinx.atomicfu 的 compare-and-set 路径为 135 ns，而 AtomicReference 为 50.7 ns，Google 将其描述为约 2.7 倍的差距。
R8 改变了什么
R8 已经是 Android release 构建管线中的全程序优化器。R8 项目将其描述为一种读取 Java 字节码并为 Android 应用生成优化后 DEX 的工具。正是这种全程序视角，让编译器能够识别静态上足够明确的 updater 模式。
在可优化的情况下，R8 可以保持有效 updater 的语义，同时把重复的 updater 调用替换为基于字段 offset 的直接 Unsafe 操作。Google 将实现分为三个阶段：插桩、替换和清理。R8 会引入 offset 字段，重写符合条件的调用点，保留必要的 null 行为，并在所有使用点都可优化时移除不再需要的 updater 初始化。
需要注意的是，这并不是对所有反射式 atomic updater 的统一重写。文章称，R8 面向的是编译器可以安全追踪 updater、holder 类型和字段类型的大多数调用。无法满足这些条件的动态场景仍可能保留原路径。
为什么 Compose 开发者需要关注
Compose 依赖协程来处理受控副作用。Compose 文档说明，LaunchedEffect 进入 composition 时会启动一个协程，离开 composition 时会取消它；当 key 改变时，已有协程会被取消，并启动新的协程。这个生命周期很有用，但也意味着协程启动和取消成本会出现在 UI 密集型工作负载中。
Google 称，在更新 R8 后，Compose runtime 的微基准测试中，LaunchedEffect 的协程启动和取消获得了 2 倍提升。与此同时，Android Runtime 团队也在虚拟机层实现相关优化。Google 的文章称，如果应用面向 API 37 并运行在较新的 Android 版本上，可能已经能看到类似的 VM 侧行为；其协程 benchmark 在最近的 ART JIT 更新后观察到约 15% 的性能提升。
接下来该怎么做
对以 Kotlin 为主的 Android 应用团队来说，下一步很直接：在构建约束允许时，规划升级到 AGP 9.2.0，或直接使用 R8 9.2.0。收益最可能出现在协程密集路径中，尤其是 Compose 交互和 effect；但开发者仍应在自己的应用中测量，因为改进取决于热点路径是否使用了可被优化的 atomic updater 模式。
这是一项编译器和 runtime 层面的改进，而不是新的 API。只要构建使用新的 R8 路径，并且相关代码模式符合优化条件，现有协程和 Compose 代码就有机会受益，而无需进行应用层重写。