MobX 性能优化：深入理解计算属性的缓存机制

在最近对 MobX 的基准测试中，我们发现了一个有趣的性能问题。当大规模使用计算属性（computed）时，如果不遵循 MobX 的最佳实践，会导致严重的性能下降。本文将深入分析这一现象背后的原因，并探讨如何正确使用 MobX 的计算属性以获得最佳性能。

问题现象

在基准测试场景中，我们构建了一个多层级的响应式数据图：

1. 底层是基础信号（signal）
2. 中间层是依赖下层信号的计算属性
3. 顶层是最终的计算属性（叶子节点）

测试通过以下方式运行：

1. 修改底层信号的值
2. 读取顶层计算属性的值
3. 重复数千次

测试结果显示，MobX 在这种场景下的性能明显低于其他响应式库，甚至在某些情况下会出现"卡死"现象。

根本原因分析

经过深入调查，我们发现问题的根源在于计算属性的缓存机制。MobX 的计算属性有以下特点：

1. 无观察者时的行为：当计算属性没有被任何反应（reaction）或观察者（observer）跟踪时，它们不会保持缓存状态。每次读取都会重新计算。

2. 临时批处理：计算属性在被读取时会创建一个临时批处理上下文。在这个上下文中，如果同一个计算属性被多次读取，会被缓存。但一旦计算完成，所有缓存都会被清除。

3. 依赖关系维护：只有在被观察的情况下，MobX 才会维护计算属性之间的依赖关系图。

在基准测试中，由于没有设置任何观察者，计算属性每次都被当作普通getter使用，导致性能急剧下降。

解决方案

要解决这个问题，有以下几种方法：

1. 使用批处理（batch）

framework.withBatch(() => {
  // 在此上下文中读取计算属性会被缓存
  for (const leaf of readLeaves) {
    leaf.read();
  }
});

批处理上下文会临时保持计算属性的缓存状态，适合在短时间内多次读取的场景。

2. 添加观察者

autorun(() => {
  // 在此反应中读取的计算属性会被持续观察和缓存
  for (const leaf of readLeaves) {
    leaf.read();
  }
});

这是最符合MobX设计理念的解决方案，计算属性会被持续缓存，直到观察者被销毁。

3. 使用keepAlive选项

computed(fn, { keepAlive: true })

这个选项会强制保持计算属性的缓存状态，即使没有被观察。但要注意内存泄漏风险。

最佳实践建议

1. 始终确保计算属性被观察：MobX的设计初衷是用于有明确观察者的场景，如React组件。

2. 合理使用批处理：对于需要频繁读写操作的场景，使用runInAction或transaction进行批处理。

3. 避免孤立计算属性：没有观察者的计算属性应该被视为临时计算，不适合作为核心状态。

4. 性能关键路径测试：对于性能敏感的场景，应该在实际使用模式下进行测试，包括观察者的设置和销毁。

总结

MobX的计算属性机制是为了在有观察者的场景下提供最佳性能而设计的。理解这一设计理念对于正确使用MobX至关重要。在基准测试或性能关键的应用中，确保计算属性被适当观察或使用批处理，可以避免不必要的性能损失。

这一案例也提醒我们，在比较不同响应式库时，需要考虑它们各自的设计哲学和最佳实践，才能得出公平、有意义的结论。