.net - 确保在 WPF 中的 UI 线程上运行

Question

我正在构建一个 WPF 应用程序。我正在与服务器端进行一些异步通信，并在客户端上使用 Prism 的事件聚合。这两件事都会导致生成新线程，而这些线程不是 UI 线程。如果我尝试在这些回调和事件处理程序线程上执行“WPF 操作”，那么世界将分崩离析，现在它已经开始这样做了。

首先，我在尝试从服务器的回调中创建一些 WPF 对象时遇到了问题。有人告诉我该线程需要在 STA 模式下运行。现在我正在尝试更新 Prism 事件处理程序中的一些 UI 数据，有人告诉我:

The caller cannot access this thread because a different thread owns it.

所以; 在 WPF 中正确处理事情的关键是什么？ 我在 this MSDN post 中阅读了 WPF Dispatcher .我开始明白了，但我还不是巫师。

当我需要运行一些我不确定会在 UI 线程上调用的东西时，总是使用 Dispatcher.Invoke 的关键是什么？

如果它实际上是在 UI 线程上调用的，那么我还是执行 Dispatcher.Invoke 有关系吗？

Dispatcher.Invoke = 同步。 Dispathcher.BeginInvoke = 异步？

Dispatcher.Invoke 会不会请求 UI 线程，然后停下来等待呢？这是不良做法和响应较慢的程序的风险吗？

无论如何，我如何获得调度员？ Dispatcher.CurrentDispatcher 是否总是给我代表 UI 线程的调度程序？

是否会存在多个 Dispatcher，或者“Dispatcher”是否与应用程序的 UI 线程基本相同？

与 BackgroundWorker 有什么关系？我什么时候改用这个？我认为这总是异步的？

在 UI 线程上运行的所有内容(通过被调用)都将在 STA 单元模式下运行吗？ IE。如果我有一些需要在 STA 模式下运行的东西 - Dispatcher.Invoke 是否足够？

有人想为我澄清事情吗？有没有相关的推荐等？谢谢!

Answer 1

逐一检查您的每个问题:

不完全的;您应该只在必要时调用 UI 线程。见#2。

是的，这很重要。你不应该只是自动 Invoke一切。关键是仅在必要时调用 UI 线程。为此，您可以使用 Dispatcher.CheckAccess方法。

那是正确的。

也是正确的，是的，您确实存在响应速度较慢的程序的风险。大多数情况下，您不会看到严重的性能下降(我们谈论的是上下文切换的毫秒数)，但您应该只看到 Invoke如有必要。话虽如此，在某些时候这是不可避免的，所以不，我根本不会说这是不好的做法。它只是您时不时遇到的问题的一种解决方案。

在我见过的每一个案例中，我都与 Dispatcher.CurrentDispatcher 交了款。 .对于复杂的场景，这可能还不够，但我(个人)还没有看到它们。

不完全正确，但这种思路不会造成任何伤害。让我这样说:Dispatcher可用于访问应用程序的 UI 线程。但它本身并不是 UI 线程。

BackgroundWorker通常在您有一个耗时的操作并希望在后台运行该操作时保持响应式 UI 时使用。通常，您不使用 BackgroundWorker 而不是 Invoke，而是将 BackgroundWorker 与 Invoke 结合使用。也就是说，如果您需要更新您的 BackgroundWorker 中的某个 UI 对象，您可以在 UI 线程上调用，执行更新，然后返回到原始操作。

是的。根据定义，WPF 应用程序的 UI 线程必须在单线程单元中运行。

关于 BackgroundWorker有很多话要说，我相信很多问题已经专门针对它了，所以我不会太深入。如果您好奇，请查看 MSDN page for BackgroundWorker class .