反应式扩展、锁和线程

Question

我正在使用响应式扩展来处理 wpf ui，基本上我有一个文本框，我需要在小时间跨度（200-300毫秒）

问题在于它有些不可预测，有时会立即触发油门，这可能是因为 TextUpdated 事件没有到达可观察对象或可观察对象本身。我也在做一些可能会干扰的锁定，但这通常是通过新任务完成的，而不是在 UI 线程上。我还偷偷怀疑调试可能会影响行为，因为当我设置断点时它似乎更“不正确”地触发了

由于 observable 是在 UI 线程上创建的，我假设（可能是错误的）它是计时器或它在下面使用的任何东西也在该线程上，创建一个新线程来创建 observable 可能是个好主意，这样它就不会受到干扰通过 UI 开销和潜在的锁定？我如何以最好的方式设置这样一个线程，我猜它末尾的空while循环可能不是一个好主意:)

Throttle、Sample 工作以及与线程相关的响应式扩展如何在后台工作？

编辑

似乎问题出在我测试它的方式上：P 如果你按住一个键，它开始重复之前似乎有 500 毫秒的延迟，如果你只是敲击键它工作正常。叹息

Answer 1

Sample 和 Throttle 都使用 Scheduler.ThreadPool 作为他们的时间，所以我很怀疑这是问题所在。

我建议在代码中添加一些日志记录以找出瓶颈所在：

sourceEvents.LogInterval("Source")
    .Throttle(throttleTimeSpan).LogInterval("Throttled")
    .Sample(sampleTimeSpan).LogInterval("Sample")
    .Subscribe();

这里是LogInterval的定义：

public static class ObservableEx
{
    public static IObservable<TSource> LogInterval(
        this IObservable<TSource> source, string message)
    {
        return source
            .TimeInterval()
            .Do(x => Debug.WriteLine("{0} :: {1} ({2})", 
                message, x.Value, x.Interval.TotalMilliseconds);
            .RemoveTimeInteval();
    }
}

如果瓶颈是节流阀/样本，则可能意味着您在其他地方使线程池饱和。如果是这种情况，并且这些节流阀的性能很重要，您可以考虑创建一个专用线程+调度程序并为 Throttle/Sample 使用自定义 DistpatcherScheduler。或者，可能有更好的 TPL 方法来解决它。