为何部分库将Composable函数参数设为Lambda？智能重组差异解析

注：示例中Version 2的Counter函数参数类型应为() -> Int而非() -> Unit，否则Text(count())会因类型不匹配报错，属于笔误。

要理解两种版本的差异，得从Compose的重组机制核心逻辑说起：Compose的重组是按需触发的，只有当Composable函数的「输入依赖的状态发生变化」时，才会重新执行该函数。

版本1：直接传递属性值的局限 #

当使用Counter(screenState.count)时，Counter的输入参数是一个具体的Int值：

• Test函数会先读取screenState.count，把这个值传递给Counter。
• 一旦Test函数因为任何其他状态变化（比如同组件内的另一个状态isDarkMode更新）触发重组，即使screenState.count的值完全没变，Test还是会重新计算screenState.count并传递给Counter。
• Compose此时会对比Counter前后两次的参数值，发现没变化就跳过重组，但这个「参数对比」的过程是额外开销，而且如果Test重组频繁，这种无意义的参数传递和对比会累积性能损耗。
• 更关键的是，如果screenState是一个包含多个字段的复杂data class，当其他字段（比如username）变化时，screenState对象本身会因为data class的equals特性生成新实例，触发Test重组，此时screenState.count虽然没变，但同样会触发上述的参数传递和对比流程。

版本2：用Lambda包装的优势 #

当使用Counter({ screenState.count })时，Counter的输入参数是一个无参Lambda函数：

• Compose会对这个Lambda做状态读取追踪：它会记录Lambda内部读取了哪些状态（这里就是screenState.count对应的State对象）。
• 只有当Lambda内部读取的状态发生变化时，Compose才会触发Counter的重组。
• 即使Test函数因为其他状态变化触发重组，只要screenState.count没变化，这个Lambda就不会被重新执行，Counter也不会被触发重组——完全跳过了参数对比的步骤，直接实现了精准的按需重组。
• 另外，Lambda的传递本身是稳定的（只要Lambda的引用没变化），Compose会将其视为稳定参数，不会因为外部无关状态变化而触发不必要的检查。

本质差异：状态追踪的范围 #

• 版本1的状态追踪是在Test函数层面：Test读取了screenState.count，所以Test会依赖这个状态，而Counter只依赖传递过来的Int值。
• 版本2的状态追踪是在Counter函数层面：Counter内部执行Lambda时才读取screenState.count，所以Counter直接依赖这个状态，跳过了Test层面的中间传递，实现了更精准的依赖绑定。

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