为什么 Context API 在高频更新方面比 Redux 差？

Question

我看到很多文章都说Redux比高频更新在性能上优于Context API，但没有具体说明原因。

为什么人们会说 Redux 比 Context API 更适合高频更新？

Answer 1

我在我的文章为什么 React Context 不是“状态管理”工具（以及为什么它不取代 Redux）、React、Redux 和上下文行为以及React 的历史和实现中对此进行了广泛的介绍-Redux.

总结：目前，将新值传递到

<MyContext.Provider>

会强制订阅该上下文的每个组件重新渲染。如果组件只关心上下文值的部分并且该部分没有改变，则没有办法摆脱困境。

此外，React 目前必须做大量的工作来循环整个组件树，以找出

哪些组件订阅了给定的上下文。 另一方面，React-Redux 依赖于对 Redux 存储的直接订阅。它在分派操作时运行您的选择器，并且仅在提取的数据发生更改时强制该组件重新渲染。因此，目前，在大多数情况下，这比 Context 提供了更好的性能，因为针对给定的更改需要重新渲染的组件更少。

React 团队

已经

一直致力于“上下文选择器”和“惰性上下文传播”的一些潜在实现，这可能有助于将来加快速度。目前还没有发布这些内容的时间表。

Answer 2

是的，因为 context API 会重新渲染每个订阅的组件，如 markikson 提到的那样。但有解决方法。

经过一番研究，我发现了这篇文章。 提到了 4 种方法。我在我的项目中尝试了“容器”。它确实解决了我的性能问题。

https://www.basefactor.com/global-state-with-react

Answer 3

MobX

代替Redux，使用起来更简单。 在我看来，MOBx 效率更高，并且代码也更干净。

它具有出色的性能，我认为在大多数情况下甚至比 Redux 还要好。但我把超性能之战留给了那些在没有这种需求的情况下寻求一切最佳性能并因此浪费时间的人。