Vue 3 早期响应式系统与 Alien Signals 优化对比

伪代码如下

具体的工作流程

2.2 特性与影响

• 默认深度响应式: 这是 Vue 3 早期响应式系统的一个显著特点。它为开发者提供了便利，修改嵌套对象的属性也能自动触发更新，降低了心智负担。然而，这种“魔法”并非没有代价。对于包含大量属性、层级很深或者本身是不可变的数据结构（例如来自 API 的大型只读数据），深度响应式会带来不必要的性能开销。因为每一次对嵌套属性的访问都会触发 Proxy 的 get 陷阱，执行依赖追踪逻辑，即使这些属性很少变化或根本不被任何 effect 依赖。  
• 运行时依赖收集: 依赖关系是在代码运行时，当 effect 函数实际执行并访问响应式属性时才被收集的。这种方式灵活，不需要编译时分析，但意味着依赖关系可能会随着代码分支的执行而动态变化。  
• 更新触发: 当一个响应式属性被修改时，trigger 函数会查找并调度所有依赖该属性的 effect 重新执行。在组件场景下，这通常意味着整个组件的 render 函数会被重新调用。  

2.3 已识别的局限性与性能考量

随着 Vue 3 的应用深入，其早期响应式系统的一些局限性和性能瓶颈逐渐显现：

• 响应式开销: 对于大型或深层嵌套的对象，Proxy 陷阱的调用和依赖追踪本身会产生一定的运行时开销。当一个操作（如组件渲染）需要访问成千上万个属性时（例如处理一个包含 10 万个属性的大型状态对象），这种累积的开销可能变得非常显著，影响性能。  
• VDOM 交互成本: 响应式系统触发的更新（通常是组件重新渲染）与 VDOM 机制紧密相连。组件重新渲染会生成新的 VDOM 树，然后与旧树进行比较（diffing），找出差异并将其应用（patch）到真实 DOM 上。VDOM diffing 和 patching 本身需要计算资源和内存。对于大型列表或复杂的组件树，这个过程可能成为性能瓶颈。虽然 Vue 3 的编译器通过静态分析和优化（如 patch flags）来减少 VDOM 开销，但 VDOM 本身的机制仍存在固有的成本。Vapor Mode 的提出正是为了从根本上解决 VDOM 带来的这部分开销。  
• 手动优化需求: 为了解决深度响应式的性能问题，Vue 3 提供了 shallowRef(), shallowReactive() 和 markRaw() 等 API。shallowRef 和 shallowReactive 只对对象的顶层属性进行响应式处理，内部嵌套的对象保持原样，访问它们不会触发依赖追踪。markRaw 则完全阻止一个对象被转换为代理。虽然这些 API 提供了优化手段，但它们要求开发者对响应式系统的内部机制有更深入的理解，并需要手动识别性能瓶颈并应用这些优化，增加了开发复杂性。这本身也说明了默认的深度响应式机制并非在所有场景下都是最优解。  
• 边缘情况: 如前所述，解构原始类型属性或替换整个响应式对象引用时丢失响应性的问题，虽然有文档说明，但仍是开发者容易遇到的坑。  

总结来说，Vue 3 早期的 Proxy 响应式系统虽然功能强大且易于上手，其默认的深度响应式特性在简化开发的同时，也隐藏了潜在的性能问题。当应用规模扩大、状态变得复杂时，开发者需要借助额外的 API 进行手动优化，这表明核心机制本身存在优化空间。VDOM 作为更新视图的主要手段，其固有的开销也与响应式系统的触发机制相互影响，共同构成了 Vue 3 早期性能优化的主要关注点。

3. Alien Signals 简介：以性能为中心的演进

面对早期响应式系统在高负载场景下的性能挑战，以及业界对更高效响应式模型的探索（如 SolidJS 的成功），Vue 核心团队成员启动了对响应式引擎进行深度优化的研究，Alien Signals 正是这项研究的产物。

3.1. 动机：解决性能瓶颈

Alien Signals 的核心目标是创建一个性能极致、开销更低的响应式系统。它旨在直接解决早期 Proxy 系统中观察到的性能瓶颈，例如深度追踪的开销和与 VDOM 更新相关的间接成本。根据初步基准测试和社区讨论，Alien Signals 在某些响应式密集型场景下展现出显著的性能提升，甚至有提及高达 400% 的性能增长。  

