Rxjs主体性能-太多个是不是太多了？将几个组合成一个会更好吗？

Question

我的问题的要点是：假设你有一个服务处理2-3-4-10个操作，而为了在多个组件之间通信，你有2-3-4-10个主题。

那么，是更好地只有一个主题，在下一个对象中传递标识哪个操作与其相关，并在订阅内部进行筛选...或者将它们全部订阅并分别订阅?

有太多的主题会有什么问题吗？它们大多数时候都是同时活动的。

我感兴趣的是尽可能抽象地了解情况，而不是了解我的用例以及是否可以更好地完成。

- Vlad Pintea

---

在我看来，只要它们有良好的目的，拥有多个主题并没有什么问题。为了减少数量而混合它们的业务逻辑是不可取的。一个主题也是可观察的，当你使用操作符时，你就有了一个可观察对象+一个订阅者，当整个流被订阅时。 - Andrei Gătej

这基本上也是我的想法，但我真的很好奇是否有人在大型项目中使用它们时会觉得它们太多了。可能我不知道。我的审核者可能不是rxjs的铁杆粉丝，他可能会提出性能问题并建议重写，如果有实际数据来支持，我想为其辩护：））这比以两种方式编写并尝试进行比较要容易。 - Vlad Pintea

我怀疑使用过多的 Subject 不会导致性能下降。我非常熟悉源代码，甚至可以说，一长串操作符的消耗比一个 Subject 实例多（但不显著）。 - Andrei Gătej

Answer 1

我负责开发大型Angular应用程序，其中涉及成百上千的subjects（Subject、BehaviorSubject、ReplaySubject、AsyncSubject）。

使用许多subjects会有性能影响吗？

对此，我想说的是，它们只占用内存空间，其次，重要的是你附加到它们上面的管道，将其放入CPU的计算队列中。这取决于管道本身，而不是subjects。如果你连接到一个长时间的计算重型管道，则可能会使你的程序变慢，因为JavaScript运行在单个执行线程上（可以使用Web Workers解决此问题）。

因此，如果我们谈论应用程序的“性能”，那么subjects的数量在这里是不相关的。关键在于管道是否能够确定你的应用程序是否缓慢。例如，数据沿着管道移动，并由操作符操作。

StackBlitz 单管道实例，以证明我的观点。

是不是更好的方式是只使用1个subject，在next方法中传递一个标识其所属操作的对象，然后在订阅时进行过滤？

我认为这更多是一种设计决策，可以使用信息总线（“单个subject”）将所有数据传递，而不是将它们分解成各自的流。如果你的数据相互关联，意味着你的事件彼此依存，并且它们出现在流中的顺序很重要（如导航事件：开始，执行，结束等），那么这种方式可能非常方便。

但是，如果开发人员使用一个巨大的容器来放置所有数据，而不是将其分解为各自的流，则我会感到不满意。例如，如果我有一个用户对象、公司信息和通知，则我希望它们具有关注点分离，并且不通过总线系统（单个subject）进行传递，而是通过不同的服务进行传递，这些服务具有各自的subjects和管道。

有太多的subjects是什么情况？它们几乎都同时保持活动状态。

blockquote>

如果你只是做简单的映射和过滤，那么就不用担心你使用了多少个subjects。相反，要关注数据流是否具有逻辑/后勤意义，并且它们是否被正确结构化/隔离。

StackBlitz程序结合了100万个BehaviorSubject，以证明我的观点。

- Kevin Baker