Jetpack Compose LazyColumn性能及离屏项渲染机制相关疑问

1. 发射Composable成本低的原因，以及不使用Column全量渲染的理由 #

为什么发射新Composable成本低且性能好 #

• Composable本质是带状态的纯函数调用，没有Android View实例化的厚重开销：不需要解析XML布局、不需要初始化View的上百个默认成员变量、不需要注册各类默认触摸/焦点回调，编译器还针对重组做了大量编译期优化，多数场景下无额外对象分配，执行成本和普通函数几乎一致。
• Compose重组是完全增量的，仅参数发生变化的Composable才会重新执行，滚动时新出现的列表项仅需执行自身的函数逻辑，不会影响其他已渲染的项，性能损耗极低。

为什么不直接用Column一次性渲染全量列表 #

哪怕单个Composable成本再低，全量渲染所有列表项的开销会随列表长度线性上涨：所有项无论是否在可见区域，都需要完整走完重组、测量、布局、绘制全流程，同时所有项的状态和渲染节点都会常驻内存。如果列表有上千甚至上万条数据，直接用Column渲染会直接导致卡顿、内存暴涨甚至OOM，而LazyColumn只会处理可见区域 + 少量预缓存区域的项，不管总长度多大，始终只维持十几到几十个项的计算和内存开销，性能稳定性要高得多。

2. 滚动时不可见列表项的处理逻辑 #

你举的示例场景中，当滚动到可见项为5-14时，滚出屏幕的0-4项对应的渲染节点（LayoutNode）和关联的Composition状态都会被直接丢弃，不会常驻内存。当用户回滚到顶部时，这部分项会重新执行对应的Composable函数完成重组渲染。

有两个细节需要注意：

• LazyColumn默认会在可见区域上下保留少量预加载缓存项，避免快速滚动时出现空白，这部分缓存项哪怕暂时不可见也不会被立即清理，只有滚出缓存范围才会被丢弃。
• 如果你需要保留列表项的状态（比如用户输入的内容、展开折叠状态），可以通过rememberSaveable或者业务层ViewModel存储对应状态，即使项被销毁后重新渲染也能恢复之前的状态。

内容的提问来源于stack exchange，提问作者Karim Ata