@Immutable注解在Compose数据类中的优化价值及重组跳过场景

先搞懂核心逻辑：Compose的重组判断依赖稳定性推导，哪怕你写的是全val的data class，Compose默认也不会直接认定它是绝对稳定的——毕竟这个类的属性里可能藏着可变的内部状态，或者被子类继承后修改了逻辑。而@Immutable就是给Compose明确信号：这个类型的所有属性都是稳定不可变的，实例一旦创建就没法修改，要变更只能生成新实例。

优化点到底在哪？ #

没加@Immutable的话，Compose每次对比Person实例时，会递归检查它的所有属性是否相等，哪怕实例引用完全没变也得走一遍检查流程。加了@Immutable后，Compose直接用**引用相等（===）**来判断，不用递归遍历属性，对比速度快得多，尤其是数据结构复杂、层级深的时候，能省不少性能开销。

什么时候会跳过PersonView的重组？ #

举个实际场景：如果PeopleView的people参数是稳定类型的列表（比如用不可变的List接口，或者加了@Stable注解的自定义列表），当PeopleView因为其他参数变化触发重组时，只要某个Person的实例引用没变化，Compose就会直接跳过对应的PersonView重组——因为@Immutable保证这个实例内部状态绝对没改，没必要重新执行PersonView的逻辑。

要是没加@Immutable，哪怕Person实例引用没变，Compose也得挨个检查它的属性，万一属性里有Compose没法判断稳定性的类型，甚至会触发不必要的重组。

和PeopleView的List参数有关吗？ #

当然有关！默认的MutableList是不稳定类型，Compose知道它可以被修改，所以哪怕列表里的Person实例全没变，只要用的是MutableList，PeopleView还是会触发重组，进而可能让所有PersonView也跟着执行一遍——但加了@Immutable的话，Compose对比Person实例时会更快（直接比引用），能减少重组的耗时，但还是得走对比流程。

但如果把列表换成稳定类型（比如用remember缓存的不可变列表，或者ImmutableList），再配合Person的@Immutable注解，只要列表引用不变、内部Person实例引用也不变，PersonView就会被完全跳过重组，连对比步骤都省了。

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