作者:HELLO_WARD
我想学习底层原理的主要原因是我对 Jetpack Compose 是如何运作的非常感兴趣。相对于传统的 View 系统,JetPack Compose 写起来相当神奇。具体来说,Composable 函数不会有返回值;它会自动更新。
当然,考虑到它会是未来 Android UI 开发主流框架,我相信探究它的底层原理绝不是在浪费时间。并且如后面正文描述那样,我发现 Jetpack Compose 的实现非常有意思以至于我忍不住想要与你们分享。
我会展示一个简单的 Compose 代码片段并解释它如何工作来加深你对其中原理的认知。
这篇文章的使用例子是一段简单的 Compose UI 树代码,如下所示
@Composable
fun Content() {
// 3秒后 state 变为 false
var state by remember { mutableStateOf(true) }
LaunchedEffect(Unit) {
delay(3000)
state = false
}
//当 state 由 true 变为 false 时,Node1()会消失
if (state) {
Node1()
}
Node2()
}
所有的代码都在这个仓库里,如果你看不懂文章下面的介绍,你也可以选择直接看代码,只有130行,应该不会很难。
UI 树如下所示,并且 Node1 将会3秒后消失。
RootNode
├── Node1(value=node1)
└── Node2(value=node2)
3秒后UI树变成这样↓
RootNode
└── Node2(value=node2)
让我们看看 Compose 是如何实现上面的功能的。
首先,我们需要构造一棵上述的树,我们先简单地定义一个 Node 类。这里,我们定义了 Node 类,和它的三个子类: RootNode, Node1, Node2. 上面的几个类不会继承任何 Compose 框架里的类。
sealed class Node {
val children = mutableListOf()
class RootNode : Node() {
override fun toString(): String {
return rootNodeToString()
}
}
data class Node1(
var name: String = "",
) : Node()
data class Node2(
var name: String = "",
) : Node()
}
我们要如何让 Compose 使用上面的类来构造我们想要的树呢?
Compose 框架里有个 Applier 类,就是用来处理 UI 树的,其中的 UI 节点增删改查,都是由它来进行。
class NodeApplier(node: Node) : AbstractApplier(node) {
...
override fun insertTopDown(index: Int, instance: Node) {
// Now add a child node!
current.children.add(index, instance)
}
override fun move(from: Int, to: Int, count: Int) {
current.children.move(from, to, count)
}
override fun remove(index: Int, count: Int) {
current.children.remove(index, count)
}
}
为了让 Applier 添加我们自定义的 Node 类,我们要让 Compose 去管理 Node.
通过使用 ReusableComposeNode, 我们可以在 Compose 内部里添加 Node 类。在构造 ReusableComposeNode 的时候,需要我们传入两个 lmbda 参数,我们由参数名就可以理解到它们各自的作用:其中 factory 用于构造自定义类, update 用于当参数改变的时候发生的回调。
@Composable
private fun Node1(name: String = "node1") {
ReusableComposeNode(
factory = {
Node.Node1()
},
update = {
set(name) { this.name = it }
},
)
}
@Composable
private fun Node2(name: String = "node2") {
ReusableComposeNode(
factory = {
Node.Node2()
},
update = {
set(name) { this.name = it }
},
)
}
有了上面的代码我们就可以让 Compose 帮我们构造出上面的自定义 Node 类了,你可能需要等其他的解释完了才能理解这部分代码。
@Composable
private fun Node1(name: String = "node1") {
ReusableComposeNode(
factory = {
Node.Node1()
},
update = {
set(name) { this.name = it }
},
)
}
@Composable
private fun Node2(name: String = "node2") {
ReusableComposeNode(
factory = {
Node.Node2()
},
update = {
set(name) { this.name = it }
},
)
}
这篇文章的总览图
图片实在太大了,直接贴上来被压得妈都不认得,原图在地址在这里,个人觉得可以先阅读完整篇文章后再看图来作为回顾: github.com/takahirom/i…
之前提及的示例代码在运行前后会发生一些事情,梳理出这些应该可以帮助你理解 Compose 的内部机制:
在编译时
在运行时
调用 Composable 函数并在 SlotTable 中储存一些信息
3秒后改变 MutableState
Snapshot 系统监听到改变
重组
将发生的改变映射到 SlotTable(内部改变时使用 GapBuffer 算法)
下面我们一步一步细说
Compose 既然能在参数改变的时候进行更新,那它一定是储存了一些信息用于判断 Composable 参数是否改变了。Compose 框架中的 SlotTable(后面会细说) 正是担任这样的角色,这些参数信息是随着 Composable 函数储存在 SlotTable 中的。
我们的代码在编译成 Android 运行的应用时,Kotlin 代码会被转化为 Java 字节码,然后这些 Java 字节码再被转化为虚拟机字节码。而 Compose 看起来重写了 Kotlin IR 编译器。
因此我们可以把我们的 Kotlin 代码编译出来的字节码反编译,我们就能知道 Compose 的编译器插件做了什么事情。
现在就让我们看看反编译后的 Content() 函数。
你会注意到代码中多了 startRestartGroup(), endRestartGroup(), startReplaceableGroup(), endReplaceableGroup() 这几个不是我们写的方法。 Compose 框架内部有组的概念,并且允许我们使用组来创建 UI 树。
把成组的代码以某种方式保存使得可以在需要的时候被重复执行
你也可以看到代码里还有看起来像是跳过执行的方法
@Composable
public static final void Content(@Nullable Composer $composer, final int $changed) {
// ↓↓↓↓RestartGroup↓↓↓↓
$composer = $composer.startRestartGroup(-337788314);
ComposerKt.sourceInformation($composer, "C(Content)");
if ($changed == 0 && $composer.getSkipping()) {
$composer.skipToGroupEnd();
} else {
... LaunchedEffect and MutableState related code
$composer.startReplaceableGroup(-337788167);
if (Content$lambda-2(state$delegate)) {
Node1((String)null, $composer, 0, 1);
}
$composer.endReplaceableGroup();
Node2((String)null, $composer, 0, 1);
}
ScopeUpdateScope var18 = $composer.endRestartGroup();
// ↑↑↑↑RestartGroup↑↑↑↑
// ↓↓↓↓保存上面的组代码使得可以在被需要的时候重复执行↓↓↓↓
if (var18 != null) {
var18.updateScope((Function2)(new Function2() {
public final void invoke(@Nullable Composer $composer, int $force) {
MainKt.Content($composer, $changed | 1);
}
}));
}
// ↑↑↑↑保存上面的组代码使得可以在被需要的时候重复执行↑↑↑↑
}
@Composable
private static final void Node1(final String name, Composer $composer, final int $changed, final int var3) {
$composer = $composer.startRestartGroup(1815931657);
// ...
ScopeUpdateScope var10 = $composer.endRestartGroup();
if (var10 != null) {
var10.updateScope((Function2)(new Function2() {
public final void invoke(@Nullable Composer $composer, int $force) {
MainKt.Node1(name, $composer, $changed | 1, var3);
}
}));
}
}
现在,运行APP,示例代码中的 Content() 函数会被执行。
在这个时候, Compose 会把数据储存至 SlotTable. 在这篇文章里我们不会花太多篇幅在这步上,因为我们主要关心 UI 自动更新的部分。
SlotTable 内部包含两个数据结构,都是用于储存 UI 树中的组信息。
groups: IntArray
slots: Array
这个名为 groups 的整型数组为每个组储存了5个元素,因此 groups 的大小是组数量的5倍。有了这个信息后我们也可以通过下面的代码来窥探 groups 里储存的数据:
groups.toList().windowed(
size = 5,
step = 5,
partialWindows = false
)
.forEachIndexed { index, group ->
val (key, groupInfo, parentAnchor, size, dataAnchor) = group
println("index: $index, " +
"key: $key, " +
"groupInfo: $groupInfo, " +
"parentAnchor: $parentAnchor, " +
"size: $size, " +
"dataAnchor: $dataAnchor")
}
看起来 groups 储存的数据是属于 slots 的信息。
组数据里储存着对应 slots 的下标,在上面名为 dataAnchor 的变量中。组数据里也储存着对应父组的 slots 的下标,在上面名为 parentAnchor 的变量中。
groups 中的信息:
index: 0, key: 100, groupInfo: 2, parentAnchor: -1, size: 16, dataAnchor: 0
index: 1, key: 1000, groupInfo: 2, parentAnchor: 0, size: 15, dataAnchor: 1
index: 2, key: 200, groupInfo: 536870914, parentAnchor: 1, size: 14, dataAnchor: 1
index: 3, key: -985533309, groupInfo: 2, parentAnchor: 2, size: 13, dataAnchor: 2
index: 4, key: -337788314, groupInfo: 268435458, parentAnchor: 3, size: 12, dataAnchor: 4
index: 5, key: -3687241, groupInfo: 268435456, parentAnchor: 4, size: 1, dataAnchor: 6
index: 6, key: -3686930, groupInfo: 268435456, parentAnchor: 4, size: 1, dataAnchor: 8
index: 7, key: 1036442245, groupInfo: 268435456, parentAnchor: 4, size: 2, dataAnchor: 11
index: 8, key: -3686930, groupInfo: 268435456, parentAnchor: 7, size: 1, dataAnchor: 12
index: 9, key: -337788167, groupInfo: 1, parentAnchor: 4, size: 4, dataAnchor: 15
index: 10, key: 1815931657, groupInfo: 1, parentAnchor: 9, size: 3, dataAnchor: 15
index: 11, key: 1546164276, groupInfo: 268435457, parentAnchor: 10, size: 2, dataAnchor: 16
index: 12, key: 125, groupInfo: 1073741824, parentAnchor: 11, size: 1, dataAnchor: 17
index: 13, key: 1815931930, groupInfo: 1, parentAnchor: 4, size: 3, dataAnchor: 19
index: 14, key: 1546164276, groupInfo: 268435457, parentAnchor: 13, size: 2, dataAnchor: 20
index: 15, key: 125, groupInfo: 1073741824, parentAnchor: 14, size: 1, dataAnchor: 21
index: 16, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 17, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 18, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 19, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 20, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 21, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 22, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 23, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 24, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 25, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 26, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 27, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 28, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 29, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 30, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
index: 31, key: 0, groupInfo: 0, parentAnchor: 0, size: 0, dataAnchor: 0
Slots 中的信息:
0: {}(class androidx.compose.runtime.external.kotlinx.collections.immutable.implementations.immutableMap.PersistentHashMap)
1: OpaqueKey(key=provider)(class androidx.compose.runtime.OpaqueKey)
2: androidx.compose.runtime.RecomposeScopeImpl@4fb4ae6(class androidx.compose.runtime.RecomposeScopeImpl)
3: androidx.compose.runtime.internal.ComposableLambdaImpl@3b52827(class androidx.compose.runtime.internal.ComposableLambdaImpl)
4: C(Content)(class java.lang.String)
5: androidx.compose.runtime.RecomposeScopeImpl@b882ad4(class androidx.compose.runtime.RecomposeScopeImpl)
6: C(remember):Composables.kt#9igjgp(class java.lang.String)
7: MutableState(value=true)@167707773(class androidx.compose.runtime.ParcelableSnapshotMutableState)
8: C(remember)P(1):Composables.kt#9igjgp(class java.lang.String)
9: MutableState(value=true)@167707773(class androidx.compose.runtime.ParcelableSnapshotMutableState)
10: Function2, java.lang.Object>(class com.github.takahirom.compose.MainKt$Content$1$1)
11: C(LaunchedEffect)P(1)336@14101L58:Effects.kt#9igjgp(class java.lang.String)
12: C(remember)P(1):Composables.kt#9igjgp(class java.lang.String)
13: kotlin.Unit(class kotlin.Unit)
14: androidx.compose.runtime.LaunchedEffectImpl@8d3f428(class androidx.compose.runtime.LaunchedEffectImpl)
15: androidx.compose.runtime.RecomposeScopeImpl@7421fc3(class androidx.compose.runtime.RecomposeScopeImpl)
16: C(ReusableComposeNode):Composables.kt#9igjgp(class java.lang.String)
17: Node1(name=node1)(class com.github.takahirom.compose.Node$Node1)
18: node1(class java.lang.String)
19: androidx.compose.runtime.RecomposeScopeImpl@81cf51f(class androidx.compose.runtime.RecomposeScopeImpl)
20: C(ReusableComposeNode):Composables.kt#9igjgp(class java.lang.String)
21: Node2(name=node2)(class com.github.takahirom.compose.Node$Node2)
22: node2(class java.lang.String)
23: null(null)
24: null(null)
25: null(null)
26: null(null)
27: null(null)
28: null(null)
29: null(null)
30: null(null)
31: null(null)
另外,我们可以通过调用 SlotTable#asString()
来把数据可视化:
Group(0) key=100, nodes=2, size=16, slots=[0: {}]
Group(1) key=1000, nodes=2, size=15
Group(2) key=200, nodes=2, size=14 objectKey=OpaqueKey(key=provider)
Group(3) key=-985533309, nodes=2, size=13, slots=[2: androidx.compose.runtime.RecomposeScopeImpl@4fb4ae6, androidx.compose.runtime.internal.ComposableLambdaImpl@3b52827]
Group(4) key=-337788314, nodes=2, size=12 aux=C(Content), slots=[5: androidx.compose.runtime.RecomposeScopeImpl@b882ad4]
Group(5) key=-3687241, nodes=0, size=1 aux=C(remember):Composables.kt#9igjgp, slots=[7: MutableState(value=false)@167707773]
Group(6) key=-3686930, nodes=0, size=1 aux=C(remember)P(1):Composables.kt#9igjgp, slots=[9: MutableState(value=false)@167707773, Function2, java.lang.Object>]
Group(7) key=1036442245, nodes=0, size=2 aux=C(LaunchedEffect)P(1)336@14101L58:Effects.kt#9igjgp
Group(8) key=-3686930, nodes=0, size=1 aux=C(remember)P(1):Composables.kt#9igjgp, slots=[13: kotlin.Unit, androidx.compose.runtime.LaunchedEffectImpl@8d3f428]
Group(9) key=-337788167, nodes=1, size=4
Group(10) key=1815931657, nodes=1, size=3, slots=[15: androidx.compose.runtime.RecomposeScopeImpl@7421fc3]
Group(11) key=1546164276, nodes=1, size=2 aux=C(ReusableComposeNode):Composables.kt#9igjgp
Group(12) key=125, nodes=0, size=1 node=Node1(name=node1), slots=[18: node1]
Group(13) key=1815931930, nodes=1, size=3, slots=[19: androidx.compose.runtime.RecomposeScopeImpl@81cf51f]
Group(14) key=1546164276, nodes=1, size=2 aux=C(ReusableComposeNode):Composables.kt#9igjgp
Group(15) key=125, nodes=0, size=1 node=Node2(name=node2), slots=[22: node2]
在运行时上面这些数据都会储存在 SlotTable 中
下面这段代码改变 MutableState
// It's written at the top level. (The exact scope is different).
var state: MutableState = mutableStateOf(true)
@Composable
fun Content() {
LaunchedEffect(Unit) {
delay(3000)
// Rewrite state.value
state.value = false
}
现在让我们探究一下 Compose 框架是如何监测到 State 的改变的
Compose 框架使用快照系统去做这个事情,假设我们有如下代码,我们可以先猜猜代码会输出什么
class ViewModel {
val state = mutableStateOf("initialized")
}
fun main() {
val viewModel = ViewModel()
Snapshot.registerApplyObserver { changedSet, snapshot ->
changedSet.forEach {
println("registerApplyObserver:" + it)
}
}
viewModel.state.value = "one"
}
正确答案是什么都不会输出。
但是当我再增加一行 Snapshot.sendApplyNotifications()
结果就会不一样:
class ViewModel {
val state = mutableStateOf("initialized")
}
fun main() {
val viewModel = ViewModel()
Snapshot.registerApplyObserver { changedSet, snapshot ->
changedSet.forEach {
println("registerApplyObserver:" + it)
}
}
viewModel.state.value = "one"
// ↓ **Add the following**
Snapshot.sendApplyNotifications()
}
//控制台输出
//registerApplyObserver:MutableState(value=one)@1831932724
Compose 框架正是使用上面的机制来以监测每帧之间的 UI 数据变化。在上面的例子中,在 registerApplyObserver()
****注册的回调会在 state 改变后调用
如果 Compose 的重组发生在非主线程会发生什么事情呢?
从我们以前的经验来说,感觉这样做会出现异常。但是通过使用快照系统,没问题!
事实上,在上一个例子里,我们使用了一个最顶层的快照 (GlobalSnapshot) 。通过调用 Snapshot.takemutableSnapshot()
就可以创建出快照,重组就是在快照里面发生。
// Here is GlobalSnapshot
// Create Snapshot
val snapshot = Snapshot.takeMutableSnapshot()
snapshot.enter {
// Recompose here
}
你可以把快照想象成游戏里的存档。
在创建快照后,通过 enter{}
方法进入快照,此时数据会定格在进入快照的时候,之后无论外面的数据怎么变化,都不会影响到该快照里面的数据。
class ViewModel {
val state = mutableStateOf("init")
}
fun main() {
val viewModel = ViewModel()
viewModel.state.value = "before snapshot"
val snapshot = Snapshot.takeMutableSnapshot()
// 尝试从其他线程更改数据
thread { // 启动一个其他线程更改 state
viewModel.state.value = "changes from other thread"
}
snapshot.enter {
// 等待上面的线程更改数据
Thread.sleep(100)
println("in snapshot:" + viewModel.state)
}
}
//控制台的输出:
//in snapshot:MutableState(value=before snapshot)@1777466639
从上面的代码结果可以看出,在进入快照后,数据之后在外面发生的更改不会影响到快照内的数据。
那么当我们同时在快照里和快照外更改数据后会发生什么呢?
通过调用 Snapshot.apply()
我们可以把快照里的更改提交。
val snapshot = Snapshot.takeMutableSnapshot()
thread {
viewModel.state.value = "changes from other thread"
}
snapshot.enter {
Thread.sleep(100)
println("in snapshot before change:" + viewModel.state)
viewModel.state.value = "change in snapshot"
println("in snapshot after change:" + viewModel.state)
}
snapshot.apply()
println("after apply:" + viewModel.state)
//控制台的输出:
// in snapshot before change:MutableState(value=before snapshot)@1170114219
// in snapshot after change:MutableState(value=change in snapshot)@1170114219
// after apply:MutableState(value=changes from other thread)@1170114219
运行没有出错,但是看起来快照的更改没有生效。
事实上,MutableState 还有一个名为 SnapshotMutationPolicy 的参数(如下所示),用于快照提交时如果发生冲突时回调,让你自定义逻辑,而默认实现是会放弃提交的。快照系统正是通过这个来应对多线程修改。
fun mutableStateOf(
value: T,
policy: SnapshotMutationPolicy = structuralEqualityPolicy()
): MutableState = createSnapshotMutableState(value, policy)
class ViewModel {
val state = mutableStateOf("init", object : SnapshotMutationPolicy {
override fun equivalent(a: String, b: String): Boolean {
return a == b
}
override fun merge(previous: String, current: String, applied: String): String {
return applied
}
})
}
当一个 Composable 函数使用到的 MutableState 发生改变的时候,函数会再次调用,这个过程也叫重组 (Recompose) 。
这是如何做到的?
锵锵!Snapshot.takeMutableSnapshot()
方法还有一个名为 readObserver 的参数,问题的答案就在其中:
val snapshot = Snapshot.takeMutableSnapshot(readObserver = { state ->
// state 被读取的时候发生回调
})
非常直观,当 state 被读取的时候,把当前的 Scope 存下来,如下所示。
class ViewModel {
val state = mutableStateOf("init")
}
fun main() {
val viewModel = ViewModel()
lateinit var currentScope: String
val observations = mutableMapOf()
val snapshot = Snapshot.takeMutableSnapshot(readObserver = {
observations[it] = currentScope
})
snapshot.enter {
currentScope = "Root()"
currentScope = "Content()"
// read
viewModel.state.value
currentScope = "Root()"
}
snapshot.apply()
observations.forEach { mutableState, scope ->
println("`$mutableState` is observed by `$scope`")
}
}
//控制台输出:
//`MutableState(value=init)@1096979270` is observed by `Content()`
还记得我们一开始的那个简易 UI 树例子的反编译后的代码吗? Compose 的编译器插件为我们生成了一个再次调用该 Composable 的方法,事实上,重组时的 UI 更新就是通过调用这个方法做到的:
@Composable
public static final void Content(@Nullable Composer $composer, final int $changed) {
...
// ↓↓↓↓Register the function to be called again↓↓↓↓
if (var18 != null) {
var18.updateScope((Function2)(new Function2() {
public final void invoke(@Nullable Composer $composer, int $force) {
MainKt.Content($composer, $changed | 1);
}
}));
}
// ↑↑↑↑Register the function to be called again↑↑↑↑
}
至此,我们知道了 :
Compose 如何监测数据发生改变
数据改变后哪些关联的 Scope 被影响到
被影响到的 Scope 如何更新UI
相信你已经可以推理出完整的过程了!
当快照检测到 Content() 里读取的数据发生改变,Content() 会被再次调用。对于这个具体例子来说, state 被储存在 SlotTable 中,现在 Node1() 将要消失,而 Node2() 依旧会显示。
@Composable
fun Content() {
var state by remember { mutableStateOf(true) }
LaunchedEffect(Unit) {
delay(3000)
state = false
}
if (state) {
Node1() // ← This place is about to disappear.
}
Node2()
}
但是 Compose 会调用整个受影响的地方吗? Compose 其实做了很多精妙的优化。
Compose 会跳过数据没有变化的部分。这个优化被称为 ‘donut-hole skipping’ ,具体来说,Content() 会被调用,但不会完全调用(笑),里面的 Node2() 不会发生重组,就像把 Content() 比作一个甜甜圈(donut),而 Node2() 正是甜甜圈里的洞 (hole)。
非常神奇吧!在上文中我们提及过数据会被储存在 SlotTable 中,通过比对新旧数据,是可以做到跳过没有发生更改的部分的。
Group(0) key=100, nodes=2, size=16, slots=[0: {}]
Group(1) key=1000, nodes=2, size=15
...
Group(13) key=1815931930, nodes=1, size=3, slots=[19: androidx.compose.runtime.RecomposeScopeImpl@81cf51f]
Group(14) key=1546164276, nodes=1, size=2 aux=C(ReusableComposeNode):Composables.kt#9igjgp
// **↓I won't recompose it because it's the same data I'm holding here!**
Group(15) key=125, nodes=0, size=1 node=Node2(name=node2), slots=[22: node2]
通过反编译的代码👇,我们可以看到第9行从 SlotTable 中读取数据比较。(事实上这里的默认参数并不准确,不过这个不是重点,我们这里不展开)
@Composable
private static final void Node2(final String name, Composer $composer, final int $changed, final int var3) {
$composer = $composer.startRestartGroup(1815931962);
int $dirty = $changed;
if ((var3 & 1) != 0) {
$dirty = $changed | 6;
} else if (($changed & 14) == 0) {
// ↓ 与 SlotTable 中的数据比较
$dirty = $changed | ($composer.changed(name) ? 4 : 2);
}
if (($dirty & 11 ^ 2) == 0 && $composer.getSkipping()) {
// 根据比较结果决定是否跳过
$composer.skipToGroupEnd();
} else {
...
$composer.startReplaceableGroup(1546164276);
// ... Here's the original process.
$composer.endReplaceableGroup();
}
...
}
上一小节我们谈及到了未更改的部分不会重新运行,但是 SlotTable 的数据也是需要更新的。在重组期间,所有的改变都会被储存在一个 change list 中,最后一次过对 SlotTable 应用所有的改变。
现在是时候把更改列表储存的所有更改全部应用了。如果我们不想太多直接用常规方法实现,工作起来如下图所示,很直观,没有毛病。
那如果用上面的方法在4个元素的数组里移除3个呢?
由于删除数组中的其中一个数据后需要把后面所有的元素一个一个往回补,这样的操作会花费大量的时间👇
在前文我们已知 SlotTable 使用的数据结构就是数组,更何况现实中的 UI 元素可远不止个位数,显然不能用这种默认实现去操作 SlotTable。
Compose 使用 Gap Buffer 算法来优化。
简单来说,gap buffer 是一个动态数组,实现了相邻位置元素的高效的增删,这个算法常用于文本编辑器中。
通过移动数据来创建间隙,只需使用一个变量来表示间隙的长度,然后更改该变量即可完成删除。
使用 GapBuffer 删除 Node1 的过程👇
可以看到,Compose 内部做了非常多有趣的优化,我不认为只使用 Compose 去编写 UI 能够发掘出这些东西。
Jetpack全家桶篇(内含Compose):https://qr18.cn/A0gajp
Android 性能优化篇:https://qr18.cn/FVlo89
Android Framework底层原理篇:https://qr18.cn/AQpN4J
Android 车载篇:https://qr18.cn/F05ZCM
Android 逆向安全学习笔记:https://qr18.cn/CQ5TcL
Android 音视频篇:https://qr18.cn/Ei3VPD
OkHttp 源码解析笔记:https://qr18.cn/Cw0pBD
Kotlin 篇:https://qr18.cn/CdjtAF
Gradle 篇:https://qr18.cn/DzrmMB
Flutter 篇:https://qr18.cn/DIvKma
Android 八大知识体:https://qr18.cn/CyxarU
Android 核心笔记:https://qr21.cn/CaZQLo
Android 往年面试题锦:https://qr18.cn/CKV8OZ
2023年最新Android 面试题集:https://qr18.cn/CgxrRy
Android 车载开发岗位面试习题:https://qr18.cn/FTlyCJ
音视频面试题锦:https://qr18.cn/AcV6Ap