我见过这样的模式:
Observable<String> nameChanges = nameDataSource.changes().share();
// One subscriber
autoUnsubscribe(nameChanges.subscribe(() -> { ... }));
// Another subscriber
autoUnsubscribe(nameChanges.map(...).filter(...).subscribe(...));
// autoUnsubscribe is called when the UI is torn down
我的问题是:
为什么每当我想在多个地方监听 Observable 时都需要调用 share()？
为什么 share() 不是所有可观察对象的默认行为？
如果上面的代码在没有 .share() 的情况下也能正常工作，那就太好了。我不必考虑何时需要共享 Observable，何时不需要。
是否出于性能原因，因为拥有单个订阅者是一种可以更有效地处理的特殊情况？
从文档中我不清楚这一点:
share() returns a new ObservableSource that multicasts (shares) the original ObservableSource. As long there is at least one Observer this ObservableSource will be subscribed and emitting data.
最佳答案
有两种Observable:冷的和热的。 Cold Observable 会在有 Observer 时开始生成项目，并且它们会单独进行。订阅多个 Observer 将导致多次运行相同的冷 Observable。这方面的一个例子是发出网络请求的 Observable。
相比之下，hot Observable 可以在存在或不存在Observer 的情况下生成项目。这些 Observable 通常将相同的项目多播到它们当前的所有 Observer。这方面的一个例子是按钮点击的 Observable。
要将冷 Observable 变成热的，您可以使用 publish() 这将确保只对源 Observable 建立一个订阅 无论有多少个Observer。因此，从 Observer 的角度来看，该链现在将充当热多播 Observable。
然而，在 publish() 的所有 Observer 都消失后，让一个原本冷的 Observable 继续运行通常是不经济的，因此 refCount() 运算符可用于跟踪它们并在没有有趣的参与方时停止源。
如果您的源已经很热，则不需要share()。
Why is not share() the default behavior for all observables?
实际上，这个属性是现代响应式(Reactive)编程范式的重要贡献之一:冷热Observable的区分。
但是，多播本身就很昂贵，因为您必须跟踪当前的 Observer 集合，以便用新事件通知它们，这可能导致各种逻辑竞争条件被防御。众所周知，冷 Observable 仅与单个 Observer 对话，因此不需要额外的跟踪开销。
关于android - RxJava - 何时以及为何使用 Observable.share()，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48460553/