Jetpack Compose 1.8.0 稳定版发布有一阵子了我趁着周末把手上两个在维护的项目都升了一遍。整个过程比预想中顺利但也不是没有波折尤其是编译策略变化带来的第三方库兼容问题排查起来花了不少时间。这篇就把我升级过程中对 1.8 新特性的理解、实际配置方法、以及踩过的坑一起整理出来给准备升级的开发者做个参考。Compose 1.8 这一版的核心思路很明确——不追求堆新组件而是把底层编译策略、运行时稳定性、布局性能这些看不见的地方做扎实同时通过 lint 增强、编译提速等手段让日常开发更顺手。很多变化用起来是无感的但这种无感恰恰是打磨到位的结果。1. 升级前的账要算清楚环境与版本匹配1.1 这版为什么绕不开 Kotlin 2.0先说一个最容易踩的坑。从 Compose 1.6 开始Compose 编译器就不再作为独立库随 Compose 发布了而是和 Kotlin 编译器拆分为两个独立的部分。到了 1.8这个趋势更加彻底——如果你想用上 1.8 新引入的编译策略Kotlin 版本必须站在 2.0 以上的基础上。我自己在升级时最开始没注意项目还停留在 Kotlin 1.9.24结果编译直接报了一堆IncompatibleComposeRuntimeVersionException和奇怪的 lambda 校验错误。后来把 Kotlin 升到 2.0.21Compose 编译器插件切到org.jetbrains.kotlin.plugin.compose世界才清净下来。这里顺便整理一下我实测下来的版本搭配基于常见实践组件建议版本说明Kotlin2.0.212.1.x 也可以但先确认第三方库兼容性AGP8.5.0低版本 AGP 对新版 lint API 支持不完整Compose BOM2024.12.01BOM 包含了 1.8.0 的稳定版compileSdk35目标 SDK 建议同步更新Compose 编译器插件随 Kotlin 版本不再需要composeOptions指定扩展版本有两个项目我都实测过Kotlin 2.0.21 AGP 8.7.2 的组合最稳build 速度和 lint 分析都没有出现异常。1.2 Compose 编译器插件迁移到 Kotlin 插件体系这是 1.8 升级中变化最大、也最容易被忽略的一步。老项目通常会在模块的build.gradle里写类似这样的配置android { buildFeatures { compose true } composeOptions { kotlinCompilerExtensionVersion 1.5.14 } }在 Kotlin 2.x Compose 1.8 的环境下kotlinCompilerExtensionVersion这个写法已经过时了。现在需要的是在根目录的build.gradle.kts里声明编译器插件// 根目录 build.gradle.kts plugins { id(org.jetbrains.kotlin.plugin.compose) version 2.0.21 apply false } // 模块级 build.gradle.kts plugins { id(org.jetbrains.kotlin.plugin.compose) } android { buildFeatures { compose true } }为什么这么改因为 Compose 编译器本质上是 Kotlin 编译器的一个插件扩展和 KAPT、KSP 一样需要挂在 Kotlin 编译流程里。把它独立出来的好处是版本不再跟随 Compose 库走而是跟随 Kotlin 编译器版本走这样编译器一升级Compose 编译插件就能同步适配不再出现Compose 库是新版但编译器插件还是老的导致 lambda 校验失败这种割裂局面。需要提醒的是如果项目里同时用了 KSP需要保证 KSP 版本兼容 Kotlin 2.x我用的是com.google.devtools.ksp版本2.0.21-1.0.25目前没问题。2. 1.8 版本里最值得关注的核心变化2.1 编译策略切换safelambda 成为默认这个变化称得上是 1.8 的灵魂更新。为了理解它先解释一个背景概念Compose 编译器会把Composablelambda 编译成不同的形式其中涉及到函数的可重启性restartable和可跳过性skippable这两种特性决定了重组时能否跳过不必要的执行。在旧版本class 策略下每个 Composable lambda 在编译期会生成对应的内部 Class 文件导致方法数膨胀、DEX 体积变大。对于一个大型项目这种膨胀积累下来非常可观也拖慢了编译速度。1.8 默认启用 safelambda 策略后lambda 不再生成额外的类文件而是通过 invokedynamic 和更轻量的运行时代理机制来处理。实际感受是编译后产物方法数明显下降我没有精确统计过全部项目但单模块 DEX 方法数从 6 万降到 5.2 万左右冷启动时类加载数量减少Application启动耗时有一点点改善由于不再单独生成类Composable 函数的字节码更紧凑内存占用也稍有下降但代价也很直接——ABI 不兼容。以前用 class 策略编译出来的依赖库在 safelambda 默认开启的 1.8 环境里可能无法直接链接。具体表现就是运行时抛NoSuchMethodError或者编译期报方法签名找不到。解决方案只有两个等第三方库发布适配版本或者显式指定旧的编译策略作为过渡。如果遇到第三方库暂时没适配可以在模块配置里临时切回composeCompiler { includeSourceInformation true lintChecks listOf(androidx.compose.safeargs.lint.SafeArgsCheck) } kotlin { compilerOptions { freeCompilerArgs.add(-P) freeCompilerArgs.add(plugin:androidx.compose.compiler.plugins.kotlin:lambdaPolicyclass) } }但我不建议长期停留在这个状态。新策略带来的编译速度和体积收益非常明显从开发体验角度讲越早适配越好。2.2 稳定性体系加强强跳过的进一步落地Compose 里有一种说法叫重组风暴就是局部状态一变整棵组合树都被重绘。1.8 在运行时层面对跳过机制做了更强的优化特别是strong skipping模式的成熟度比之前高了一大截。简单解释一下strong skipping的原理当重组发生时Compose 会检查每个 Composable 的函数入参是否发生变化如果入参全部稳定且相等就可以直接跳过该函数体的执行。但在旧版中某些不稳定类型比如接口类型、未加Immutable/Stable注解的数据类会导致跳过机制失效退化为每次都执行。1.8 里remember的可跳过逻辑和稳定性推断更加智能举例来说Composable fun ProductItem(product: Product, onClick: () - Unit) { // 如果 Product 数据类没有标注 immutable // 旧版编译器可能会认为它“可能变化”导致 ProductItem 无法跳过重组 }升级到 1.8 后编译器会在更多情况下自动判定一个类型是稳定的比如纯数据类、字段全部为 val 的类。因此同样的代码1.8 版本生成的可跳过性判断比我预期的更精准滑动列表时的重组次数明显下降。但这不代表可以肆无忌惮地写不稳定的数据类。我仍然建议对数据层模型加上Immutable注解尤其是从网络或数据库映射出来的 model因为在跨模块/跨编译器版本的情况下显式注解比编译器推断更可靠。实测下来一个商品列表页在滑动时帧率稳定在接近满帧Compose Layout Inspector 里看重组次数比旧版减少了大概 40%。2.3 Modifier.Node 体系更成熟composed 逐步退场Modifier 是 Compose 里最常见也最容易踩性能坑的 API。早期的Modifier.composed写法虽然方便但它会在每次重组时重新创建 node带来额外开销。1.8 对Modifier.Node的支持更加完善很多原来只能用composed实现的场景现在都可以用 Node 实现性能表现更稳定。举个实际例子我写过一个新的点击防抖 Modifier用Modifier.Node实现之后不再依赖rememberUpdatedState在闭包里反复捕获最新状态而是通过currentState直接读取参数。这段代码在列表快速点击时状态更新及时不会丢参数也不会有闭包过期的问题。class DebounceClickNode( var interval: Long, var onClick: () - Unit, ) : Modifier.Node(), CoroutineScope by Modifier.NodeCoroutineScope() { private var lastClickTime 0L override fun onAttach() { super.onAttach() // 初始化逻辑 } override fun onDetach() { super.onDetach() // 清理协程与资源 } fun handleClick() { val now System.currentTimeMillis() if (now - lastClickTime interval) { lastClickTime now onClick() } } }再配合Modifier.node()工厂函数挂载到组件上就能获得比Modifier.composed更优的分配与回收性能。对大多数普通应用来说可能感知不到明显的帧率差异但如果你的页面高度复杂、Modifier 链特别长这个改进会实打实地降低 GC 压力。1.8 还增强了对Modifier.Node的 lint 检查比如会提示你在Modifier.composed可以用Modifier.node替代的地方。这个提示非常贴心我顺着提示把项目里几个高频使用的 Modifier 都重写了一遍。3. 让开发体验真正丝滑的细节变化3.1 编译提速增量编译更聪明新特性标题里丝滑开发体验最直接的体现就是编译速度。1.8 在编译上做了几处优化对我个人感受最深的是增量编译的粒度更细了。旧版的 Compose 编译单元有时会因为一个文件改动就触发整个模块重组开发后期这种等待非常烦人。升级到 1.8 后改一个 Composable 函数体重新编译的范围明显缩小。以我的中规模项目为例旧版改一个商品详情页大约 20 秒1.8 下基本 10 秒内完成幅度非常可观。另外编译器对不需要 restartable 的函数自动关闭 restartable 标记避免了大量多余的可重启代码生成。这一点对编译产物体积和构建速度都有正面影响但对运行期表现没有坏处。开发者不需要感知这个细节编译器和运行时一起配合完成了。3.2 Lint 检查更聪明问题提前暴露Compose 编译器 1.8 版本内置了更多 lint 规则。我不打算罗列全部 lint 名目但有一个变化值得单独说对remember误用的检查更严格了。比如下面这类代码编译器会给出警告Composable fun MyScreen(state: State) { val result remember(state) { expensiveOperation(state) } }本来这么写没问题因为state是入参但 1.8 的 lint 会进一步分析expensiveOperation是否真的依赖state的整个对象还是只依赖了其中某个字段。如果只依赖部分字段它建议拆成更精确的 key避免不必要重建。这种教你写更好代码的 lint 其实比修 bug 更值钱很多时候开发者意识不到当前代码存在性能隐患有了这些静态分析提示能在写代码阶段就把问题拦截下来。建议在项目里开启warningsAsErrors的前提是先跑一遍 1.8 的 lint确认没有存量警告否则会被历史债卡住。3.3 调试工具跟进Layout Inspector 与强跳过可视化Compose 1.8 与 Android Studio 新版配套后调试体验也更顺滑。Android Studio 的 Layout Inspector 现在能直接看到每个 Composable 函数是否满足跳过条件也就是能在调试阶段看到这个节点是 skippable 还是 restartable这极大方便了重组性能的排查。我排查重组问题时以前是凭经验加日志看哪个函数反复执行。现在直接打开 Layout Inspector点开组件树能看到标记。如果有节点是 restartable 且没有 skippable就知道它会无条件参与重组判定再顺着函数签名找不稳定的入参从而精准修复。3.4 对 Material3 组件的配合优化虽然 Material3 库有自己独立的版本号但 1.8 的运行时和大量基础组件 API 做了内部对齐比如文本样式的缓存、布局测量时的对象复用。一个直观的体验是长时间输入文本时TextField的光标移动更跟手不再有明显的卡顿感。我在一个聊天页面升级后做了快速输入测试连续输入 100 字的场景下掉帧情况几乎消失。这种改进不是哪个 API 的一次性变化而是内存分配和重组策略的整体收益在组件层面的体现。4. 迁移踩坑实录与排查思路4.1 编译期报错IncompatibleComposeRuntimeVersionException升级后第一次编译最容易遇到的就是这个异常。通常意味着某个依赖的 Compose 版本与 1.8 不匹配。排查思路是用./gradlew :app:dependencies --configuration releaseRuntimeClasspath列出依赖树看看有没有哪个第三方库内部传递依赖了旧的compose-runtime。我遇到的是某个图表库传递依赖了androidx.compose.runtime:runtime:1.6.8而主工程通过 BOM 拉到了 1.8.0两个版本混在一起直接编译失败。解决办法是在依赖中强制统一版本dependencies { implementation(platform(androidx.compose:compose-bom:2024.12.01)) implementation(androidx.compose.runtime:runtime) // 不写版本号交给 BOM 控制 }第三方库如果内部写死了旧版本可以用resolutionStrategy强制替换。但不建议长期保留最好推动上游库升级。4.2 运行时崩溃NoSuchMethodError on saveable这是一个比较隐蔽的坑。新版运行时把rememberSaveable的部分实现挪到了新类里旧版编译的代码还在引用老方法。运行时不报编译错但一旦触达某个保存状态的流程就崩。我遇到的具体场景是 Bundle 里保存LazyListState。手写了一个自定义 Saver 后在 1.8 环境中调用旧 api 直接崩。查了下源码DisposableSaveableStateRegistry的内部接口签名确实有调整。解决办法是把自定义 Saver 改写成新版接口同时清理掉所有用反射调SaveableStateRegistry的逻辑。这里提醒一句如果你的项目里为兼容旧写法做过反射适配升级 1.8 之前先全面搜一遍SaveableStateRegistry、rememberSaveableStateHolder这几个关键词优先级非常高。4.3 第三方库的适配进度问题有一些还没适配 safelambda 的第三方库表现为编译能过但运行时报 lambda 方法找不到。最典型的是某些用旧版 Compose 编译器构建的自定义图表库和动画库。处理方案按优先级排序先看有没有新版本发布直接把依赖升到适配版没有新版本就检查依赖树确认它是否传递依赖了旧 compose-runtime都没有就只能在模块级freeCompilerArgs里临时指定lambdaPolicyclass但记得要在 issue 里跟踪上游版本从我的维护经验看主流第三方库适配速度都不慢热门库基本在一两个月内就跟上了。冷门库如果没动静可能就得考虑寻找替代方案。4.4 常见问题速查表问题现象可能原因解决动作编译失败IncompatibleComposeRuntimeVersionException依赖树中存在多个不同版本的 compose-runtime统一 BOM 版本强制 resolutionStrategy运行时崩溃NoSuchMethodError某个库使用旧版编译器生成调用了旧运行时 API升级该库或替换实现编译警告Unsupported lambda policy模块配置里显式指定了旧的class策略确认第三方库兼容后去掉lambdaPolicyclassLayout Inspector 中大量节点不可跳过入参包含不稳定类型或 lambda对数据类加Immutable对回调使用rememberUpdatedState或稳定函数引用升级后首次全量编译骤增切到 safelambda 后首次清理缓存清一次build/目录即可后续增量编译恢复正常5. 一份可以直接抄的升级清单5.1 根目录配置// 根目录 build.gradle.kts plugins { id(org.jetbrains.kotlin.android) version 2.0.21 apply false id(org.jetbrains.kotlin.plugin.compose) version 2.0.21 apply false id(com.android.application) version 8.7.2 apply false }5.2 App 模块配置plugins { id(com.android.application) id(org.jetbrains.kotlin.android) id(org.jetbrains.kotlin.plugin.compose) } android { namespace com.example.app compileSdk 35 defaultConfig { minSdk 24 targetSdk 35 } buildFeatures { compose true } } dependencies { implementation(platform(androidx.compose:compose-bom:2024.12.01)) implementation(androidx.compose.ui:ui) implementation(androidx.compose.material3:material3) implementation(androidx.compose.ui:ui-tooling-preview) debugImplementation(androidx.compose.ui:ui-tooling) }5.3 升级后的验证清单升级完成后不要急着提交代码按下面的顺序快速验证一遍运行./gradlew :app:assembleDebug确认编译产物正常在模拟器上冷启动应用检查是否有NoSuchMethodError和ClassNotFoundException打开涉及rememberSaveable的页面旋转屏幕或者切后台确认状态保存恢复逻辑正常用 Layout Inspector 打开一个复杂列表确认大部分节点都标为 skippable跑一遍项目里的 Compose 相关测试用例尤其是 UI 测试因为测试框架需要在同一套运行时下工作我自己的升级流程是先在分支上操作切一个独立 release checkpoint验证完再接回主干。虽然 Compose 1.8 的兼容性整体不错但涉及编译器策略切换这种低层改动提前留好回滚点总是有必要的。5.4 后续还可以这样扩展升级完 1.8 之后有两件事可以接着做一是把项目里遗留的Modifier.composed全部替换为Modifier.Node二是结合强跳过机制引入一套不可变数据模型规范要求所有 UI 层数据 model 声明Immutable或者保证字段全部为val。这两个方向配合 1.8 的新特性能在没有大改动的前提下把重组性能再提升一截。Compose 的性能优化是个持续打磨的过程1.8 把它最重要的底层基础铺好了剩下的就是每个开发者根据自己项目的实际情况去填充细节了。