Alien Signals 技术分析之订阅者 (Subscriber)(七)

在上一章 第 6 章：依赖 (Dependency) 中，我们认识了响应式系统中的“信息发布者”——依赖 (Dependency)，它们负责维护订阅者列表并在自身变化时发出通知。那么，谁是这些信息的接收者呢？谁会“订阅”这些依赖，并在它们变化时做出反应呢？

这一章，我们聚焦于响应式连接的另一端：那个积极响应变化的角色——订阅者 (Subscriber)。

什么是订阅者？为什么需要它？

想象一下你订阅了很多在线课程（比如编程课、烹饪课）。这些课程就是 依赖 (Dependency)，它们会不定期发布新的教学视频（数据变化）。作为学生（也就是订阅者），你需要：

1. 知道你订阅了哪些课程：你需要有个列表记录你感兴趣的课程（追踪依赖）。
2. 收到新课通知：当课程发布新视频时，平台需要通知你（接收通知）。
3. 采取行动：收到通知后，你可能会去看新视频、做笔记，或者根据新学的知识做点什么（执行动作或计算）。

如果没有你这个“学生”（订阅者），课程发布再多新视频也没有意义，因为没有人去学习和应用这些知识。

在 alien signals 响应式系统中，订阅者 (Subscriber) 就是这个“学生”。它是响应式系统中的一个核心单元，负责追踪一个或多个 依赖 (Dependency)，并在这些依赖发生变化时做出反应。

典型的订阅者包括我们已经学习过的：

• 计算属性 (Computed)：当它的“原料”（依赖）变化时，它需要重新计算自己的值。
• 副作用 (Effect)：当它关心的状态（依赖）变化时，它需要重新执行指定的操作（比如更新界面）。

订阅者是响应式系统中主动执行计算或操作的部分，是让整个系统“动起来”的关键。

订阅者的核心职责：追踪与响应

订阅者主要承担以下职责：

1. 追踪依赖 (deps)：
2. • 当订阅者执行其内部逻辑（比如 computed 的 getter 函数或 effect 的 fn 函数）时，依赖追踪与链接 (Tracking & Linking) 机制会自动工作。
   • 所有在执行期间被读取的 依赖 (Dependency)（如 信号 (Signal) 或其他 计算属性 (Computed)）都会被记录在订阅者内部的一个列表里，通常称为 deps（dependencies，依赖项列表）。这就像学生记录下自己订阅的所有课程。
2. 接收通知 (flags)：
3. • 当一个被追踪的 依赖 (Dependency) 发生变化时，它会通过 响应式系统核心 (Reactive System Core) 的 propagate 函数来通知所有“订阅”了它的订阅者。
   • propagate 函数会找到对应的订阅者，并更新其内部的一个状态标记，我们称之为 flags。这个标记就像给学生发送了一条“新课通知”，并标记了这条通知的状态（例如，“需要注意”、“等待处理”）。常见的标记有 Dirty（表示计算属性需要重新计算）、PendingComputed（表示其依赖的计算属性可能需要更新）、PendingEffect（表示副作用需要被执行）。
3. 对通知做出反应：
4. • 订阅者如何响应通知，取决于它的类型和当前的 flags 状态。
   • 对于 计算属性 (Computed)：当它被标记为 Dirty 时，它并不会立即重新计算。而是等到下一次有人读取它的值时，它才会检查自己的 flags，发现是 Dirty，然后才执行自己的 getter 函数进行重新计算，并缓存新结果。这是惰性求值的表现。
   • 对于 副作用 (Effect)：当它被标记为需要执行时（比如被 propagate 标记为 PendingEffect 并加入通知队列），响应式系统核心 (Reactive System Core) 的调度器（processEffectNotifications）会在适当的时机（通常是当前更新批次结束后）调用 notifyEffect，从而重新执行该副作用的 fn 函数。

订阅者实例：计算属性和副作用回顾

让我们回顾一下 计算属性 (Computed) 和 副作用 (Effect) 是如何扮演订阅者角色的。

