Alien Signals 技术分析之订阅者 (Subscriber)(七)
11 分钟
本文深入解析了响应式系统中的订阅者(Subscriber)机制，作为依赖(Dependency)的响应端，订阅者通过deps列表追踪依赖关系，在状态变化时通过flags标记接收通知并执行响应。重点阐述了计算属性(Computed)的惰性求值和副作用(Effect)的自动执行特性，揭示了propagate通知机制和状态标记(Dirty/Pending等)的核心作用。订阅者与依赖的协作构成了响应式系统自动更新的基础，其内部通过Link对象和flags状态实现高效依赖管理，为后续EffectScope等高级特性奠定基础。
在上一章 第 6 章：依赖 (Dependency) 中，我们认识了响应式系统中的“信息发布者”——依赖 (Dependency)，它们负责维护订阅者列表并在自身变化时发出通知。那么，谁是这些信息的接收者呢？谁会“订阅”这些依赖，并在它们变化时做出反应呢？
这一章，我们聚焦于响应式连接的另一端：那个积极响应变化的角色——订阅者 (Subscriber)。
想象一下你订阅了很多在线课程（比如编程课、烹饪课）。这些课程就是 依赖 (Dependency)，它们会不定期发布新的教学视频（数据变化）。作为学生（也就是订阅者），你需要：
如果没有你这个“学生”（订阅者），课程发布再多新视频也没有意义，因为没有人去学习和应用这些知识。
在 alien signals 响应式系统中，订阅者 (Subscriber) 就是这个“学生”。它是响应式系统中的一个核心单元，负责追踪一个或多个 依赖 (Dependency)，并在这些依赖发生变化时做出反应。
典型的订阅者包括我们已经学习过的：
订阅者是响应式系统中主动执行计算或操作的部分，是让整个系统“动起来”的关键。
订阅者主要承担以下职责：
deps)：computed 的 getter 函数或 effect 的 fn 函数）时，依赖追踪与链接 (Tracking & Linking) 机制会自动工作。deps（dependencies，依赖项列表）。这就像学生记录下自己订阅的所有课程。flags)：propagate 函数来通知所有“订阅”了它的订阅者。propagate 函数会找到对应的订阅者，并更新其内部的一个状态标记，我们称之为 flags。这个标记就像给学生发送了一条“新课通知”，并标记了这条通知的状态（例如，“需要注意”、“等待处理”）。常见的标记有 Dirty（表示计算属性需要重新计算）、PendingComputed（表示其依赖的计算属性可能需要更新）、PendingEffect（表示副作用需要被执行）。flags 状态。Dirty 时，它并不会立即重新计算。而是等到下一次有人读取它的值时，它才会检查自己的 flags，发现是 Dirty，然后才执行自己的 getter 函数进行重新计算，并缓存新结果。这是惰性求值的表现。propagate 标记为 PendingEffect 并加入通知队列），响应式系统核心 (Reactive System Core) 的调度器（processEffectNotifications）会在适当的时机（通常是当前更新批次结束后）调用 notifyEffect，从而重新执行该副作用的 fn 函数。让我们回顾一下 计算属性 (Computed) 和 副作用 (Effect) 是如何扮演订阅者角色的。
计算属性 (Computed) 作为订阅者：
输出：
计算属性：正在重新计算 sum...
首次读取 sum: 3
a 变化后，sum 尚未被读取，还未重新计算
计算属性：正在重新计算 sum...
再次读取 sum: 12
解释：
sum 在首次计算时读取了 a 和 b，于是 a 和 b 通过 link 函数将 sum 加入了它们各自的 subs 列表，同时 sum 也将 a 和 b 加入了自己的 deps 列表。a(10) 执行时，a 的 propagate 函数被调用，它找到了订阅者 sum，并将 sum 的 flags 标记为 Dirty。sum() 再次被调用读取时，sum 内部检查到 Dirty 标记，才重新执行 getter 函数。副作用 (Effect) 作为订阅者：
输出：
副作用：counter 当前值为: 0 // effect 首次自动执行
--- counter 更新 ---
副作用：counter 当前值为: 1 // effect 被通知并重新执行
--- counter 再次更新 ---
副作用：counter 当前值为: 2 // effect 再次被通知并重新执行
解释：
loggingEffect 在创建时立即执行一次，读取了 counter，从而建立了依赖关系（counter 的 subs 包含 loggingEffect，loggingEffect 的 deps 包含 counter）。counter(1) 执行时，counter 通过 propagate 通知 loggingEffect，将其标记为需要执行（例如 PendingEffect），并可能将其放入通知队列。processEffectNotifications 函数稍后会处理这个队列，调用 notifyEffect 来重新执行 loggingEffect 的 fn 函数。counter(2) 再次重复这个通知和执行的过程。让我们看看当一个 依赖 (Dependency) 通知一个订阅者时，幕后发生了什么。
signal）的值改变了。propagate): 该依赖调用 响应式系统核心 (Reactive System Core) 的 propagate 函数，传入它自己的订阅者列表 (subs)。propagate 函数遍历 subs 列表中的每个链接 (Link)，找到对应的订阅者 (sub)。flags): 对于每个订阅者，propagate 会根据情况更新其 flags 状态。Dirty 或 PendingComputed。PendingEffect。Notified，表示已收到通知。propagate 可能会将其添加到响应式核心的通知缓冲区 (notifyBuffer) 中。processComputedUpdate 触发。processEffectNotifications 函数会遍历 notifyBuffer，并为每个 effect 调用 notifyEffect。getter 或 fn）被执行时：startTracking(subscriber) 开始新一轮的 依赖追踪与链接 (Tracking & Linking)。link 确认或建立新的依赖关系。endTracking(subscriber) 来清理不再需要的旧依赖，并结束追踪。这个图展示了从依赖变化 -> 核心通知 -> 订阅者状态更新 -> 最终触发订阅者逻辑执行的典型流程。
Subscriber 接口与对象的结构alien signals 在 src/system.ts 中定义了 Subscriber 接口，明确了扮演“订阅者”角色的对象需要具备哪些核心属性：
解释:
Subscriber 接口要求实现者必须有 flags, deps, 和 depsTail。flags: 一个数字，通过位运算存储了订阅者的多种状态。propagate 和核心调度函数会读取和修改这些标志来控制流程。deps: 指向一个由 Link 对象构成的链表的头部。每个 Link 都指向一个该订阅者所依赖的 依赖 (Dependency) 对象 (dep)。这个链表是在订阅者执行期间通过 link 函数动态构建的。depsTail: 指向 deps 链表的尾部。这在 startTracking 和 endTracking 中用于高效地添加和清理依赖链接。Computed 和 Effect 如何实现 Subscriber：
我们在上一章看到，computed 和 effect 在创建时生成的内部对象，不仅可能扮演 Dependency 角色，它们也天然地扮演着 Subscriber 角色：
computed 对象:effect 对象:flags 的作用：
flags 是订阅者状态管理的核心。例如：
propagate 通知一个 computed 时，它会设置 Dirty 或 PendingComputed 标志。computedGetter 执行时，它会检查这些标志来决定是否调用 processComputedUpdate。processEffectNotifications 处理一个 effect 时，它会检查 Notified 和 PendingEffect 等标志，并可能在 notifyEffect 执行后清除它们。startTracking 会设置 Tracking 标志，endTracking 会清除它。通过这些状态标志，响应式系统能够精确地控制每个订阅者的行为，实现高效的懒更新（Computed）和自动执行（Effect）。
在本章中，我们深入探讨了响应式系统中的“信息接收者”和“行动者”——订阅者 (Subscriber)。
deps 列表记录它所依赖的对象，这个列表在执行期间由 依赖追踪与链接 (Tracking & Linking) 自动构建。propagate 更新其内部状态 flags。flags 状态，在适当的时候（惰性读取或调度执行）运行其内部逻辑（getter 或 fn）。flags 属性管理自身状态，使得响应式系统能够进行精确的调度和优化。订阅者就像响应式系统中的“工人”，它们监听着“指令”（依赖变化），并在需要时执行具体的“任务”（计算或副作用）。它们与 依赖 (Dependency) 和 响应式系统核心 (Reactive System Core) 紧密协作，共同构成了 alien signals 自动响应变化的基础。
我们现在已经了解了响应式系统的基本组成部分：存储状态的 信号 (Signal)，派生状态的 计算属性 (Computed)，以及执行操作的 副作用 (Effect)。我们也理解了它们背后的 响应式系统核心 (Reactive System Core)，以及 依赖追踪与链接 (Tracking & Linking)、依赖 (Dependency) 和 订阅者 (Subscriber) 这些内部概念。
特别是副作用（Effect），它们是我们连接响应式状态与外部世界（如 UI 更新、网络请求）的桥梁。但是，当应用变得复杂时，我们可能会创建很多副作用。如何有效地管理这些副作用的生命周期呢？比如，当一个组件卸载时，如何确保与该组件相关的所有副作用都被自动停止，以避免内存泄漏或不必要的计算？
在下一章，我们将学习一个专门用于管理副作用生命周期的工具：副作用作用域 (EffectScope)。