使用MobX时选更多小store还是更少大store？需注意哪些性能问题？

搭建MobX状态架构的性能注意事项 #

• 控制可观察对象的粒度：尽可能将状态拆分为最小粒度的可观察单元，仅把需要响应式更新的属性声明为可观察，避免单个可观察对象挂载数十个以上的属性，减少MobX的依赖追踪开销。
• 合理控制observer的包装范围：仅给需要响应状态变化的组件套observer装饰器，列表场景下建议把列表项单独封装为observer组件，避免单个数据变动触发全列表重渲染。
• 优先使用computed声明派生值：所有需要从原始状态计算得到的衍生值，都用computed装饰器声明，MobX会自动缓存计算结果，仅当依赖的原始状态变动时才会重新计算，避免渲染时重复计算的性能损耗。
• 避免全量替换可观察对象：不要直接对可观察的数组、对象做全量赋值操作，尽量用增量更新的方法修改数据，减少响应更新的触发范围。
• 不要在可观察对象中存储冗余数据：临时变量、常量、不需要响应的非业务状态不要挂载到store的可观察对象上，降低不必要的依赖追踪成本。

小Store与大Store的实践优先级与性能差异 #

业内普遍认为按照业务领域拆分的多小Store是更优的实践方案，仅在超小型、业务逻辑极简单的项目中可以用单一大Store。

二者的性能差异主要体现在以下两点：

• 依赖追踪开销差异：大Store的状态集中，MobX需要维护的依赖树更庞大，任意状态变动时的依赖遍历成本更高；小Store的状态仅覆盖单一业务域，依赖树更轻量，状态变动时的依赖检查成本更低。
• 无效更新范围差异：大Store的状态没有天然隔离，很容易因为不合理的状态引用，导致非相关业务的组件被误触发重渲染；小Store的状态天然按业务域隔离，状态变动的影响范围基本被限制在对应业务的组件内，出现无效更新的概率低很多。

需要注意的是Store拆分也不是越细越好，拆分粒度过细会提升跨Store状态共享的维护成本，一般按照业务模块边界拆分即可，比如用户Store、订单Store、商品Store各自独立，不需要把单个业务模块的状态再拆成多个子Store。

内容的提问来源于stack exchange，提问作者metropolis4