计算属性 (Computed) 作为订阅者：

import { signal, computed } from './src/index.js';

const a = signal(1);
const b = signal(2);

// `sum` 是一个 Computed，它扮演了 Subscriber 的角色
const sum = computed(() => {
  // 1. 追踪依赖：读取 a 和 b，将 a 和 b 加入 sum 的 deps 列表
  const valA = a();
  const valB = b();
  console.log("计算属性：正在重新计算 sum...");
  return valA + valB;
});

console.log("首次读取 sum:", sum()); // 触发首次计算

a(10); // a 变化，a 作为 Dependency，会 propagate 通知它的订阅者 sum

console.log("a 变化后，sum 尚未被读取，还未重新计算");

console.log("再次读取 sum:", sum()); // 读取时，sum 发现自己被标记为 Dirty，触发重新计算

输出：

计算属性：正在重新计算 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) 作为订阅者：

import { signal, effect } from './src/index.js';

const counter = signal(0);

// `loggingEffect` 是一个 Effect，它扮演了 Subscriber 的角色
const loggingEffect = effect(() => {
  // 1. 追踪依赖：读取 counter，将 counter 加入 loggingEffect 的 deps 列表
  const count = counter();
  console.log("副作用：counter 当前值为:", count);
});

console.log("--- counter 更新 ---");
counter(1); // counter 变化，会 propagate 通知 loggingEffect，并调度其执行

console.log("--- counter 再次更新 ---");
counter(2); // 再次触发 propagate 和调度执行

输出：

副作用：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) 通知一个订阅者时，幕后发生了什么。

非代码内部流程

1. 依赖变化: 某个 依赖 (Dependency)（比如一个 signal）的值改变了。
2. 传播通知 (propagate): 该依赖调用 响应式系统核心 (Reactive System Core) 的 propagate 函数，传入它自己的订阅者列表 (subs)。
3. 遍历与标记: propagate 函数遍历 subs 列表中的每个链接 (Link)，找到对应的订阅者 (sub)。
4. 更新状态 (flags): 对于每个订阅者，propagate 会根据情况更新其 flags 状态。
5. • 如果订阅者是 计算属性 (Computed)，可能会被标记为 Dirty 或 PendingComputed。
   • 如果订阅者是 副作用 (Effect)，可能会被标记为 PendingEffect。
   • 同时，订阅者通常会被标记为 Notified，表示已收到通知。
5. 放入队列 (可选): 如果订阅者是 副作用 (Effect) 并且需要执行，propagate 可能会将其添加到响应式核心的通知缓冲区 (notifyBuffer) 中。
6. 调度执行: 在适当的时候（例如，当前代码执行栈或批处理结束后），响应式核心会处理这些通知：
7. • 对于需要重新计算的 计算属性 (Computed)，更新会在它下次被读取时由 processComputedUpdate 触发。
   • 对于需要执行的 副作用 (Effect)，processEffectNotifications 函数会遍历 notifyBuffer，并为每个 effect 调用 notifyEffect。
7. 执行与再追踪: 当订阅者的逻辑（getter 或 fn）被执行时：
8. • 系统会调用 startTracking(subscriber) 开始新一轮的 依赖追踪与链接 (Tracking & Linking)。
   • 在执行过程中读取依赖时，会通过 link 确认或建立新的依赖关系。
   • 执行完毕后，系统会调用 endTracking(subscriber) 来清理不再需要的旧依赖，并结束追踪。

简化序列图：依赖通知订阅者

这个图展示了从依赖变化 -> 核心通知 -> 订阅者状态更新 -> 最终触发订阅者逻辑执行的典型流程。

代码实现：Subscriber 接口与对象的结构

alien signals 在 src/system.ts 中定义了 Subscriber 接口，明确了扮演“订阅者”角色的对象需要具备哪些核心属性：

// src/system.ts (简化)
export interface Subscriber {
	flags: SubscriberFlags;     // 存储订阅者的状态标记 (e.g., Dirty, PendingEffect, Tracking)
	deps: Link | undefined;     // 指向该订阅者所依赖的 Dependency 链表的第一个链接
	depsTail: Link | undefined; // 指向依赖链表的最后一个链接，用于依赖追踪优化
}

