Jetpack Compose列表高频重组是否会严重影响应用性能？

核心判断逻辑：重组次数本身不是性能问题的唯一判定标准，要结合重组发生的场景、重组范围、单帧总耗时综合判断，你已经实际感知到滚动卡顿的前提下，这个重组频率是需要重点排查的性能疑点。

• 先明确debug模式统计的偏差：Debug构建下Compose会插入额外的状态追踪、调试检测逻辑，统计到的重组次数会比release正式包高30%-50%左右，不能直接把debug下的计数直接等同于正式环境表现，但可感知的卡顿已经说明问题不是单纯的统计误差。
• 正常重组的阈值参考：如果是列表项首次滑入视窗、完成数据绑定和初始布局的阶段，发生3-5次重组属于Compose的正常调度范围，只要单帧总耗时控制在对应刷新率的阈值内（60fps屏幕单帧上限16ms，120fps高刷屏单帧上限8ms），就不会造成可感知的卡顿。
• 会造成卡顿的异常重组场景：如果是滚动过程中、已经完成初始绑定的列表项持续触发5次以上重组，且列表项本身包含复杂嵌套布局、图片加载、业务逻辑计算等重开销内容，多次重组的耗时叠加后很容易突破单帧耗时上限，直接引发滚动掉帧。

注意：不要过度追求“0额外重组”，Compose的重组调度本身做了大量优化，少量非预期重组只要不带来帧耗时超标，完全不需要额外处理。

以下是Layout Inspector检测结果参考：

后续排查建议 #

• 先切换到release构建（开启R8混淆、关闭debug调试标识），用Macrobenchmark库做滚动场景的基准测试，拿到正式环境下的帧耗时、重组计数、跳过率数据，排除debug模式的干扰。
• 检查列表项入参的稳定性：如果传入列表项的数据类没有做@Stable稳定性标注、或者传了捕获了外部不稳定变量的Lambda，会导致Compose无法判定参数是否变化，无法跳过不必要的重组，引发整项反复重组。
• 收敛状态作用域：检查是否把滚动过程中高频变化的状态（比如滚动偏移量、联动动画值）放在了列表项的顶层，要把这类状态下放到实际使用它的最小子组件，避免状态变化时触发整个列表项重组。

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