引言
Jetpack Compose 作为现代 Android 开发中声明式 UI 编程的翘楚，革新了开发者构建用户界面的方式。其中，currentComposer 与 Activity、currentRecomposeScope 与 Compose 函数之间的一一对应关系，犹如两条隐秘的线索，串联起 Compose 高效渲染与精准状态管理的奥秘。理解这两组对应关系，不仅是掌握 Compose 运行机制的关键，更是编写出稳定、高效 Compose 应用的不二法门。接下来，我们将深入 Composition 源码，揭开这两组对应关系的神秘面纱。
一、currentComposer 与 Activity 的一一对应关系
1. currentComposer 概述
在 Jetpack Compose 的宏大舞台上，currentComposer 以 Composer 实例的身份，扮演着核心导演的角色。它就像一位技艺精湛的指挥家，凭借着对节奏和细节的精准把控，协调着 Compose 应用中各个可组合函数的有序执行。Composer 细致地跟踪着所有可组合函数的状态和执行顺序，如同一位严谨的史官，记录着哪些 UI 部分需要重新渲染，确保整个应用界面能够流畅、及时地更新。
2. Activity 与 Composition 的关联
在 Android 开发的传统版图中，Activity 一直是承载用户界面的核心容器。当引入 Jetpack Compose 来构建界面时，setContent 方法成为了连接传统与现代的桥梁。以下是一个简单而经典的示例：
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
// Compose UI 内容
Text(text = "Hello, Compose!")
}
}
}
在上述代码中，调用 setContent 方法后，系统内部会创建一个 ComposeView，并调用其 setContent 方法，进而触发 Composition 的创建以及 Composer 的初始化。这一系列操作，如同一场精心编排的舞蹈，将 Activity 与 Compose UI 紧密地联系在一起。
我们也可以采用一种更具层次感的写法，将 Compose UI 优雅地适配到传统 Android View 体系中：
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(ComposeView(this).apply {
setContent {
// Compose UI 内容
Text(text = "Hello, Compose!")
}
})
}
}
更令人惊喜的是，Compose 还支持将传统 Android View 融入到 Compose UI 中，实现两者的混合开发，示例如下：
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
AndroidView(factory = { context -> TextView(context) }) {
it.text = "Hello, Android!"
}
}
}
}
3. 从 Composition 源码看对应关系
在 CompositionImpl 类中，composer 作为一个只读属性，与 CompositionImpl 实例的创建紧密相连。当 CompositionImpl 被实例化时，composer 也会同步诞生，代码如下：
private val composer: ComposerImpl =
ComposerImpl(
applier = applier,
parentContext = parent,
slotTable = slotTable,
abandonSet = abandonSet,
changes = changes,
lateChanges = lateChanges,
composition = this
).also {
parent.registerComposer(it)
}
详细解释
-
applier：Applier继承自AbstractApplier<LayoutNode>，它是 Compose 组合体与实际 UI 系统之间的关键纽带。不同的Activity就像不同风格的建筑，有着各自独特的 UI 布局需求。applier的使命就是将 Compose 生成的虚拟 UI 结构，如同一位技艺高超的工匠，精准地转化为实际的 UI 元素，确保每个Activity的界面都能完美呈现。 -
parentContext：CompositionContext为组合体提供了必要的上下文信息，就像为一场戏剧演出搭建了舞台和背景。它负责管理组合体的生命周期，并协调各种相关操作。每个Activity都拥有自己独立的上下文环境，不同Activity对应的parentContext各不相同。这种独立性就像为每个Activity配备了专属的指挥室，保证了每个Activity中的Composer可以独立运行，互不干扰。 -
slotTable：SlotTable是一个用于存储组合信息的精密数据库，它记录着可组合函数的状态和位置。每个Activity中的Composer都拥有自己独立的slotTable，就像每个城市都有自己的图书馆，各自独立地跟踪和管理其内部可组合函数的状态，确保信息的准确性和独立性。
由于每个 Activity 中的 ComposeView 都会创建独立的 Composition 实例，而每个 Composition 实例又会进一步创建独立的 Composer 实例。这是因为 Activity 本身就是独立的 UI 容器，不同 Activity 之间的 UI 是相互隔离的。每个 Activity 中的 ComposeView 会根据自身的 CompositionContext 创建独立的 Composer，从而实现了 currentComposer 与 Activity 的一一对应关系。
4. 对应关系的意义
这种一一对应关系为不同 Activity 中的 Compose UI 提供了独立管理和渲染的能力。每个 Activity 的 Composer 就像一位独立的项目经理，独立跟踪其内部可组合函数的状态和执行顺序。当某个 Activity 中的可组合函数状态发生变化时，只会触发该 Activity 对应的 Composer 进行重组操作，而不会对其他 Activity 的 UI 产生任何影响。这种独立性保证了 UI 的稳定性和可靠性，同时也提高了应用的性能和响应速度，为用户带来了更加流畅的使用体验。
二、currentRecomposeScope 与 Compose 函数的一一对应关系
1. currentRecomposeScope 概述
currentRecomposeScope 作为 RecomposeScope 实例，在 Compose 函数的运行过程中扮演着智能监控者的角色。它就像一个时刻保持警觉的哨兵，密切关注着 Compose 函数内部状态的变化。当 Compose 函数内部的状态发生改变时，currentRecomposeScope 会根据状态变化的情况，精准地决定是否对该函数进行重组操作，确保 UI 能够及时反映最新的状态信息。
2. Compose 函数与 RecomposeScope 的关联
在 CompositionImpl 中，当调用 setContent 或 recompose 方法时，系统会为传入的 @Composable 函数创建独立的 RecomposeScope。以 composeContent 方法为例：
override fun composeContent(content: @Composable () -> Unit) {
guardChanges {
synchronized(lock) {
drainPendingModificationsForCompositionLocked()
guardInvalidationsLocked { invalidations ->
val observer = observer()
if (observer != null) {
observer.onBeginComposition(
this,
invalidations.asMap() as Map<RecomposeScope, Set<Any>?>
)
}
composer.composeContent(invalidations, content)
observer?.onEndComposition(this)
}
}
}
}
在上述代码中，composer.composeContent 方法会为 content 这个 @Composable 函数创建对应的 RecomposeScope，为该函数的状态监控和重组操作提供支持。
3. 从 Composition 源码看对应关系
在 CompositionImpl 中，RecomposeScope 的管理是通过 ScopeMap 来实现的。下面是 recordReadOf 方法的代码示例：
override fun recordReadOf(value: Any) {
// Not acquiring lock since this happens during composition with it already held
if (!areChildrenComposing) {
composer.currentRecomposeScope?.let {
it.used = true
val alreadyRead = it.recordRead(value)
if (!alreadyRead) {
if (value is StateObjectImpl) {
value.recordReadIn(ReaderKind.Composition)
}
observations.add(value, it)
// Record derived state dependency mapping
if (value is DerivedState<*>) {
val record = value.currentRecord
derivedStates.removeScope(value)
record.dependencies.forEachKey { dependency ->
if (dependency is StateObjectImpl) {
dependency.recordReadIn(ReaderKind.Composition)
}
derivedStates.add(dependency, value)
}
it.recordDerivedStateValue(value, record.currentValue)
}
}
}
}
}
详细解释
-
composer.currentRecomposeScope：在组合过程中，Composer会为每个@Composable函数维护一个当前的RecomposeScope。这个RecomposeScope就像一个专属的日志本，会详细记录该函数读取的状态对象信息。 -
recordRead：当@Composable函数读取一个状态对象时，RecomposeScope会调用recordRead方法记录这个读取操作。通过这种方式，当状态对象发生变化时，RecomposeScope就能够准确知道哪些@Composable函数需要进行重组操作，实现精准的状态更新。 -
observations和derivedStates：observations是一个ScopeMap，它用于存储状态对象和对应的RecomposeScope之间的映射关系，就像一个联系人列表，记录着状态对象和RecomposeScope之间的关联。derivedStates则用于记录派生状态的依赖关系。通过这些映射关系，RecomposeScope可以精确地跟踪状态变化，并根据变化情况决定是否触发重组操作。这里的derivedState实际上对应derivedStateOf函数，用于处理派生状态的计算和更新。
每个 @Composable 函数都拥有自己独立的 RecomposeScope，用于跟踪其内部状态的变化。当状态发生变化时，对应的 RecomposeScope 会立即触发重组操作，确保 Compose 函数能够及时更新 UI，为用户呈现最新的界面内容。
4. 对应关系的意义
这种一一对应关系为每个 Compose 函数的重组过程提供了独立可控的能力。不同的 Compose 函数可能依赖不同的状态，就像不同的工匠在不同的工坊里工作，各自依赖不同的工具和材料。通过独立的 RecomposeScope，可以精确控制每个函数的重组时机，避免不必要的重组操作。例如，当某个 Compose 函数的某个状态发生变化时，只有该函数对应的 RecomposeScope 会触发重组操作，而不会影响其他 Compose 函数。这大大提高了 Compose 应用的性能和响应速度，减少了系统资源的浪费，使应用更加高效和流畅。
三、总结
currentComposer 与 Activity 一一对应，currentRecomposeScope 与 Compose 函数一一对应，这两组对应关系是 Jetpack Compose 实现高效渲染和精准状态管理的核心机制。通过对 Composition 源码的深入分析，我们清晰地看到了 Compose 是如何利用这些机制实现 UI 的动态更新和高效管理的。
在实际开发过程中，开发者应充分利用这些特性，合理设计 Compose 函数，科学管理 Activity 中的 Compose UI。通过优化函数结构和状态管理，能够进一步提升应用的性能和用户体验。同时，持续深入研究 Compose 的源码，有助于开发者更好地应对开发中遇到的各种问题，充分发挥 Jetpack Compose 的最大潜力。
值得注意的是，从源码分析可以看出，Compose UI 框架采用了空间换时间的策略。传统的 setContentView 方法需要进行解析 XML 的 IO 操作，这会消耗一定的时间和资源。而 Compose 框架避免了这一操作，提高了渲染速度，但在渲染过程中会创建大量对象，占用一定的内存空间。因此，在使用 Compose 布局时，开发者应尽量减少复杂布局的使用，优化内存占用。不过，随着现代手机内存容量的不断增大，这一问题对应用性能的影响通常较小。