// SubscriberFlags 枚举 (部分)
export const enum SubscriberFlags {
	Computed = 1 << 0,        // 标记为计算属性
	Effect = 1 << 1,          // 标记为副作用
	Tracking = 1 << 2,        // 标记正在追踪依赖
	Notified = 1 << 3,        // 标记已收到通知
	Dirty = 1 << 5,           // 标记计算属性需要重新计算
	PendingComputed = 1 << 6, // 标记依赖的计算属性可能需要更新
	PendingEffect = 1 << 7,   // 标记副作用需要执行
	// ... 其他标记 ...
}

// Link 对象结构 (回顾)
export interface Link {
	dep: Dependency | (Dependency & Subscriber); // 指向依赖对象
	sub: Subscriber | (Dependency & Subscriber); // 指向订阅者对象
	nextDep: Link | undefined; // 指向订阅者的下一个依赖链接 (构成 deps 链表)
	// ... 其他字段 ...
}

解释:

• Subscriber 接口要求实现者必须有 flags, deps, 和 depsTail。
• flags: 一个数字，通过位运算存储了订阅者的多种状态。propagate 和核心调度函数会读取和修改这些标志来控制流程。
• deps: 指向一个由 Link 对象构成的链表的头部。每个 Link 都指向一个该订阅者所依赖的 依赖 (Dependency) 对象 (dep)。这个链表是在订阅者执行期间通过 link 函数动态构建的。
• depsTail: 指向 deps 链表的尾部。这在 startTracking 和 endTracking 中用于高效地添加和清理依赖链接。

Computed 和 Effect 如何实现 Subscriber：

我们在上一章看到，computed 和 effect 在创建时生成的内部对象，不仅可能扮演 Dependency 角色，它们也天然地扮演着 Subscriber 角色：

• computed 对象:

// src/index.ts (computed 创建简化示意)
const computedObject: Computed<T> = {
  // ... 作为 Dependency 的属性 (currentValue, subs, subsTail) ...
  deps: undefined,     // !! 符合 Subscriber 接口，初始无依赖 !!
  depsTail: undefined, // !! 符合 Subscriber 接口 !!
  flags: SubscriberFlags.Computed | SubscriberFlags.Dirty, // !! 符合 Subscriber 接口，初始标记 !!
  getter: getter,      // Computed 特定属性
};

• effect 对象:

// src/index.ts (effect 创建简化示意)
const e: Effect = {
  fn,                  // Effect 特定属性
  // ... 作为 Dependency 的属性 (subs, subsTail) ...
  deps: undefined,     // !! 符合 Subscriber 接口，初始无依赖 !!
  depsTail: undefined, // !! 符合 Subscriber 接口 !!
  flags: SubscriberFlags.Effect, // !! 符合 Subscriber 接口，初始标记 !!
};

flags 的作用：

flags 是订阅者状态管理的核心。例如：

• 当 propagate 通知一个 computed 时，它会设置 Dirty 或 PendingComputed 标志。
• 当 computedGetter 执行时，它会检查这些标志来决定是否调用 processComputedUpdate。
• 当 processEffectNotifications 处理一个 effect 时，它会检查 Notified 和 PendingEffect 等标志，并可能在 notifyEffect 执行后清除它们。
• startTracking 会设置 Tracking 标志，endTracking 会清除它。

通过这些状态标志，响应式系统能够精确地控制每个订阅者的行为，实现高效的懒更新（Computed）和自动执行（Effect）。

总结

在本章中，我们深入探讨了响应式系统中的“信息接收者”和“行动者”——订阅者 (Subscriber)。

• 订阅者是响应式系统中追踪 依赖 (Dependency) 并在其变化时做出反应的单元。
• 典型的订阅者是 计算属性 (Computed) 和 副作用 (Effect)。
• 订阅者的核心职责是：
• • 追踪依赖：通过 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)。