前面第 103 篇讲过 DSL 的三个语言特性，这一节把它们落到 Compose 上——因为 Compose 是 Kotlin 特性最集中的体现场：带接收者的 Lambda、@Composable 注解、编译器插件、状态模型。面试里问"Compose 和 Kotlin 什么关系"，答得浅的人说"Compose 是新的 UI 框架"，答得深的人会讲清楚编译器在其中做了什么。
先把结论放在前面：Compose 的"声明式"能成立，靠的正是上一节讲的 DSL 三特性（带接收者 lambda + 扩展函数 + 尾随语法），再叠加编译器插件提供的两项能力——①@Composable 函数可以被编译器追踪，生成"可重启、可跳过"的代码；②@Stable/@Immutable 让编译器知道哪些参数变化会触发重组。没有编译器插件，Compose 只是"写法好看"，不会有性能优势。
机制背后的执行路径
先看一个最小的 Composable 与它的编译产物：
@Composable
fun Greeting(name: String) {
Text(text = "Hello $name")
}
编译器把这个函数改写成类似这样的结构（伪代码）：
@Composable
fun Greeting(name: String, $composer: Composer, $changed: Int) {
val changedFlag = $composer.changed(name)
if (changedFlag or $composer.skipping) {
Text("Hello $name", $composer, $changedFlag)
}
}
三个要点：①参数与 Composer 一起传入，编译器能追踪"这次重组里哪些参数变了"；②$composer.skipping 允许跳过整个子树——这就是重组能省下来的机制；③Text 本身也是 Composable，调用被同样改写，形成一棵可追踪的树。
编译器还生成一张"组（group）表"记录调用顺序，使得重组时能按顺序快速定位变化的组，而不是整棵树重跑。
然后是稳定性（stability）这个关键概念。编译器给每个类推断稳定性：不可变且字段也是稳定的类是 stable，可变或有可变字段的是 unstable。@Immutable/@Stable 是人工覆盖。规则是：
- stable 参数变化 → 只重组该 composable
- unstable 参数变化 → 跳过优化，每帧都可能重组
这就解释了标题里那个坑的机理——传 List 给参数，如果这个 List 被当成 unstable（或每次传入新实例且无法证明相等），重组就会被放大。
真实工程场景的推演
场景一：重组范围的放大。列表项 composable 接收 List<Item> 参数，父层每次重组都 items.map { Row(item) } 生成新 List。即使内容相同，引用变了就会触发重组。修法：把重组边界往下推——用 key、items(items, key = { it.id }) 让 Compose 能做结构化复用；把与重组无关的 lambda 传下去（Modifier 稳定，但普通 lambda 捕获可变状态会变 unstable）。
场景二：remember 与 rememberSaveable。remember 只在首次组合时计算，配置变更（旋转）后重建 Composition 就会丢失；rememberSaveable 通过 Bundle/SavedState 保存，恢复后还在。这是"状态该放哪"的答案：跨重建要保存的用 rememberSaveable，纯派生值用 remember，跨界面共享的用 ViewModel。
场景三：副作用。LaunchedEffect(key)、DisposableEffect(key)、SideEffect 三者的区别正是"用 Kotlin 协程 + DSL 能力表达生命周期"。这是把 108 篇的 Channel/协程知识用上的地方。
场景四：状态容器。Compose 里 mutableStateOf 提供了快照（snapshot）机制：读取时记录当前快照，写入时通知该快照的观察者，实现"读谁触发谁重组"的细粒度更新。这是 Compose 相比传统 View 失效重绘的核心优势。
最常见的坑是
用不稳定的 List 参数导致列表整页重组，性能反直觉恶化。 修法三条：①把 data class 模型字段声明为 val 且集合用不可变类型，让编译器能推断为 stable；②LazyColumn 的 items 用 key 参数；③把与重组无关的逻辑用 remember 缓存，不要在组合阶段重复计算。
其次是在 Composable 里直接做重活（网络请求、复杂计算、文件读写）。修法：网络放 ViewModel（配合前面的 StateFlow），副作用用 LaunchedEffect 触发，重计算用 remember(keys) 缓存或 derivedStateOf。
还有一个更隐蔽的坑：传 lambda 参数时捕获了会变的状态，导致每次重组都是新 lambda。修法：把 lambda 提到 @Composable 之外或用 remember 稳定引用；能用 State 读的值就不要再通过参数传。
现场手写这一段就够了
// 1) 稳定性：@Immutable 让编译器跳过重组判定
@Immutable
data class UserUi(
val id: String,
val name: String,
val tags: List<String> // List 稳定，但字段需为 val
)
@Composable
fun Profile(user: UserUi) {
// user 是 stable → 变化才重组
Text(user.name)
}
// 2) 重组边界：把 lambda 与状态隔离
@Composable
fun Screen(state: State<ScreenState>) {
val onClick: () -> Unit = remember(state.value) {
{
navTo(state.value.id) } }
Button(onClick = onClick) {
Text("打开") }
}
// 3) remember / rememberSaveable 的选择
@Composable
fun Detail(id: String) {
val formatter = remember {
DateFormatter() } // 纯实例，首次组合创建
var draft by rememberSaveable {
mutableStateOf("") } // 跨重建保存
val derived = remember(id) {
computeExpensive(id) } // key 变化才重算
OutlinedTextField(value = draft, onValueChange = {
draft = it })
}
// 4) 列表：key 必给
@Composable
fun List(modifier: Modifier = Modifier) {
LazyColumn(modifier) {
items(items = ui.items, key = {
it.id }) {
item -> // ⚠️ 缺 key 会整页重建
Row(Modifier.fillMaxWidth()) {
Text(item.name) }
}
}
}
// 5) 副作用三选一：LaunchedEffect / DisposableEffect / SideEffect
@Composable
fun Timer(enabled: Boolean, onTick: (Long) -> Unit) {
LaunchedEffect(enabled) {
// 协程副作用，key 变则重启
while (enabled) {
onTick(System.currentTimeMillis()); delay(1000) }
}
DisposableEffect(Unit) {
// 需要清理的资源
val reg = registerListener()
onDispose {
reg.unregister() }
}
SideEffect {
log("组合完成") } // 每次重组后执行
}
// 6) 状态容器：快照实现细粒度更新
@Composable
fun Counter() {
val count = remember {
mutableStateOf(0) } // 读写有快照隔离
Column {
Text("count=$count") // 读 count → 订阅这处
Button(onClick = {
count.value++ }) {
Text("+") }
}
}
关键行解读：@Immutable 配合 val 让编译器推断 stable，从而跳过不必要的重组；remember 缓存 lambda 引用避免每次重组生成新对象；items(key = { it.id }) 让列表结构化复用；LaunchedEffect 用协程表达副作用、DisposableEffect 负责清理；mutableStateOf 读时记录快照、精准定位重组范围。
面试追问四连
"Compose 相比传统 View 有什么本质区别？" 答：传统是"命令式修改视图"，Compose 是"描述当前状态，框架计算差异"；伴随的是细粒度重组——状态读取点被追踪，只重算受影响的部分，而不是整棵视图树。
"@Composable 是怎么做到可跳过重组的？" 答：编译器改写函数签名，加入 Composer 与 $changed 参数，生成"参数是否变化"的判断与 $composer.skipping 短路；配合稳定性推断，只有 stable 参数变化才进入重组逻辑。
"@Immutable 和 StateFlow 什么关系？" 答：解决不同问题。@Immutable 是给编译器的承诺（"这个对象不会变，可以跳过重组"），StateFlow 是运行时的状态容器与订阅源。实践上常见组合：StateFlow<UserUi> 提供状态流，UserUi 用 @Immutable 让重组可跳过。
"为什么列表必须给 key？" 答：key 让 Compose 能区分"新增/删除/移动/内容变化"，从而只重组受影响的项并保持状态（如展开态、动画）。缺失 key 时按位置匹配，列表头部插入会导致后面所有项被当成内容变化，状态错位。
落地建议
1. 项目统一约定：UI 模型用 @Immutable data class + val + 不可变集合；不得在 Composable 参数里传可变对象。 2. review checklist 加入三条：列表是否给 key、是否用 remember 缓存昂贵对象与 lambda、Composable 内是否有重 IO。 3. 状态归属明确：跨界面共享 → ViewModel + StateFlow；界面内状态 → remember/mutableStateOf；需跨重建保存 → rememberSaveable。 4. 自动化预防：用 Compose 编译器插件的稳定性报告（reportsDestination）在构建时输出 unstable 类清单，把它们作为重构待办；性能侧用 Perfetto/Recomposer 的帧耗时做基线对比。
给正在准备面试的你 把这题画成"编译前 vs 编译后"的对比图。左侧画 Compose 源码（Greeting(name) → Text(...)）；右侧画改写后（Greeting(name, $composer, $changed) → if (changedFlag or $composer.skipping) → 递归调用 Text(..., $composer, ...)），用红色高亮标出"可跳过"的分支。再在旁边画一棵"重组树"示意：改动最底层节点时，只有从该点到根的路径参与重组，兄弟节点被 $composer.skipping 拦下。
再补一个高分追问答案："为什么 Compose 的性能有时反而不如预期？" 四类原因：①unstable 参数导致跳过失效（用稳定性报告定位）；②重组粒度过大（把 state.value 传给整层子树，应在读取点就地消费）；③组合阶段做重活（移到 LaunchedEffect 或 ViewModel）；④频繁状态变更（应做防抖/派发/合并）。这四条是"知道怎么查"的完整路径——面试官问"你怎么定位 Compose 性能问题"时，答出"稳定性报告 + Recomposer 计数 + 布局层与绘制层分开测"三层排查，就是资深答法。
复习时别孤立刷题：Kotlin 2.x 演进——上一节讲编译器插件与语言特性，本节讲这些能力在 Compose 场景下的具体收益，工具与落地正好互为印证。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：Kotlin-2.x-演进：K2-编译器带来了什么
下一篇预告：函数式编程思维：纯函数与副作用管理
有任何问题欢迎在评论区留言交流。
