Vuetify 3.5 的响应式系统经过重大重构，性能提升了 56%，主要得益于双向链表的使用。这篇文章将解释它是如何通过双向链表实现依赖收集和触发的，帮助你掌握 Vuetify 3.5 的响应式原理。
什么是响应式系统
Vuetify 的响应式系统让界面能自动更新数据变化。在 Vuetify 3.5 之前，系统用简单列表跟踪依赖，效率可能较低。新版本引入双向链表，优化了性能。
新系统的核心组件
新系统有三个角色：
Dep：代表响应式数据，如 ref 或 reactive 的属性。
Sub：代表订阅者，如 watchEffect 或 watch。
Link：连接 Dep 和 Sub 的节点，形成双向链表。
依赖收集过程
当 Sub（如 watchEffect）读取 Dep（如 ref）时：
创建一个 Link 节点，连接当前 Sub 和 Dep。
Link 被添加到 Sub 的依赖列表和 Dep 的订阅者列表中。
依赖触发过程
当 Dep 变化时：
从 Dep 的订阅者列表尾部开始，通过 prevSub 指针逐个通知 Sub，执行更新。
意外的细节
一个有趣的发现是，通知顺序从尾到头，可能优化了缓存使用，但具体原因未明确。
调查笔记：Vuetify 3.5 响应式系统的详细分析
Vuetify 3.5 版本的响应式系统是其性能提升的核心，声称通过双向链表和版本计数实现了 56% 的性能改进。本文将深入探讨如何使用双向链表实现依赖收集和触发，基于用户提供的代码示例和相关分析。
背景与动机
Vuetify 的响应式系统旨在通过自动跟踪数据变化来更新视图，简化状态管理。在 Vuetify 3.5 之前，系统主要依赖于订阅者（Sub，如 watchEffect、watch、render 函数、computed）和依赖（Dep，如 ref、reactive）的多对多关系。这种关系通过直接列表管理，但可能在高频插入、删除或遍历时效率较低。Vuetify 3.5 的重构引入了双向链表，试图优化这些操作。
性能提升的 56% 归因于双向链表和版本计数，其中版本计数未在本讨论中深入，但用户提到可另文探讨。我们的重点是双向链表如何改进依赖收集和触发。
系统组件
新的响应式系统包含三个主要角色：
Dep（依赖）：
表示响应式数据项，如 ref 或 reactive 对象的属性。
属性包括：
subs: 指向订阅者链表的尾部节点。
track: 用于依赖收集的函数，在读取操作时触发。
trigger: 用于依赖触发的函数，在写入操作时触发。
Subscriber（订阅者）：
表示依赖于数据的代码片段，如 watchEffect、watch 等。
属性包括：
deps: 指向依赖链表的头部节点。
depsTail: 指向依赖链表的尾部节点。
notify: 执行依赖的函数，如重新运行 watchEffect 的回调。
Link（链接节点）：
作为桥梁，连接特定的 Subscriber 和 Dep。
属性包括：
sub: 指向 Subscriber。
dep: 指向 Dep。
nextDep 和 prevDep: 用于 Subscriber 的依赖链表（X 轴）。
nextSub 和 prevSub: 用于 Dep 的订阅者链表（Y 轴）。
这些组件通过双向链表形成网格结构，Dep 和 Subscriber 不再直接连接，而是通过 Link 间接关联。
依赖收集过程
依赖收集发生在订阅者执行期间，读取依赖时触发。以下是详细步骤，基于用户提供的代码示例：
ts
import { ref, watchEffect } from "vue"; let dummy1, dummy2; const counter1 = ref(1); // Dep1 const counter2 = ref(2); // Dep2 watchEffect(() => { // Sub1 dummy1 = counter1.value + counter2.value; console.log("dummy1", dummy1); }); watchEffect(() => { // Sub2 dummy2 = counter1.value + counter2.value + 1; console.log("dummy2", dummy2); }); counter1.value++; counter2.value++;
初始化：
counter1 和 counter2 是 Dep 对象。
两个 watchEffect 是 Subscriber 对象。
第一个 watchEffect（Sub1）执行：
读取 counter1.value，触发 Dep1 的 get 拦截，调用 track。
track 创建新 Link1，sub 指向 Sub1，dep 指向 Dep1。
将 Link1 添加到 Sub1 的依赖列表：
若 Sub1 无依赖，deps 和 depsTail 均指向 Link1。
否则，Link1 的 prevDep 指向当前 depsTail，depsTail.nextDep 指向 Link1，更新 depsTail 为 Link1。
调用 addSub(Link1)，将 Link1 添加到 Dep1 的订阅者列表：
Dep1 的 subs 指向链表尾部，若无节点，subs 直接指向 Link1；否则，Link1 的 prevSub 指向当前尾部，尾部的 nextSub 指向 Link1，更新 subs 为 Link1。
接着读取 counter2.value，类似地创建 Link2，连接 Sub1 和 Dep2，添加到各自列表。
第二个 watchEffect（Sub2）执行：
类似地，读取 counter1.value 和 counter2.value，创建 Link3（Sub2-Dep1）和 Link4（Sub2-Dep2）。
这些 Link 被添加到 Sub2 的依赖列表和 Dep1、Dep2 的订阅者列表。
例如，Dep1 的订阅者列表最终为 Link1（Sub1）<- Link3（Sub2），Link3 为尾部。
最终，系统形成如下的双向链表结构：
Sub1 的依赖列表：Link1（Dep1）-> Link2（Dep2）。
Sub2 的依赖列表：Link3（Dep1）-> Link4（Dep2）。
Dep1 的订阅者列表：Link1（Sub1）<- Link3（Sub2），尾部为 Link3。
Dep2 的订阅者列表：Link2（Sub1）<- Link4（Sub2），尾部为 Link4。
依赖触发过程
当依赖值改变时，触发其 trigger 方法通知所有订阅者。以下是详细步骤：
改变 counter1.value：
触发 Dep1 的 set 拦截，调用 trigger。
从 Dep1 的 subs（指向 Link3，尾部）开始。
使用 prevSub 指针遍历：先访问 Link3，通知 Sub2（Link3.sub.notify()）；然后访问 Link1，通知 Sub1（Link1.sub.notify()）。
顺序为 Sub2 然后 Sub1，反映链表从尾到头的遍历。
改变 counter2.value：
类似地，从 Dep2 的 subs（指向 Link4）开始，遍历 Link4->Link2，通知 Sub2 然后 Sub1。
这种从尾到头的遍历可能与性能优化或依赖顺序有关，但目前文档未明确说明。
性能提升分析
双向链表的引入可能带来以下优势：
高效插入和删除：链表的插入和删除为 O(1)，相比数组的可能需要移位，减少开销。
遍历优化：从尾到头的遍历可能利用缓存局部性，减少内存访问延迟。
内存效率：对于动态变化的依赖关系，链表可能比数组更节省内存，尤其在高频添加移除场景。
然而，具体为何性能提升 56%，可能涉及版本计数的协同作用，用户提到可另文探讨。我们推测，链表结构减少了管理依赖关系的开销，特别是在大规模应用中。
对比旧系统
旧系统（Vuetify 3.5 之前）中，Dep 和 Sub 直接通过列表（如数组或集合）管理关系。这种方式在高频操作下可能效率较低：
数组插入删除可能涉及移位，时间复杂度为 O(n)。
遍历可能受缓存不友好影响。
新系统通过 Link 作为桥梁，形成了双向链表，优化了这些操作，尤其适合动态依赖关系的场景。
意外细节
一个可能未预料到的细节是通知顺序从尾到头（通过 prevSub），这可能与某些依赖的执行顺序优化有关，但目前尚无明确文档解释其具体优势。
总结
Vuetify 3.5 的响应式系统通过双向链表优化了依赖收集和触发，涉及 Dep、Subscriber 和 Link 的协作。依赖收集时，Link 被添加到双方的链表；依赖触发时，从尾部开始遍历，逐个通知订阅者。这种结构提升了插入、删除和遍历效率，可能解释了 56% 的性能提升。