📚 课程目录第3章 Item复用机制

Item 复用机制：ViewHolder 复用逻辑、key、contentType 与避免重建

LazyColumn 在滚动时不会为每一个可见项创建全新的 Composable 实例，而是通过 slot 复用 机制（类比 RecyclerView 的 ViewHolder）减少对象分配和重组开销。理解这一机制是优化首屏渲染的关键。

ViewHolder 复用逻辑在 Compose 中的映射

概念	传统 RecyclerView	Compose LazyColumn
复用单元	ViewHolder（持有 View 引用）	LayoutNode + SlotTable 条目
缓存池	RecycledViewPool（按 type 分区）	内部 Slot 池（按 contentType 分区）
复用条件	itemViewType 一致	contentType 一致 + 相同 key
重复绑定	onBindViewHolder()	重组时调用 Composable 函数

LazyColumn 在滚动出屏幕后不会销毁 item 的 Composable，而是将其放入 slot 池。当新 item 进入视口时，优先从池中取出已存在的 LayoutNode，然后在其上执行重组（复用状态的子节点）。

key 的作用与设置

key 用于标识每个 item 的唯一性。未设置 key 时，LazyColumn 会使用 item 的索引作为隐式 key。这会导致列表项位置变化（增删、排序）后发生错误的复用与重组。

  正确用法：为列表数据提供稳定且唯一的 key，通常使用数据对象的 id。

// 错误：使用索引，当列表增删时复用错乱
LazyColumn {
    items(myList.size) { index ->
        ItemView(data = myList[index])
    }
}

// 正确：使用数据 ID 作为 key
LazyColumn {
    items(myList, key = { it.id }) { item ->
        ItemView(data = item)
    }
}

设置 key 后，Compose 会通过 key 比对 来决定是复用现有 Composable 还是重建。若 key 未变化，即使数据 content 变化，也只是原地重组；若 key 变化，则视为新 item。

contentType 区分不同类型 item

当列表中存在多种 UI 布局时（例如图片类型与文本类型），必须设置 contentType，否则不同布局的 slot 会互相复用导致高度错误的布局结果，甚至触发不必要的完整重建。

LazyColumn {
    items(
        items = mixedList,
        key = { it.id },
        contentType = { it.type }  // "image" 或 "text"
    ) { item ->
        when (item.type) {
            "image" -> ImageItem(item)
            "text"  -> TextItem(item)
        }
    }
}

contentType 内部原理： LazyColumn 为每种 contentType 维护独立的 slot 池。当某个类型的 item 被回收时，只进入同类型的池中，后续只有同类型的 item 才能从该池中取出复用，从而保证 LayoutNode 结构与所需布局兼容。

机制可视化

避免不必要的重新创建

不合理的 key 和 contentType 会导致 LazyColumn 频繁执行 slot 新建，增加首屏绘制时间。以下是常见优化实践：

始终提供稳定的 key（如数据库 id），避免使用 hashCode() 或随机数。
为不同类型 item 显式设置 contentType，即使类型只有一种时也建议指定，便于 Compose 优化 slot 分配策略。
避免在 item 函数内部使用 lambda 作 key：key = { it.hashCode() } 每次重组都可能变化，导致重建。
利用 contentType 减少池碎片：尽量将高度相似的布局合并为同一 contentType，避免过多小池降低复用率。

调试技巧：在 Layout Inspector 中查看 LazyColumn 的 slotCacheSize 和 itemRecompositionCount。若某类型 item 的 slot 数量远大于可见项，说明复用未生效，应检查 key 或 contentType 设置。

// 反例：未设置 key 且未设 contentType，导致每个 item 都可能新建
LazyColumn {
    items(data) { item ->
        when (item.type) {
            "a" -> TypeA(item)
            "b" -> TypeB(item)
        }
    }
}

// 正例：key + contentType 明确
LazyColumn {
    items(
        items = data,
        key = { item.id },
        contentType = { item.type }
    ) { item ->
        when (item.type) {
            "a" -> TypeA(item)
            "b" -> TypeB(item)
        }
    }
}

常见错误与稳定性验证

错误场景	现象	验证方法
未设置 key，列表发生删减	动画错乱、item 内容错误闪现	删除中间项后观察保留的 item 是否变化
key 使用可变字段（如时间戳）	每次重组都重建所有 item，卡顿	用 Profiler 查看 Recomposition count
contentType 缺失，多类型混用	布局高度异常、UI 闪烁	快速滚动并观察布局错位
contentType 粒度太细（每个数据都不同）	slot 池碎片化，复用率为 0	检查 slot 池数量是否接近 item 总数

稳定性验证流程：

使用 LayoutInspector 或 Compose Compiler Metrics 记录 Recompositions 和 Skipped 计数。
在列表中间删除一条记录：应只有被删除项之后的 item 发生重组，且重组次数等于列表长度减一。
测量连续 10 次滚动 100 项的平均帧时间：FrameTiming 应平稳，无突然 spike。

正确实现 Item 复用机制后，LazyColumn 在首屏渲染时可以复用已有的 LayoutNode，将创建新 Composable 的开销转化为简单的重组，显著缩短测量/布局阶段耗时，从而提升首屏展示速度。