Timer与DispatcherTimer的性能

Question

我没有特定的场景，但是当我想到可能想要在DispatcherTimer上使用Timer的场景时，这个问题就在我脑海中浮现。

在我必须执行计算密集型任务的情况下，每当计时器事件触发，然后对UI进行次要修改时，在性能方面会更好：

1. 使用常规Timer，然后使用应用程序的Dispatcher 更改用户界面
2. 使用DispatcherTimer（并且可能在我的计算上做 如有必要，可以在某些异步后台工作人员中进行密集工作。

我的猜测是尽可能长时间地保持UI线程畅通无阻将增强用户体验。如果 是可取的，那么在这种情况下我是否应该注意哪些捕获？

修改

我觉得我的问题不够明确，所以我将尝试添加一个具体的，虽然是一个简单的例子。

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

Answer 1

要点：

  

执行计算密集型任务

这表明不使用DispatcherTimer。它主要用于在主线程上执行小任务，避免创建另一个线程。

如果您使用DispatcherTimer启动Backgroundworker，则会绕过其主要目的。

所以这里只需使用常规计时器。

Answer 2

经过一些研究和分析后，我得出结论，常规计时器在我的例子中效果最好。到目前为止，我没有必要留意任何可能导致我的代码中潜在问题的特定内容。话虽如此，良好的编码实践从未受到伤害！

Answer 3

• 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上。使用与Timer相反的DispatcherTimer的原因是DispatcherTimer在与Dispatcher相同的线程上运行，并且可以设置DispatcherPriority。

Answer 4

Comparing Timer with DispatcherTimer 这里发布的一些答案更具体地针对您的问题，但我认为此链接提供了一些一般信息和建议。

Answer 5

如果要更改绑定到UI元素的标量（不是集合）值，则不仅可以从UI线程（例如来自Timer委托）执行此操作。在这种情况下，您不需要使用Dispatcher.Invoke / BeginInvoke。

Answer 6

另一种选择是使用DispatcherTimer在每次定时器迭代时创建BackgroundWorker类实例。在许多情况下，它还可以使您免于使用Dispatcher.Invoke / BeginInvoke。