c# - C# silverlight 中的 DispatcherTimer 和 UI 刷新限制

Question

我再次为一个对你们所有人来说可能很简单的问题表示歉意。我对 Silverlight 幕后的工作了解有限。

我有一个图表应用程序 (Visiblox)，我将其用作每 20 毫秒更新一次的滚动范围，添加和删除一个点。在伪代码中:

List<Point> datapoints= new List<Point>();
Series series = new Series(datapoints);
void timer_tick(){
  datapoints.Add(new Point);
  datapoints.RemoveAt(0);
  // no need to refresh chart, it does refresh automatically
}

在这个图表工具中运行 6 系列时，它开始表现得有点迟钝。将刻度更改为 10 毫秒没有任何区别，图表以相同的速度更新，因此 20 毫秒似乎是速度限制(UI 或图表？)。

我尝试使用 CompositionTarget.Rendering 并得到了相同的结果:低于 20 毫秒时速度没有差异。

然后我不小心启用了两者并且速度加倍。所以我用多线程(2、3、4)进行了测试，速度翻了一番、三倍和四倍。这还没有锁，因为我什至不知道我需要在哪个进程上生成锁，但没有数据损坏或内存泄漏。

我的问题是，为什么 20 毫秒的缓慢图表不能以 10 毫秒的速度运行，但在多线程时却快得离谱？ UI 刷新过程是否运行得更快？图表计算是否加倍？或者单个 DispatcherTimer 的执行速度有限制吗？

谢谢!

---

编辑:我有嵌入式编码的背景，所以当我想到线程和时序时，我立即想到在硬件中切换一个引脚并连接一个示波器来测量过程长度。我是 C# 中线程的新手，没有连接作用域的引脚。有没有办法以图形方式查看线程计时？

Answer 1

在 UI 线程上触发其 Tick 事件的 DispatcherTimer 被认为是低分辨率或低精度计时器，因为它的 Interval 实际上意味着“自上次滴答开始后不早于 x 滴答”。如果 UI 线程忙于做任何(处理输入、刷新图表等)，那么它将延迟计时器的事件。此外，如果 DispatcherTimer 在 UI 线程上以非常短的时间间隔计时，也会降低应用程序的响应速度，因为在引发 Tick 事件时，应用程序无法响应输入。

因此，正如您所指出的，为了频繁处理数据，您应该转移到后台线程。但有一些警告。您目前没有观察到损坏或其他错误的事实可能纯属巧合。如果在后台线程上修改列表，同时前台线程试图从中读取列表，您最终会崩溃(如果幸运的话)或看到损坏的数据。

在您的示例中，您有一条评论说“无需刷新图表，它会自动刷新”。这让我想知道图表如何知道您已经更改了 datapoints收藏？ List<T>修改时不会引发事件。如果您使用的是 ObservableCollection<T>我要指出的是，每次您删除/添加一个点时，您可能会刷新图表，这可能会减慢速度。

但如果您实际上使用的是 List<T>那么一定有其他东西(也许是另一个计时器？)正在刷新图表。也许图表控件本身具有内置的自动刷新机制？

无论如何，这个问题有点棘手but not completely new .您可以通过多种方式在后台线程上维护集合并从 UI 线程绑定(bind)到它。但是您的 UI 刷新得越快，您等待后台线程释放锁的可能性就越大。

最小化这种情况的一种方法是使用 LinkedList<T>而不是 List<T> .添加到 LinkedList 的末尾是 O(1)，删除项目也是如此。 List<T>当您从头开始删除项目时，需要将所有内容向下移动一个。通过使用 LinkedList，您可以在后台线程中锁定它，并且可以最大限度地减少持有锁的时间。在 UI 线程上，您还需要获得相同的锁并在持有锁时将列表复制到数组或刷新图表。

另一种可能的解决方案是在后台线程上缓冲“ block ”点，然后使用 Dispatcher.BeginInvoke 将一批点发布到 UI 线程，然后您可以在其中安全地更新集合。