Alien Signals 技术分析之依赖追踪与链接 (Tracking & Linking)(五)

2. 读取与链接 (link)

当目标人物（activeSub）接触到一个线索（读取一个 信号 (Signal) 或 计算属性 (Computed)）时，侦探需要记录下来并建立档案。

• 何时发生？ 当 activeSub 存在（即系统处于追踪模式下）时，并且代码执行了 someSignal() 或 someComputed() 这样的读取操作。
• 做什么？
• • 读取操作（比如 signalGetterSetter 或 computedGetter）会检查全局的 activeSub 是否有值。
  • 如果有，就调用核心的 link(dependency, subscriber) 函数（dependency 是被读取的信号或计算属性对象，subscriber 就是 activeSub）。
  • link 函数负责建立双向链接：
  • • 将 subscriber 添加到 dependency 的订阅者列表 (subs) 中。（记录下：“这个信号被这个订阅者关注了”）
    • 将 dependency 添加到 subscriber 的依赖列表 (deps) 中。（记录下：“这个订阅者依赖于这个信号”）
  • 这样，依赖图中的一条边就建立起来了。

3. 结束追踪 (endTracking)

侦探完成了本次跟踪任务。

• 何时发生？ 在订阅者的函数执行完毕后（比如 updateComputed 或 notifyEffect 的 finally 块中）。
• 做什么？
• • 清理旧依赖: 这是 endTracking 的一个重要工作。在 startTracking 时，系统准备清空旧依赖。在追踪过程中，每次 link 操作都会标记一个依赖是“新的”或“仍然有效”。endTracking 会检查哪些旧的依赖在这次执行中没有被再次 link，并将这些无效的链接从双方（依赖的 subs 和订阅者的 deps）中断开。这确保了依赖关系总是最新的。这个清理工作通常由内部的 clearTracking 函数完成。
  • 清除之前设置的 Tracking 标志。
  • 恢复全局的 activeSub 到它之前的值（可能为 undefined 或外层的另一个订阅者）。

工作流程：探索如何建立档案

让我们通过 fullName 首次计算的场景，看看这个过程是如何运作的：

1. 触发计算: 当代码首次读取 fullName() 时，computedGetter 被调用。
2. 检查状态: fullName 发现自己是 Dirty（需要计算）。
3. 准备追踪: processComputedUpdate 调用 updateComputed，接着调用 startTracking(fullName)。
4. • activeSub 被设置为 fullName 对象。
   • fullName 的旧 deps 准备被清理。
   • fullName 被标记为 Tracking。
4. 执行 Getter: 系统开始执行 fullName 的计算函数：() => firstName() + lastName()。
5. 读取 firstName():
6. • firstName 的 signalGetterSetter 被调用（无参数读取模式）。
   • 它检测到 activeSub 是 fullName (非 undefined)。
   • 调用 link(firstName, fullName)。
   • • fullName 被添加到 firstName 的 subs 列表。
     • firstName 被添加到 fullName 的 deps 列表，并被标记为有效。
6. 读取 lastName():
7. • 类似地，lastName 的 signalGetterSetter 检测到 activeSub 是 fullName。
   • 调用 link(lastName, fullName)。
   • • fullName 被添加到 lastName 的 subs 列表。
     • lastName 被添加到 fullName 的 deps 列表，并被标记为有效。
7. Getter 执行完毕: 计算函数返回结果 "张三"。
8. 结束追踪: updateComputed 的 finally 块调用 endTracking(fullName)。
9. • clearTracking 运行：由于 firstName 和 lastName 都被标记为有效，没有旧的、无效的依赖需要清理。
   • fullName 的 Tracking 标志被移除。
   • activeSub 恢复为之前的值（在这个例子中可能是 undefined）。
9. 缓存与返回: fullName 缓存结果 "张三"，清除 Dirty 标记，并返回值。

现在，系统已经成功记录了：fullName 依赖于 firstName 和 lastName。如果之后 firstName 变化，propagate 就知道要通知 fullName 了。

同样的过程也发生在 greetingEffect 首次执行时，它会通过 startTracking(greetingEffect)、读取 fullName() 时调用 link(fullName, greetingEffect)、以及最后的 endTracking(greetingEffect)，建立起 fullName 到 greetingEffect 的依赖链接。

内部机制：追踪与链接的代码实现

让我们简单看下 system.ts 中这几个核心函数的简化逻辑。

startTracking(sub)

解释:

• depsTail 是一个指向订阅者依赖链表（deps）末尾的指针，用于优化 link 操作。重置它表示开始一轮新的依赖检查。
• 设置 Tracking 标志，同时清除一些可能由 propagate 设置的状态标志，确保一个干净的追踪环境。

link(dep, sub)

解释:

• 这段代码的核心是创建一个 Link 对象，并将其正确地插入到两个双向链表中：订阅者的 deps 链表和依赖的 subs 链表。
• depsTail 和 subsTail 指针用于快速定位链表末尾，方便添加新链接。
• 更新 sub.depsTail = newLink 非常关键，它标记了这个依赖在当前追踪轮次中是活跃的，endTracking 时会用到。

endTracking(sub)

解释:

• endTracking 的主要职责是利用 depsTail 指针来识别并清理那些在当前执行周期内没有被重新 link 的旧依赖。
• 它通过调用 clearTracking (未显示，但其作用是从依赖的 subs 链表中移除链接) 来完成清理工作。
• 最后清除 Tracking 标志，表示依赖追踪结束。

依赖追踪流程图

让我们用一个简化的序列图来展示这个过程：

这个图清晰地展示了 startTracking、link 和 endTracking 如何协同工作，在订阅者执行期间动态地构建和维护依赖关系。

总结

在本章中，我们深入了解了 master 响应式系统自动管理依赖的关键机制：依赖追踪与链接 (Tracking & Linking)。

• 这是响应式系统能够自动响应变化的基础。系统无需我们手动声明，就能在运行时动态发现“谁依赖谁”。
• 依赖追踪 (Tracking) 通过 startTracking 和 endTracking 界定一个订阅者（计算属性 (Computed) 或 副作用 (Effect)）的执行上下文，并使用全局标记 activeSub 来标识当前活动的订阅者。
• 链接 (Linking) 通过 link 函数实现。当处于追踪状态的订阅者读取一个依赖（信号 (Signal) 或 计算属性）时，link 会在它们之间建立双向链接，更新依赖的订阅者列表 (subs) 和订阅者的依赖列表 (deps)。
• endTracking 负责清理在当前执行周期内不再需要的旧依赖关系，确保依赖图的准确性。

这个过程就像一个不知疲倦的侦探，时刻观察着数据的流动，精确地记录下所有的关联，为后续的精确通知（propagate）打下坚实的基础。

下一步

我们现在知道了依赖关系是如何被动态发现和建立起来的 (link)。那么，构成这些关系的两端——那个被依赖的东西（比如 信号 (Signal)）和那个依赖别人的东西（比如 计算属性 (Computed) 或 副作用 (Effect)）——它们在系统内部是如何表示的？它们有哪些共同的特性和不同的职责？

在下一章，我们将分别聚焦于这两个核心角色：依赖 (Dependency) 和 订阅者 (Subscriber)，深入了解它们的数据结构和在响应式系统中的具体作用。