[Android 从零到一] Compose LazyColumn 性能优化：key、稳定性与重组治理

原创

hunter android

发布于 2026-08-17 15:07:50

100

LazyColumn 是 Compose 中处理长列表的核心组件，但很多项目在列表数据更新时会出现闪烁、滚动卡顿或不必要的重组，根本原因往往集中在三个问题上：key 配置错误、数据类型不稳定、重组作用域过大。本文从实际问题出发，梳理这三条治理链路，并给出可以直接落地的方案。

key 的作用与错误配置

LazyColumn 的 key 参数告诉 Compose 如何识别列表中的每一个条目。当数据列表发生更新（增删改位移）时，Compose 依靠 key 决定哪些条目可以复用状态、哪些需要销毁重建。

没有 key 时发生什么

LazyColumn {
    items(users) { user ->
        UserItem(user)
    }
}

未指定 key 时，Compose 默认按位置索引区分条目。列表头部插入一个新条目后，所有条目的位置都会偏移，Compose 认为每个位置上的"条目"都发生了变化，触发全量重组。如果 UserItem 内部有动画或焦点状态，全部会丢失。

正确配置 key

LazyColumn {
    items(users, key = { it.id }) { user ->
        UserItem(user)
    }
}

用唯一且稳定的 ID 作为 key，Compose 可以精确追踪每个条目的移动和复用，只对真正发生变化的条目触发重组。

key 的类型限制

key 必须是可序列化到 Bundle 的类型（Int、Long、String 等原始类型或其包装类），因为在配置更改或进程重建时，LazyColumn 需要恢复滚动位置。如果用自定义对象做 key 且未实现 Parcelable，滚动状态恢复会静默失败。

// 错误：自定义对象无法序列化到 Bundle
items(users, key = { it }) { ... }

// 正确：使用 Long 类型 ID
items(users, key = { it.id }) { ... }

数据类型稳定性与重组触发

Compose 在判断是否跳过重组时，会检查传入参数是否"稳定"。不稳定的类型会导致 Compose 无法跳过重组，即使数据实际上没有变化。

什么是稳定类型

Compose 认为以下类型是稳定的：

所有原始类型及其包装类（Int、String、Boolean 等）
用 @Stable 或 @Immutable 标注的类
所有属性都是稳定类型的 data class（满足条件时 Compose 编译器会自动推断）

普通 data class 为什么可能不稳定

data class User(
    val id: Long,
    val name: String,
    val tags: List<String>   // List 是不稳定类型
)

标准库的 List 是不稳定类型，因为 Compose 无法判断它是否是可变列表。只要 User 包含 List<String>，Compose 编译器就会把整个 User 标记为不稳定。

解决方案有两种：

方案 A：使用 kotlinx.collections.immutable

// build.gradle.kts
implementation("org.jetbrains.kotlinx:kotlinx-collections-immutable:0.3.7")

data class User(
    val id: Long,
    val name: String,
    val tags: ImmutableList<String>
)

方案 B：用 @Immutable 显式标注

@Immutable
data class User(
    val id: Long,
    val name: String,
    val tags: List<String>
)

@Immutable 是向 Compose 编译器的承诺：你保证这个类的所有属性在创建后不会改变。如果承诺被打破（用可变 List 并在外部修改），重组行为会变得不可预测。

用 Layout Inspector 验证稳定性

Android Studio 的 Layout Inspector 在 Compose 模式下可以显示每个 Composable 的重组次数和跳过次数（Recompositions / Skips）。打开 Live Updates，滑动列表触发更新，观察 UserItem 的 Skips 列——如果 Skips 始终为 0 说明从未被跳过，需要排查稳定性问题。

重组作用域治理

即使 key 和稳定性都配置正确，重组作用域过大仍会带来性能损耗。Compose 的重组是按作用域（Composable 函数边界）进行的，一个函数内部任意状态发生变化，整个函数都会重组。

条目内部的状态隔离

@Composable
fun UserItem(user: User) {
    // 问题：expanded 变化会重组整个 UserItem
    var expanded by remember { mutableStateOf(false) }
    Column {
        Text(user.name)
        if (expanded) {
            Text(user.bio)
        }
        Button(onClick = { expanded = !expanded }) { Text("展开") }
    }
}

将展开状态下沉到子 Composable：

@Composable
fun UserItem(user: User) {
    Column {
        Text(user.name)
        ExpandableSection(bio = user.bio)
    }
}

@Composable
private fun ExpandableSection(bio: String) {
    var expanded by remember { mutableStateOf(false) }
    if (expanded) {
        Text(bio)
    }
    Button(onClick = { expanded = !expanded }) { Text("展开") }
}

expanded 的变化只会触发 ExpandableSection 重组，Text(user.name) 不受影响。

避免在 items lambda 中直接读取顶层状态

// 问题写法：整个 LazyColumn 依赖 selectedId，selectedId 变化触发全量重组
val selectedId by viewModel.selectedId.collectAsState()
LazyColumn {
    items(users, key = { it.id }) { user ->
        UserItem(user = user, isSelected = user.id == selectedId)
    }
}

