Jetpack Compose 1.8 稳定版在 2025 年上半年正式落地我没有任何犹豫就把手头两个项目的构建流程全部切了过去。倒不是我喜欢尝鲜而是 1.8 这代版本解决的几个问题恰好是这两年我在生产环境里被反复折磨的痛点Kotlin 版本与 Compose 编译器的版本绑定、重组频率过高导致的卡顿、文本输入状态难以管理、以及预览调试不给力。这篇文章就围绕这些变化聊聊实际体验。如果你是正在观望升级的 Android 开发者或者刚接触 Compose 1.8、想知道它到底强在哪这篇应该能给你一份比较完整的参考。1. 升级前必须理解的编译架构变化1.1 为什么 Kotlin 2 把 Compose 编译器“收编”了先说这个最容易被忽略、实际影响最大的变化。在 Compose 1.8 对应的时代Compose 编译器已经以 Kotlin 编译器插件的形式被直接整合进 Kotlin 2.x 的发布体系里不再是独立的androidx.compose.compiler版本。这意味着我们不用再像以前那样为了找一个和 Kotlin 版本完全匹配的kotlinCompilerExtensionVersion而翻官方兼容表了。以前的老配置长这样android { buildFeatures { compose true } composeOptions { kotlinCompilerExtensionVersion 1.5.4 } }但凡 Kotlin 升到 1.9.22Compose 编译器就可能还没跟上编译直接报版本不兼容。社区里的经典场景是Kotlin 版本升了编译器版本还是旧结果项目里各种“编译器插件与 Kotlin 版本不匹配”的红字。到了 Compose 1.8配置变成了这样plugins { id(org.jetbrains.kotlin.plugin.compose) }这个org.jetbrains.kotlin.plugin.compose插件随 Kotlin 版本一起发布。也就是说你升级 Kotlin 的时候Compose 编译器插件也跟着走不会再有版本错位的问题。我升级时最直观的感受就是以前三步一踩的“版本配不上”彻底消失了。1.2 新老配置对比与迁移命令迁移并不复杂但有几个小坑值得说清楚。你要做的第一步是在根目录的build.gradle.kts里加上插件声明plugins { id(org.jetbrains.kotlin.plugin.compose) version 2.1.20 apply false }然后在所有需要写 Composable 的模块里声明plugins { id(org.jetbrains.kotlin.plugin.compose) }同时删掉composeOptions块把 Kotlin 版本提到 2.1.20 以上并把 Compose BOM 升到包含 1.8 的版本例如2025.06.01。这里有一个容易漏的地方如果你之前还在用kotlinCompilerExtensionVersion配置删除后如果不同步清理缓存Gradle 增量编译可能会保留旧的编译器类路径导致偶发编译错误。建议改完配置后执行一遍./gradlew clean不要偷懒。从我的实测来看升级到新编译器架构后单模块的干净编译时间大概减少了 20% 到 30%。这个提升主要来自 K2 编译器本身对前端分析过程的优化加上 Compose 编译器作为插件直接嵌在 Kotlin 编译链路里少了一层中间转换和数据交换。对大型项目来说这个收益非常可观CI 构建耗时能明显降下来。2. 默认开启的强跳过模式丝滑从重组开始2.1 重组剔除是怎么回事Compose 的核心理念是状态驱动 UI。状态一变组合函数就可能重新执行。但“重新执行”不等于所有代码都得从头跑一遍Compose 有一种跳过机制如果调用点的参数没有变化就直接复用上一次的组合结果不再进入函数体。在 1.8 之前这种跳过对参数类型有一个很硬的要求参数必须是稳定类型同时值相等判断要靠谱。如果参数是不可变的普通数据类但你没有标注Immutable或StableCompose 会默认把它当成不稳定类型每次重组都不做跳过判断老老实实执行整段函数。这在列表长、页面层级深的时候非常容易造成不必要的重组表现出来就是滑动掉帧、UI 更新迟钝。强跳过模式改变的是判断逻辑只要参数值没有变化就对整个 lambda 和参数做跳过判断。它不再像以前那样严格要求类型被显式标注为稳定而是通过更聪明的推断把那些不可变但没标注的普通类也纳入可跳过的范围。说句大白话以前重组就像每次做饭都从洗菜开始哪怕菜没动过也要重来一遍强跳过模式则是先看一眼菜是不是原样放着没动过就直接起锅烧油。2.2 稳定性判定与配置实战在 Compose 1.8 里强跳过模式默认是开启的不需要额外配置。部分项目如果之前用了一些不规范的写法比如在 Composable 内部直接改了传入的集合内容或者依赖了可变全局变量开启强跳过模式后可能会暴露问题。如果你需要临时关闭它可以在模块的composeCompiler配置块里设置composeCompiler { strongSkippingMode false }不过我建议慎关因为关了之后性能又会回到老样子。更好的做法是修问题代码而不是牺牲性能保兼容。稳定性配置这块也有新玩法。你可以准备一个stability.conf文件将项目里一批已知稳定的类直接写入配置减少手动加注解的负担composeCompiler { stabilityConfigurationFiles.add(stability.conf) }比如你的项目里有很多第三方返回的 DTO 类它们实际上是不可变的但你没权限给源码加注解这时在stability.conf里声明它们的全限定类名就能让编译器把它们当稳定类型处理。我在一个老项目里维护着几十个这样的类实测写入配置后列表滚动的重组计数明显下降帧时间更稳定。关于调试Android Studio 的 Layout Inspector 已经支持显示每个 Composable 的重组次数和跳过次数。打开后你会看到每帧有重组、有跳过如果某个节点的重组次数一直没收敛多半是稳定性判断出了问题。我见过最典型的现象一个图标明明没变化每次列表滚动都接着重组最后发现是它接收了一个()- Unit类型的新 lambda导致调用点不可跳过。3. 状态管理新 API从 Flow 到 Observable 一次拿捏3.1 rememberObservableState 解决什么问题Compose 1.8 带来的新状态 API 中rememberObservableState算是最让人惊喜的一个。它主要解决的是项目里已经存在RxJava、Swing或者自有观察者模式数据源时如何优雅地订阅并转成 Compose 状态。以前拿到一个ObservableT想让它驱动 UI最常用的做法是在DisposableEffect里手动订阅再把值塞到mutableStateOf里。代码写起来大概这样val result remember { mutableStateOfString?(null) } DisposableEffect(Unit) { val disposable repository.userName .subscribe { result.value it } onDispose { disposable.dispose() } }这段逻辑本身不复杂但每个 Observable 都要重复写一遍订阅、赋值和清理而且生命周期稍微复杂一点就很容易忘记dispose造成内存泄漏。新 API 可以直接这样写val userName by rememberObservableState( observable repository.userName ) { it?.displayName ?: }它会在组合进入时自动订阅离开时自动取消订阅省掉了DisposableEffect样板代码。更重要的是它把订阅结果直接以State的方式暴露给 Compose 快照系统后续的重组和值更新不需要额外的手动赋值。3.2 collectAsState、rememberObservableState 怎么选很多朋友会问这个新 API 和collectAsState、collectAsStateWithLifecycle有什么区别。它们不是竞争关系而是针对不同数据源的适配。API数据源生命周期处理适用场景collectAsStateKotlin Flow无跟随组合生命周期简单 Demo、不关心 Activity 状态collectAsStateWithLifecycleKotlin Flow跟随 Lifecycle 的 STARTED 状态生产环境推荐rememberObservableStateRxJava/Swing/Observable自动订阅与释放遗留 RxJava 项目、非 Flow 数据源我的建议是新项目尽量以Flow collectAsStateWithLifecycle为主老项目如果还有大量RxJava代码不需要急着全部重写用rememberObservableState过渡非常平滑。尤其是新版 Compose 对普通Observable的支持并不是包装一层 Flow而是直接监听并同步到快照系统省了一次转换开销在频繁更新场景下的性能表现还要好一些。另外produceState依然可以用来封装基于回调的异步数据源。比如你想从LocationManager拿位置信息就可以用produceState包一层回调但如果数据本来就是Observable形式rememberObservableState明显更合适。4. 文本输入重构TextFieldState 时代4.1 老的 TextField 到底卡在哪Compose 的文本输入从早期就被吐槽原因是它把文本值、选区状态、输入法交互、光标控制全部混在一起API 虽然灵活但用起来很痛苦。以自动搜索框为例你既要监听TextFieldValue的变化又要维护一个单独的搜索关键词状态还要处理输入法弹起后的滚动位置稍不注意就在不同状态之间来回同步出现输入丢字、光标乱跳的问题。老的BasicTextField在重构前内部依赖了一套和 Android 平台EditText强绑定的输入服务跨平台复用时很别扭。而且每次输入一个字符整个文本状态对象都会重新创建导致周围 Composable 跟着重组。在一些需要频繁输入的长列表场景下这种重组成了一笔不小的性能开销。4.2 新 BasicTextField 上手Compose 1.8 把TextFieldState推向了稳定新的BasicTextField用法很直接val textFieldState rememberTextFieldState(initialText Hello) BasicTextField( state textFieldState, textStyle TextStyle(fontSize 20.sp) )TextFieldState把文本、选区、光标、IME 状态统一收进了一个对象里输入过程中的内部更新被局域化不再频繁触发整棵组件树重组。在实际项目里我试着把一页内容表单迁移到新 API输入响应明显更跟手键盘弹起时的跳帧也少了很多。迁移时要注意几个点。老代码里用TextFieldValue做初始值的地方如果直接换成TextFieldState(initialText ...)语法层面没问题但你要注意TextFieldState并不等价于TextFieldValue它更偏向于一个管理输入状态的容器读取当前文字需要通过state.text.toString()。同时如果你在写双向绑定逻辑新 API 不推荐再同时传value和onValueChange而是直接操作state否则两个入口竞争行为会很奇怪。我建议在升级后先挑一个不重要的输入页测试把TextFieldValue相关代码全部换成TextFieldState跑一遍回归。重点看光标移动、选中复制粘贴、IME 唤起与关闭、以及旋转屏幕后的状态保留这几个场景最容易出问题。5. 开发体验升级预览、检查器、调试都在变顺5.1 预览不再“只可远观”Compose 1.8 在预览上的改进配合新版 Android Studio已经不只是看静态布局那么简单了。Preview支持的参数更丰富可以直接预览不同主题、字体缩放、动态配色下的效果同时交互式预览也变得更加实用点击、输入、滑动这类操作能直接在预览窗口里做不用每次改代码都部署到模拟器或真机。我自己的习惯是给关键页面写多个不同状态下的Preview比如一个用户信息卡片分别预览加载中、加载失败、有数据三个形态。以前这样搞代码里要写一堆辅助 Composable而且预览区偶尔渲染更新不及时还得手动刷新。现在交互式预览加入后页面跳转、按钮反馈这类逻辑可以在编辑器里直接探索明显减少了“改几行代码就跑一次真机”的频率。对于团队协作来说这个提升价值很高。设计师和开发兄弟对着一台手机讨论方案的日子少了直接在预览窗口里调状态、看交互沟通成本低一截。如果你还没升级 Studio建议一并升到最新稳定版体验差异非常明显。5.2 Layout Inspector 里看重组与跳过调试 Compose 性能Layout Inspector 已经是很重要的工具。Compose 1.8 把重组计数、跳过统计显示得更清楚点开某个 Composable可以直接看到它这一帧是重组了还是跳过了以及最后一次重组产生自哪个状态读取。实际操作中我用它排查过一个典型的列表卡顿问题。页面里有一个高频更新的进度条按理说只影响进度条自己的重组但 Layout Inspector 显示整个列表item都跟着重组。一路追下去发现item构造函数里有个参数是onProgressChange: (Int) - Unit每次父 Composable 重组都会新建 lambda导致子项判断依赖变化没法跳过。解决办法很简单用rememberUpdatedState包一下回调或者把 lambda 提升到更高层级复用。这类问题以前靠猜现在直接看重组树就能定位。另外Layout Inspector 对Modifier.onPlaced、Modifier.layout这类低层 API 的调用也提供了更好的信息展示能看到完整的布局链路过中间结果。对于做自定义布局、排查尺寸异常的场景省了很多人肉推演的时间。6. 动画与 Material3视觉交互的最后一公里6.1 共享元素转场稳定了Compose 1.8 里让人期待已久的共享元素转场从一个实验性 API 走向了稳定。以前在两个页面之间做一套图片和文字的平滑过渡必须要自己用AnimatedContent、Box和位移计算去拼代码量不小而且动画过程容易闪烁、错位。现在通过SharedTransitionLayout和sharedElement修饰符就能搞定SharedTransitionLayout { AnimatedContent(targetState currentPage) { page - when (page) { is Page.Grid - GridView( onItemClick { currentPage Page.Detail(it) } ) is Page.Detail - DetailView( item page.item, onBack { currentPage Page.Grid } ) } } }在 Grid 页面里给卡片图片加上modifier.sharedElement(image-${item.id}, image)在 Detail 页面也给同一张大图加上相同的 keyCompose 会自动计算两帧之间的位置和尺寸变化生成很自然的过渡效果。这个特性在做图片浏览、商品详情、聊天头像放大这类场景时非常出效果。不过要提醒一点共享元素转场稳定不等于所有布局组合都完美。LazyColumn中同时滚动和共享元素转场时容易因为目标页面的测量时点不同步导致闪一下建议把转场元素放在页面盒尽量高的层级避免嵌套在clip或graphicsLayer下。真机上测试过渡帧率如果发现掉帧考虑把共享元素上的复杂shadow和border临时去掉。6.2 Material3 组件补齐Compose 1.8 配合 Material3 组件库把一批原本缺失的常用组件补得七七八八。SearchBar搜索栏终于有了规范的组件和交互模型带展开状态、输入框和下拉列表的联动DatePicker、TimePicker拾取器支持更多自定义选项PullToRefreshBox下拉刷新可以作为标准组件直接接入列表。我实际感受最明显的是日期选择以前要接一个第三方日历控件UI 风格很难和应用的 Material3 主题完全一致现在直接用官方DatePicker加一点DatePickerColors配置视觉和交互都很自然。PullToRefreshBox的接入也简单包住列表并监听刷新状态就行。不过这些新组件的 API 里有不少参数还带实验性注解生产环境使用时需要OptIn(ExperimentalMaterial3Api::class)。在升级时先扫一下现有代码里有没有同名组件冲突比如某些项目自己封装过SearchBar、DatePicker切到官方组件后记得删除自定义实现避免两套逻辑在同一页面里打架。7. 升级实操记录与避坑清单7.1 我的升级步骤这里给一份我实际执行过的升级清单基本顺序排过优先级能少走弯路升级 Android Gradle Plugin 到 8.5 以上太老的 AGP 对 Kotlin 2.1 支持不够。把 Kotlin 版本升到 2.1.20并添加org.jetbrains.kotlin.plugin.compose插件。删除各模块的composeOptions配置。升级 Compose BOM 到包含 1.8 的版本同时把 Material3 升到 1.4。全局搜索并处理编译警告特别注意已被标记废弃的旧BasicTextField重载。执行./gradlew clean跑一遍编译和单元测试。先在一个非核心业务模块联调测试再放量到全部模块。第 5 步容易忽略。Compose 1.8 对老 API 的废弃警告比之前更多但不影响编译很多人就留在那不管。问题在于后续升级到 1.9 时废弃 API 可能被直接移除到时候再改就是一堆代码大改。趁着 1.8 升级的机会顺手清理长期看收益很高。7.2 常见问题速查表我把升级过程中和社区里高频出现的问题整理成一张速查表遇到能秒定位问题现象可能原因解决方式编译报错Compose compiler 与 Kotlin 版本不匹配还在用旧kotlinCompilerExtensionVersion改用org.jetbrains.kotlin.plugin.compose删除composeOptions运行崩溃找不到rememberObservableStateCompose BOM 实际未到 1.8检查 BOM 版本确认各 compose 依赖统一列表滑动反而更卡强跳过模式被显式关闭查看composeCompiler.strongSkippingMode恢复默认开启某个 Composable 一直重组lambda 参数不稳定每次新建用rememberUpdatedState或提升 lambda 到可复用层级输入框变为只读或光标异常新旧TextFieldState与TextFieldValue混用统一用TextFieldState不要同时传value与onValueChange交互式预览无法点击Android Studio 版本过旧升级到支持 Compose 1.8 的 Studio 稳定版共享元素转场出现闪烁共享元素处于LazyColumn或嵌套裁剪层内尽量将共享元素放在页面顶层去掉多余graphicsLayer编译期出现非稳定参数警告自定义类未被标注稳定使用stability.conf或加Immutable注解最后再分享一个小技巧升级完 Compose 1.8 后不要急着把所有特性都用到现有代码里。先拿一个功能相对独立的页面把文本输入迁移到TextFieldState列表数据源改用新的状态 API并加上共享元素转场跑一遍完整流程。我这样试完之后最大的感受是开发逻辑变清晰了状态、输入、动画各管各的组件的边界感强很多。等你实际把玩过 Compose 1.8 这些新东西大概率也会有回不去的感觉。