Question

当调整第三方库以公开IObservable时，有时候您必须使用类似ReplaySubject之类的内容来在您意识到流可用之后的短时间内缓冲结果，这是不可避免的。在你可以让别人订阅它之前。

短时间段的ReplaySubject通常会“正常”工作，但并非总是如此，然后是浪费，维持滚动队列，一旦订阅者正在收听，这可能是不必要的。

是否有一个“受试者的建议模式，直到有人在听？”

Answer 1

我不确定我是否正确理解了这个问题。但根据您的上一句subject which buffers until someone is listening，您可以执行以下扩展方法

之类的操作

static IObservable<T> BufferUntillSubscribe<T>(this IObservable<T> obs)
{
    var replay = new ReplaySubject<T>();
    var disposable = obs.Subscribe(replay);
    return Observable.CreateWithDisposable<T>((subscriber) =>
    {
        disposable.Dispose();
        return replay.Merge(obs).Subscribe(subscriber);
    });
}

Answer 2

答案似乎是“不”。你可以自己编写一个相对较少的麻烦，虽然它看起来很像ReplaySubject，只是一个完全在订阅后丢弃其队列的。从碎片构建一个充满了竞争条件。

当我编写一个公开IObservable<TConnection> TConnection IObservable<TMessage>有成员TConnection的API时，问题出现了。观察新TMessage的人需要确保他们不会错过该连接上的任何IObservable<TMessage>。基础事件来源略显尴尬。我要求，如果观察者不想错过任何消息，那么他在之前订阅OnNext(TConnection) 对.ObserveOn(Scheduler.TaskPool)的调用完成。这几乎总是某人想要做的事情，他们只需要确保他们不会为IObservable<TConnection>做Subject之类的愚蠢行为。如果程序员同意这样做，那么实际上根本不需要缓冲（在这个特定的实现中），并且常规{{1}}将会起作用。

是否有一个Reactive Framework Subject缓冲，直到它不需要？

2 个答案: