9

我没有想到一个特定的场景，但是当我在考虑我可能想要在 DispatcherTimer 上使用 Timer 的场景时，这个问题刚刚闪过我的脑海。

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

  1. 使用常规 Timer，然后使用应用程序的 Dispatcher 更改 UI
  2. 使用 DispatcherTimer（如有必要，可能在一些异步后台工作人员中进行我的计算密集型工作）。

我的猜测是，尽可能长时间地保持 UI 线程畅通会增强用户体验。如果这是可取的，在这种情况下是否有任何我应该注意的问题？

编辑：

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

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

4

6 回答 6

5

要点：

执行计算密集型任务

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

如果您使用 DispatcherTimer 来启动 Backgroundworker，那么您就绕过了它的主要目的。

因此，只需在此处使用常规 Timer。

于 2011-12-04T10:37:27.327 回答
2

经过更多的研究和分析，我得出的结论是，在我虚构的示例中，常规计时器效果最好。到目前为止，我不必寻找任何会导致代码中潜在问题的具体内容。话虽如此，良好的编码实践永远不会受到伤害！

于 2012-02-12T07:18:53.797 回答
1

  • 计时器在应用程序中生成重复事件

  • DispatcherTimer 是一个集成到 Dispatcher 队列中的定时器，该队列以指定的时间间隔和指定的优先级进行处理。

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

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

于 2011-12-04T09:39:26.037 回答
1

比较 Timer 与 DispatcherTimer 此处发布的一些答案更具体针对您的问题，但我认为此链接提供了一些一般信息和建议。

于 2013-01-09T18:33:45.527 回答
0

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

于 2011-12-04T09:57:44.947 回答
0

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

于 2011-12-04T10:11:47.223 回答