📚 课程目录第2章 Compose重组日志分析

2、Compose重组日志分析：理解重组日志含义，使用key避免过度重组

做Compose开发，最怕什么？

界面卡顿、掉帧、莫名其妙的重绘。我刚开始接手一个大型项目时，光是一个列表滑动就卡得用户想骂娘。后来打开重组日志一看，好家伙，一个不该重组的卡片每帧都重画了三次。嗯，这就是我们今天要啃的硬骨头——理解重组日志，用key精准控制重组范围。

2.1 重组日志到底长什么样？

先别急着写代码。你得先能看到重组过程才行。我个人习惯在所有Compose模块的build.gradle.kts里加上这么一行：

// 在 build.gradle.kts 中
android {
    buildFeatures {
        compose = true
    }
    composeOptions {
        kotlinCompilerExtensionVersion = "1.5.4"
    }
    // 开启重组日志
    kotlinOptions {
        freeCompilerArgs += "-P"
        freeCompilerArgs += "plugin:androidx.compose.compiler.plugins.kotlin:recomposeHighlighter=true"
    }
}

重启IDE后运行App，你会看到组件被高亮——蓝色闪烁表示重组，红色闪烁表示测量/布局。说白了，这就是Compose的“心电图”。

在Logcat中过滤Compose:recompose，你能看到类似这样的日志：

Compose:recompose: MyComposable(123) -> recomposed 3 times
  Reason: state 'textState' changed at line 42
  Parent: ParentComposable(456) recomposed 1 times
  Child: ChildComposable(789) recomposed 2 times

每条记录告诉我们：谁重组了、重了几次、为什么重组的。有一次我在排查一个动画卡顿问题，就是靠这条日志发现一个全局状态被不小心传给了十几个子组件，导致每次点击都触发全部重组。改完以后帧率直接从20飙到60。

警告：重组日志在正式发布包中必须关闭。带上这个参数后编译器会注入额外代码，对性能有影响。上线前请设置isMinifyEnabled = true自动剔除或通过gradle区分build type。

2.2 日志字段全解析

表格里我把常见字段的含义整理了一下，你在实战中对着看就行：

日志片段	含义	给我的直觉
`MyComposable(123)`	被重组的组件名及其标识符	标识符每次运行都变，只用来区分不同实例
`recomposed 3 times`	这个组件在一帧内被重组的次数	超过1次就要警惕了，往往是不必要的
`Reason: state 'textState' changed`	触发重组的具体状态或参数	顺着这个名字去查代码里哪写了`by remember`
`Parent: ... recomposed 1 times`	父组件的重组情况	父组件是否也受了牵连
`Child: ... recomposed 2 times`	子组件受波及的次数	如果子组件不依赖那个状态，被重组就是浪费

小技巧：如果你发现某个组件在日志里频繁出现recomposed 2+次，大概率是key没用好。我一般先把所有@Composable函数内部用Layout Inspector抓一帧，再对着日志看——效率奇高。

2.3 过度重组的元凶：缺少key

想象一个列表：

@Composable
fun MessageList(messages: List<Message>) {
    LazyColumn {
        items(messages) { msg ->
            MessageItem(msg)
        }
    }
}

这段代码看起来没问题对吧？但你想想看，当列表中间插入一条数据时会发生什么？

没有key，Compose会按索引匹配，后面的所有Item都得重新重组。
有key，Compose只重组真正变化的那个Item。

我曾经在一个IM聊天界面上踩了这个坑。用户发送一条消息后，整个列表从底部到顶部全部闪蓝——重组日志显示每帧重组了上百次。加了key = { it.id }后，日志里只多了一条新Item的重组记录。

// 修复后：用稳定的唯一ID做key
LazyColumn {
    items(messages, key = { msg -> msg.id }) { msg ->
        MessageItem(msg)
    }
}

注意：key值必须稳定且不随重组变化。你想想，如果用Random.nextInt()做key，那每次重组key都不一样，Compose会认为是全新Item——干脆全部重建，性能反而更差。我见过一位同事用index当key，说是“省事”，结果列表拖拽时Item的图片乱跳，调试了一下午。

核心原则：key的目的是帮助Compose识别“哪个Item是同一个”。只要你觉得某个可组合项可能在列表顺序变化后依然需要保留状态，就给个key。我自己的经验是：凡是LazyList里的Item，一律给key；Column/Row里如果有条件动画切换，也值得加key。

2.4 不止是列表——Column、Row、AnimatedContent也需要key

很多人以为key只在LazyColumn里有用。其实Column、Row、AnimatedContent、Crossfade这类容器，在元素顺序或类型变化时同样依赖key。举个例子：

@Composable
fun ProfileScreen(user: User?) {
    Column {
        if (user != null) {
            Avatar(user.avatarUrl)
            NameTag(user.name)
            StatsPanel(user.stats)
        } else {
            LoadingIndicator()
        }
    }
}

当user从null变成非null时，Compose会把LoadingIndicator移除，再把三个新组件插入。如果这三个组件内部有remember状态，它们的生命周期完全由位置决定——万一以后顺序变了，状态就乱了。我建议你在这种分支切换的场景里也用key：

Column {
    if (user != null) {
        key("profile") {
            Avatar(user.avatarUrl)
            NameTag(user.name)
            StatsPanel(user.stats)
        }
    } else {
        key("loading") {
            LoadingIndicator()
        }
    }
}

这样Compose就知道“profile”和“loading”是两种完全不同的UI，不会尝试复用内部状态。日志里你会看到，切换时只重组一次，没有多余的残余状态。

2.5 知识脉络：一张图理清重组日志→找问题→用key解决

2.6 避坑指南：这些场景不加key会出事

列表中间插入/删除数据 – 不加key会导致后面所有Item重建，如果你的Item里有remember的输入框或动画状态，会全部丢失。
列表排序变化 – 比如你做了拖拽排序，没key的话Compose会认为每一个Item都变了，重组日志里全是闪烁。
条件分支切换 – 如上面ProfileScreen例子，不同UI加个key能保护内部状态独立。
动画过渡 – AnimatedContent默认根据targetState变化来切换，但如果你在Content里用了key，能让动画更精准地匹配旧组件和新组件，减少闪白。

最后送你一句我的经验：只要看到重组日志里某个组件在一帧内重组了超过一次，先检查它是不是在LazyList里；如果是，八九不离十是缺key。加完key再跑一遍日志，那种“哗——全绿”的爽感，你会爱上它的。