用 derivedStateOf 把选中状态的计算隔离到条目级别：

LazyColumn {
    items(users, key = { it.id }) { user ->
        UserItem(user = user, selectedIdProvider = { selectedId })
    }
}

@Composable
fun UserItem(user: User, selectedIdProvider: () -> Long) {
    val isSelected by remember(user.id) {
        derivedStateOf { user.id == selectedIdProvider() }
    }
    // 仅 isSelected 结果变化时才重组，不受 selectedId 频繁变化影响
    ...
}

derivedStateOf 使得只有 isSelected 的结果发生变化时才触发 UserItem 重组，而不是每次 selectedId 改变都穿透进来。

Modifier 稳定性与 contentType

避免在 items lambda 内创建新的 Modifier 对象

// 每次重组都会创建新的 Modifier 实例，破坏相等性检查
LazyColumn {
    items(users, key = { it.id }) { user ->
        UserItem(
            user = user,
            modifier = Modifier.padding(horizontal = 16.dp)
        )
    }
}

将固定的 Modifier 提升到外部或用 remember 缓存：

val itemModifier = remember { Modifier.padding(horizontal = 16.dp) }
LazyColumn {
    items(users, key = { it.id }) { user ->
        UserItem(user = user, modifier = itemModifier)
    }
}

contentType 的分组优化

当列表包含多种条目类型时，配置 contentType 可以让 Compose 只在同类型条目间复用，避免跨类型复用导致布局重建：

LazyColumn {
    items(
        items = feedItems,
        key = { it.id },
        contentType = { it.type }
    ) { item ->
        when (item.type) {
            FeedItemType.POST -> PostItem(item)
            FeedItemType.AD   -> AdItem(item)
        }
    }
}

完整落地示例

@Immutable
data class User(
    val id: Long,
    val name: String,
    val avatar: String,
    val bio: String,
    val tags: List<String>
)

@Composable
fun UserListScreen(viewModel: UserListViewModel = hiltViewModel()) {
    val users by viewModel.users.collectAsState()
    val selectedId by viewModel.selectedId.collectAsState()
    val selectedIdProvider: () -> Long = { selectedId }

    LazyColumn(
        modifier = Modifier.fillMaxSize(),
        contentPadding = PaddingValues(vertical = 8.dp)
    ) {
        items(
            items = users,
            key = { it.id },
            contentType = { "user" }
        ) { user ->
            UserItem(
                user = user,
                selectedIdProvider = selectedIdProvider
            )
        }
    }
}

@Composable
fun UserItem(
    user: User,
    selectedIdProvider: () -> Long,
    modifier: Modifier = Modifier
) {
    val isSelected by remember(user.id) {
        derivedStateOf { user.id == selectedIdProvider() }
    }

    Card(
        modifier = modifier
            .fillMaxWidth()
            .padding(horizontal = 16.dp, vertical = 4.dp),
        colors = CardDefaults.cardColors(
            containerColor = if (isSelected)
                MaterialTheme.colorScheme.primaryContainer
            else
                MaterialTheme.colorScheme.surface
        )
    ) {
        Row(
            modifier = Modifier.padding(12.dp),
            verticalAlignment = Alignment.CenterVertically
        ) {
            AsyncImage(
                model = user.avatar,
                contentDescription = null,
                modifier = Modifier.size(48.dp).clip(CircleShape)
            )
            Spacer(Modifier.width(12.dp))
            Column {
                Text(user.name, style = MaterialTheme.typography.titleMedium)
                ExpandableBio(bio = user.bio)
            }
        }
    }
}

@Composable
private fun ExpandableBio(bio: String) {
    var expanded by remember { mutableStateOf(false) }
    Column {
        if (expanded) {
            Text(bio, style = MaterialTheme.typography.bodySmall)
        }
        Text(
            text = if (expanded) "收起" else "展开",
            style = MaterialTheme.typography.labelSmall,
            color = MaterialTheme.colorScheme.primary,
            modifier = Modifier.clickable { expanded = !expanded }
        )
    }
}

排查路径小结

遇到 LazyColumn 性能问题时，按以下顺序排查效率最高：

Layout Inspector → Recompositions/Skips：找到重组频繁的条目
检查 key：是否配置、是否用 ID 而非对象引用、类型是否可序列化
检查数据类型稳定性：data class 是否含有不稳定字段（List、Map 等）
检查重组作用域：状态读取是否集中在顶层而非下沉到子 Composable
检查 derivedStateOf：派生状态是否做了隔离，避免上游频繁变化穿透到条目

每一步都有对应的工具和代码模式可以落地，不需要依赖直觉猜测。LazyColumn 是 Compose 中处理长列表的核心组件，但很多项目在列表数据更新时会出现闪烁、滚动卡顿或不必要的重组，根本原因往往集中在三个问题上：key 配置错误、数据类型不稳定、重组作用域过大。本文从实际问题出发，梳理这三条治理链路，并给出可以直接落地的方案。