RxJava-何时以及为何使用Observable.share() [英] RxJava - When and why to use Observable.share()

问题描述

我看过这样的模式:

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()不是所有可观察对象的默认行为?

Why is not share() the default behavior for all observables?

即使上面的代码即使没有 .share()也能正常工作，这将是很好的选择.我不必考虑何时需要共享一个Observable，何时不共享.

It would be nice if the code above worked the same even without .share(). I would not have to think about when I need to share an Observable, and when I don't.

是否出于性能原因，因为只有一个订户是一种可以更有效地处理的特殊情况?

Is it for performance reasons because having a single subscriber is a special case that can be handled more efficiently?

从文档中我不清楚:

share()返回一个新的ObservableSource，它多播(共享)原始的ObservableSource.只要至少有一个ObservableSource，该ObservableSource就会被订阅并发出数据.

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 有两种:冷和热.冷 Observable 在有 Observer 的情况下开始生产物品，并且它们是逐个进行的.订阅多个 Observer 将导致多次运行相同的 Observable .例如，发出网络请求的 Observable .

There are two kinds of Observables: cold and hot. Cold Observables start producing items when there is an Observer to them and they do it on an individual basis. Subscribing with multiple Observers will result in multiple runs of the same cold Observable. An example of this is an Observable that issues a network request.

相反，热 可观察可以生成有或没有 Observer 的项目.这些 Observable 通常会将相同的项目多播到其当前所有 Observer .例如，按钮点击的 Observable .

In contrast, a hot Observable can produce items with or without the presence of Observers. These Observables usually multicast the same items to all of their current Observers. An example of this is an Observable of button clicks.

要将冷的 Observable 变成热门的，可以使用 publish()，这将确保仅对源 Observable建立一个订阅不管有多少 Observer .因此，从 Observer s的角度来看，该链现在将充当热多播 Observable .

To turn a cold Observable into a hot one, you can use publish() which will make sure only a single subscription is established to the source Observable no matter how many Observers there are. Thus, the chain will now act as a hot multicasting Observable from the Observers' perspective.

但是，在所有 publish()的 Observer 都消失之后，通常保持冷的 Observable 运行通常是不经济的，因此， refCount()运算符可用于跟踪它们并在没有有趣的参与者时停止源.

However, often it is not economic to keep an originally cold Observable running after all Observers of publish() have gone away, therefore the refCount() operator can be used to keep track of them and stop the source when there are no interesting parties left.

如果源已经很热，则不需要 share().

If your source is already hot, you don't need share().

为什么share()不是所有可观察对象的默认行为?

Why is not share() the default behavior for all observables?

实际上，此属性是现代反应式编程范例的重要贡献之一:热和冷的 Observable s的区别.

Actually, this property is one of the important contributions of the modern reactive programming paradigm: the distinction of the hot and cold Observables.

但是，多播本身就很昂贵，因为您必须跟踪当前的 Observer 集合，以便用新事件通知它们，这可能导致各种逻辑竞争条件被捍卫.众所周知，冷的 Observable 仅与单个 Observer 通话，因此不需要额外的跟踪开销.

However, multicasting is expensive on itself because you have to keep track of the set of current Observers in order to notify them with new events, and this can lead to all sorts of logical race conditions to be defended against. A cold Observable is known to talk only to a single Observer so there is no need for the extra tracking overhead.

这篇关于RxJava-何时以及为何使用Observable.share()的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！