我没有想到具体的场景，但是当我在考虑我可能想要使用 Timer 而不是 DispatcherTimer 的场景时，这个问题突然闪过我的脑海。
在每次触发计时器事件时我必须执行计算密集型任务，然后对 UI 进行微小修改的场景中，在性能方面是否会更好：
我的猜测是，尽可能长时间地保持 UI 线程畅通会增强用户体验。如果这是可取的，在这种情况下我应该注意什么问题吗？
编辑：
我觉得我的问题不够清楚，所以我将尝试添加一个具体的，尽管是虚构的示例。
假设我必须每 2 分钟读取一次大文件，完成后，我必须向 ListBox 添加一个项目。假设读取/处理文件需要 10-15 秒，在此期间我不做任何 UI 工作。对于这样的事情，最好的方法是什么？
【问题讨论】：
标签： c# wpf silverlight dispatchertimer
要点：
执行计算密集型任务
这将表明 不 使用 DispatcherTimer。它的存在主要是为了在主线程上执行小任务，避免创建另一个线程。
如果您使用 DispatcherTimer 来启动 Backgroundworker，那么您就绕过了它的主要用途。
因此，只需在此处使用常规计时器即可。
【讨论】：
经过更多研究和分析，我得出结论，在我虚构的示例中，常规计时器的效果最好。到目前为止，我不必寻找任何会导致我的代码中潜在问题的具体内容。话虽如此，良好的编码实践永远不会受到伤害！
【讨论】：
计时器在应用程序中生成重复事件
DispatcherTimer 是集成到 Dispatcher 中的计时器 在指定的时间间隔内处理的队列 指定的优先级。
不保证定时器在时间间隔发生时准确执行，但保证在时间间隔发生之前不执行。这是因为 DispatcherTimer 操作像其他操作一样放置在 Dispatcher 队列中。当 DispatcherTimer 操作执行时，它依赖于队列中的其他作业及其优先级。
如果在WPF application 中使用了Timer，则值得注意的是Timer runs on a different thread then the user interface (UI) thread。为了访问用户界面 (UI) 线程上的对象，有必要使用 Invoke 或 BeginInvoke 将操作发布到用户界面 (UI) 线程的 Dispatcher。使用 DispatcherTimer 而不是 Timer 的原因是 DispatcherTimer 与 Dispatcher 在同一线程上运行，并且可以设置 DispatcherPriority。
【讨论】：
Comparing Timer with DispatcherTimer 此处发布的一些答案更针对您的问题，但我认为此链接提供了一些一般信息和建议。
【讨论】：
如果您想更改绑定到 UI 元素的标量（不是集合）值，您不仅可以从 UI 线程（例如，从 Timer 委托）执行此操作。在这种情况下，您不需要使用 Dispatcher.Invoke/BeginInvoke。
【讨论】：
另一种选择是使用 DispatcherTimer 在每次计时器迭代时创建 BackgroundWorker 类实例。在许多情况下，它还使您免于使用 Dispatcher.Invoke/BeginInvoke。
【讨论】：