更重要的是，这种底层的响应式优化被视为实现更宏大架构目标（如 Vapor Mode）的关键基石。Vapor Mode 旨在通过编译时优化彻底消除 VDOM，生成直接操作 DOM 的代码。这种模式高度依赖一个极其高效和细粒度的响应式系统来精确地触发最小化的 DOM 更新。Alien Signals 正是为了满足这种需求而设计的底层引擎。  

3.2. 核心概念与设计哲学

Alien Signals 的设计借鉴了响应式系统领域的一些成熟思想，并加入了独特的性能优化策略：

• 信号 (Signals) 作为原语: 与 SolidJS、Preact Signals 和 Angular Signals 类似，Alien Signals 也将“信号”作为其核心的响应式原语。这通常包括：
• • signal: 创建一个可变的信号源，持有基本状态值。
  • computed: 创建一个计算信号，其值根据其他信号衍生而来，并且是惰性计算和缓存的。
  • effect: 创建一个副作用，当其依赖的信号发生变化时自动重新执行。
• 推拉结合 (Push-Pull) 机制: 这是 Alien Signals 算法的一个关键特征。当一个信号源的值发生变化时（“推”阶段），它会通知其直接或间接的依赖者（计算信号和副作用），将它们标记为“脏”（dirty）或可能需要更新。然而，实际的重新计算（对于 computed）或重新执行（对于 effect）通常会被推迟到它们的值被实际访问时（“拉”阶段），或者由调度器在稍后的某个时间点统一处理。这种惰性求值的策略可以避免不必要的计算，特别是当一个信号变化导致多个依赖项变脏，但只有部分依赖项的值最终被使用时。  
• 细粒度追踪 (Fine-Grained Tracking): 设计目标是实现非常精细的依赖追踪，直接将信号源与其精确的消费者（计算信号或副作用）联系起来。这使得更新能够更精确地定位到真正需要变化的部分，为 Vapor Mode 等编译器优化提供基础。  
• 性能约束: 为了达到极致性能，Alien Signals 在实现上施加了一些刻意的约束：
• • 避免内建集合: 在核心的传播逻辑中，不使用 JavaScript 内建的 Array, Set, Map 数据结构。这可能是因为这些通用集合在特定场景下（如频繁增删、大量小对象）可能引入额外的内存或性能开销（如哈希冲突、垃圾回收压力）。
  • 禁止递归: 在核心的依赖传播函数（如 propagate）中，避免使用函数递归调用。递归虽然在表达树状或图状遍历时很自然，但在深度依赖链中可能导致调用栈过深，甚至栈溢出，且函数调用本身也有开销。
  • 追求算法简洁性: 开发者发现，在上述约束下，保持核心算法的简洁性比实现复杂的调度策略能带来更显著的性能提升。这表明优化的重点在于基础操作的效率。  

3.3. 算法方法与数据结构

Alien Signals 采用了一些特定的技术来实现其性能目标：

• 链表 (Linked Lists): 为了高效管理依赖关系和订阅，Alien Signals 使用了链表结构（类似于 Preact Signals 的双向链表）。相比于标准的 Map 或 Set，链表在节点的插入和删除操作上可以达到 O(1) 的时间复杂度（如果持有节点的引用），并且在遍历时可能具有更好的缓存局部性。这种数据结构特别适合构建和维护信号之间的依赖图。
• propagate 与 checkDirty 函数: 这两个函数（或类似逻辑）是推拉机制的核心。
• • propagate: 当一个信号源变化时，此函数负责沿着依赖图（通过链表）进行遍历。它不会立即执行更新，而是将下游的计算信号或副作用标记为需要重新检查或更新（例如，设置一个 Dirty 状态标志）。
  • checkDirty: 在“拉”阶段（例如，当访问一个 computed 信号的值时）或由调度器触发时，checkDirty 会检查目标的“脏”状态。如果标记为脏，它会触发必要的重新计算或副作用执行。
• 避免递归的实现: 为了在 propagate 和 checkDirty 中消除递归，Alien Signals 采用了一种迭代式的实现方式。根据文档描述，它通过记录上一次循环的最后一个链表节点，并实现回滚逻辑来返回到该节点，从而在循环中处理依赖传播。虽然这种实现方式可能更难理解，但它避免了递归带来的性能开销和潜在的栈限制。  
• 状态标志 (State Flags): 为了高效地管理每个订阅者（信号或副作用）的状态（例如，是否脏、是否正在追踪、是否已通知等），Alien Signals 使用了位运算标志 (SubscriberFlags)。通过位掩码操作，可以在一个整数上存储和查询多个布尔状态，这比使用多个布尔属性或对象更节省内存和计算资源。  

内部类图

响应式流程图