c# - 响应式扩展、锁和线程

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 的性能很重要，您可以考虑创建一个专用的线程+调度程序，并为 throttle /示例使用自定义 DistpatcherScheduler。或者，可能有更好的 TPL 方法来解决它。