爲什麼我們在這種情況下需要Publish和RefCount Rx操作符？

Question

我試圖用的反應背壓處理這一問題，以自己熟悉，特別是通過閱讀這篇維基：https://github.com/ReactiveX/RxJava/wiki/Backpressure

In the buffer paragraph，我們有這個更復雜的示例代碼：

// we have to multicast the original bursty Observable so we can use it 
// both as our source and as the source for our buffer closing selector: 
Observable<Integer> burstyMulticast = bursty.publish().refCount(); 
// burstyDebounced will be our buffer closing selector: 
Observable<Integer> burstyDebounced = burstMulticast.debounce(10, TimeUnit.MILLISECONDS); 
// and this, finally, is the Observable of buffers we're interested in: 
Observable<List<Integer>> burstyBuffered = burstyMulticast.buffer(burstyDebounced); 

如果我理解正確的話，我們通過爲緩衝區運算符生成一個去抖動信號流，有效地消除了突發源碼流。

但是，爲什麼我們需要在這裏使用發佈和refcount運算符？如果我們放棄它們會導致什麼問題？這些評論對我來說並不是很清楚，RxJava Observables是不是默認多播？

Answer 1

答案在於hot and cold觀察值之間的差異。

緩衝區操作符組合了2個流，無法知道它們有共同的源（在你的情況下）。激活（訂閱）後，它將訂閱它們，作爲回報，它將觸發2個不同的訂閱到您的原始輸入。

現在有兩件事情可能發生，要麼輸入是熱的可觀察的，並且訂閱沒有效果，只能註冊偵聽器，並且一切都按預期工作，或者它是冷的可觀察的，並且每個訂閱都會導致潛在的獨特和不同步的流。

例如，冷觀察者可以是訂閱時執行網絡請求並通知結果的人。不調用它的發佈意味着2個請求將完成。

Publish + refcount/connect是將冷觀察變爲熱點的常用方法，確保單個訂閱將會發生，並且所有的流將表現相同。