一、前言
在 Compose 的开发中,我们经常遇到这样的场景:有一个数据(比如主题颜色、字体、上下文 Context 等),需要在多层嵌套的组件中进行传递。如果通过普通的函数参数一层层传递(所谓的“Prop Drilling”),会导致中间许多并不需要这个数据的组件也被迫增加参数,代码极其冗余和难以维护。
这时,CompositionLocal 就闪亮登场了。
二、CompositionLocal 是干嘛的?为什么要用它?
1. 它是干嘛的?
CompositionLocal 是 Compose 提供的一种隐式传参机制。它允许你在树的某个高层节点“提供(Provide)”一个值,然后在树的底层任何一个节点直接“消费(Consume)”这个值,而不需要通过函数参数显式地一层层传递。
2. 为什么要用它?
- 避免属性透传 (Prop Drilling): 比如
LocalContext,几乎任何 UI 组件都可能需要 Context,如果作为参数传递,那么所有的@Composable函数都要带上 Context 参数,简直是噩梦。 - 作用域隔离: 它的值是与组件树关联的,即子树中可以覆盖父树中提供的值,不同的子树可以读取到不同的值。
- 状态响应: 结合 Compose 的重组机制,当
CompositionLocal提供的状态发生变化时,只会触发读取了该值的组件进行精确重组。
三、从源码看 CompositionLocal 的工作原理
要理解 CompositionLocal 的原理,我们需要弄清楚三个核心问题:
- 它是如何被创建的?
- 它是如何被提供的 (Provide)?
- 它是如何被读取的 (Consume)?
3、1 它是如何被创建的?
在 Compose 中,我们通常使用 compositionLocalOf 或 staticCompositionLocalOf 来创建一个 ProvidableCompositionLocal。
public fun <T> compositionLocalOf(
policy: SnapshotMutationPolicy<T> = structuralEqualityPolicy(),
defaultFactory: () -> T
): ProvidableCompositionLocal<T> = DynamicProvidableCompositionLocal(policy, defaultFactory)
public fun <T> staticCompositionLocalOf(
defaultFactory: () -> T
): ProvidableCompositionLocal<T> = StaticProvidableCompositionLocal(defaultFactory)
这两者的区别在于它们对应的内部实现类:
DynamicProvidableCompositionLocal(动态): 内部其实包裹了一个MutableState。当其值发生变化时,只有真正读取了该值的@Composable才会发生重组(精准刷新)。StaticProvidableCompositionLocal(静态): 内部直接存储值,没有任何 State 追踪。当提供给它的值发生变化时,整个CompositionLocalProvider包裹的所有内容都会发生重组。适用于极少改变的数据。
我们可以看一下 ProvidableCompositionLocal 的源码定义:
public abstract class ProvidableCompositionLocal<T> internal constructor(
defaultFactory: () -> T
) : CompositionLocal<T>(defaultFactory) {
// 允许通过 `provides` 语法糖生成一个 ProvidedValue
@Suppress("UNCHECKED_CAST")
public infix fun provides(value: T): ProvidedValue<T> =
ProvidedValue(this, value, true)
}
3、2 它是如何被提供的?(Provider 的秘密)
我们平时这样使用:
CompositionLocalProvider(LocalThemeColor provides Color.Red) {
MyComponent()
}
来看看 CompositionLocalProvider 的源码 (CompositionLocal.kt):
@Composable
public fun CompositionLocalProvider(
vararg values: ProvidedValue<*>,
content: @Composable () -> Unit
) {
currentComposer.startProviders(values)
content()
currentComposer.endProviders()
}
极其简单!调用了 currentComposer.startProviders(values)。Composer 是 Compose 运行时的核心。当调用 startProviders 时,它会将你传入的这些 ProvidedValue 合并到一个字典中:CompositionLocalMap。
CompositionLocalMap 被定义为一个不可变的 Map 快照:
public sealed interface CompositionLocalMap {
public operator fun <T> get(key: CompositionLocal<T>): T
}
在 Composer 的具体实现中,每当遇到 startProviders,它就会基于当前父级的 CompositionLocalMap,结合新传入的 values,生成一个新的 CompositionLocalMap,并将其压入栈中。这样,在 content() 内部的所有组件,看到的都是这个包含了新值的 Map。这就实现了作用域与覆盖的特性。
3、3 它是如何被读取的?
当我们在组件中读取值时:
val color = LocalThemeColor.current
这里的 .current 是一个定义在 CompositionLocal 上的只读属性。我们来看看 CompositionLocal.kt:
public sealed class CompositionLocal<T> constructor(
defaultFactory: () -> T
) {
@get:Composable
@ReadOnlyComposable
public inline val current: T
get() = currentComposer.consume(this)
}
秘密就在这里!
首先,它被 @get:Composable 标记,这意味着只能在 Composable 函数或另一个 Composable getter 中读取它。
其次,它直接调用了 currentComposer.consume(this)。
我们不需要再深入 ComposerImpl 几千行的源码,简单来说,consume(this) 做了两件事:
- 查表: 从 Composer 当前作用域绑定的
CompositionLocalMap中,以当前CompositionLocal实例本身为 Key 去查找对应的值(ValueHolder)。如果没有找到,就执行我们创建它时传入的defaultFactory获取默认值。 - 建立追踪依赖 (对于 DynamicLocal): 如果这个 Local 是
compositionLocalOf创建的动态类型,它取出的其实是一个State。读取State的值时,Compose 的快照系统(Snapshot System)就会自动记录下:“当前的 Composable 读取了这个 State”。
这样一来,当更高层的 Provider 改变了提供的值,如果是动态 Local,只有订阅了这个 State 的 Composable 会被重组;如果是静态 Local,由于没有 State 记录,系统只能粗暴地把整个 Provider 的 content 全部重组。
四、总结
CompositionLocal解决了参数层层传递的问题,本质是通过Composer维护的一个按作用域层级叠加上下文的Map (CompositionLocalMap)。- 提供值 (Provide): 将新的键值对合并到当前层级的
Map中,作用于子树。 - 获取值 (Consume): 通过隐式的
currentComposer去查询当前层级的Map。 - 响应更新:
compositionLocalOf基于内部维护的State实现了精准重组。staticCompositionLocalOf舍弃了State跟踪开销,但更新时会触发全局重组,适合那些“一旦提供几乎不改变”的数据(如 Context)。