定时器与DispatcherTimer的性能

本文关键字：性能 DispatcherTimer 定时器 | 更新日期: 2023-09-27 18:16:41

我没有一个特定的场景在脑海中，但这个问题只是闪过我的脑海，而我正在考虑的场景，我可能想要使用一个定时器在DispatcherTimer

每当计时器事件触发时，我必须执行计算密集型任务，然后对UI进行轻微的修改，在性能方面是否会更好:

  1. 使用一个常规的Timer，然后使用应用程序的Dispatcher修改UI
  2. 使用DispatcherTimer(并可能执行我的计算)

我的猜测是，保持UI线程不阻塞尽可能长时间将增强用户体验。如果是可取的，那么在这种情况下，我应该注意什么问题吗?

编辑:

我感觉我的问题不够清楚，所以我将尝试添加一个具体的，尽管是虚构的例子。

假设我必须每2分钟读取一个大文件，当我完成后，我必须向ListBox添加一个项目。假设读取/处理文件需要10-15秒，在此期间我不做任何UI工作。对于这样的事情，最好的方法是什么?

定时器与DispatcherTimer的性能

主旨:

执行计算密集型任务

这将表明没有使用DispatcherTimer 。它的存在主要是为了在主线程上执行小任务，避免创建另一个线程。

如果你使用DispatcherTimer来启动一个Backgroundworker，你就绕过了它的主要目的。

在这里使用一个普通的Timer。

经过更多的研究和分析，我得出结论，在我所创建的示例中，常规计时器效果最好。到目前为止，我还没有注意到任何可能在我的代码中导致潜在问题的特定内容。话虽如此，良好的编码实践从来没有坏处!

  • Timer在应用程序中生成循环事件

  • DispatcherTimer是一个集成在Dispatcher中的定时器队列，该队列在指定的时间间隔内以a指定优先级。

定时器不保证正好在时间间隔发生时执行，但保证不会在时间间隔发生之前执行。这是因为DispatcherTimer操作像其他操作一样放在Dispatcher队列上。当DispatcherTimer操作执行时，它依赖于队列中的其他作业及其优先级。

如果在WPF application中使用定时器，则值得注意的是Timer runs on a different thread then the user interface (UI) thread。为了访问用户界面(UI)线程上的对象，有必要使用Invoke或BeginInvoke将操作发布到用户界面(UI)线程的Dispatcher上。使用DispatcherTimer而不是Timer的原因是DispatcherTimer与Dispatcher运行在同一个线程上，并且DispatcherPriority可以被设置。

比较Timer和DispatcherTimer这里张贴的一些答案是更具体的问题，但我认为这个链接提供了一些一般的信息和建议。

如果你想改变一个标量(不是集合)值绑定到UI元素，你可以做到这一点，不仅从UI线程(例如从定时器委托)。在这种情况下，你不需要使用Dispatcher.Invoke/BeginInvoke.

另一个选择是使用DispatcherTimer在每次计时器迭代时创建BackgroundWorker类实例。它还使您不必使用Dispatcher。在很多情况下调用/BeginInvoke

相关文章：