Compose 渲染内核 (3)：Slot Table 与 Gap Buffer —— 极速重组的数学艺术

前言

Compose 为什么能支撑千万级的 UI 节点，并且在状态变动时实现极其精准的局部刷新？秘密全在底层的存储结构中。

今天我们深入 Compose Runtime 的核心数据结构 —— Slot Table (槽位表)。

---

一、 为什么不使用传统的“树状对象”？

在 View.java 体系中，UI 是由一个个真实的 Java 对象构成的树。

• 弊端：每个对象都有头信息、内存对齐开销。千万级节点会导致内存溢出（OOM）和频繁的 GC。
• Compose 的思路：将 UI 结构“扁平化”存储。

---

二、 Slot Table：UI 的“线性内存阵列”

Slot Table 本质上是一个巨大的、线性的 Int 数组和 Object 数组。

• Group：每一个 Composable 函数在调用时，都会在表中开辟一个“组”。记录了这个函数的位置、参数和 Key。
• Data：你在 Composable 里 remember 的值、创建的 State，都按顺序存放在这个线性数组的对应位置。

---

三、 核心算法：Gap Buffer (间隙缓冲区)

由于 UI 是动态变化的（增删改），在一个线性数组里插入节点通常是 $O(n)$ 的。为了保持性能，Compose 借用了文本编辑器（如 Emacs）中的 Gap Buffer 算法。

1. 预留间隙：在数组中保留一段空闲空间（Gap）。
2. 快速移动：当你在某个位置连续插入 UI 节点时，只需将 Gap 移动到该位置，后续插入就是 $O(1)$ 的。
3. 批量提交：只有当重组完成后，Gap 才会调整位置，这种算法极大地降低了内存碎片和拷贝开销。

---

四、 精准刷新的秘密：状态关联

当你在代码中读取一个 State 时：

1. Compose 会查当前执行的 Composable 所在的 Slot Table 位置。
2. 将该位置（Group）记录到 State 的监听名单中。
3. 重组时：直接通过 Slot Table 快速跳转到该 Group 重新执行，其他没读取该 State 的 Group 连看都不用看。

---

五、 技术沉思

• 内存优化：理解了 Slot Table，就明白为什么嵌套 Composable 越多，表就越长。虽然 $O(n)$ 很牛，但 $n$ 本身不能无限大。
• Key 的意义：在列表里使用 key，本质上是在告诉 Slot Table：“这个 Group 只是换了位置，请把它的槽位整体搬移，不要重新执行初始化逻辑”。

---

🏗️ 源码参考

• androidx.compose.runtime.SlotTable
• androidx.compose.runtime.SlotReader / SlotWriter

---

结语

Slot Table 是 Compose 对“声明式编程”最极致的性能优化。它让函数调用的轨迹，变成了可检索、可追溯、可快速移动的内存快照。

下一篇，我们将探讨 UI 树的真实骨架 —— LayoutNode 的生命周期。