Async/Await 和 Dispatcher 的区别

Question

我正在开发一个 WPF 应用程序，但遇到了冻结问题，现在我了解到它是一个单线程应用程序，但我对术语感到困惑

我简单的术语

Async/Await 和 Dispatcher 的区别

我想解释一下我的观点，这样就清楚我的误解，直到现在我才知道大多数应用程序都是 STA（在 c# 中），你必须使用异步编程，这很可能涉及

• 通过优先处理已经完成的工作，然后使用工作线程通知 UI 线程繁重的工作已完成，将工作转移到 UI 线程上的单个线程
• 也是一个真正的多线程应用程序，其中需要创建一个线程来完成其上的任务

我认为在大多数情况下，我的概念至少是可靠的，至少可以说我缺乏的是应用这些能力

例如，我虽然以前为了启用异步编程，我们不得不使用从主方法调用的委托，这演变成委托的调度员切割，进一步演变成异步并等待切割“任何单一使用的”调度员（甚至那个文字关键词）

所以我在函数声明中使用的只是“async”词，然后是“task”，然后通过粘贴“await”词等待一些紧张的过程，然后它最终用 Task.Run(() = 封装紧张的工作> IntenseWork())

但现在我很困惑你必须使用 Dispatcher 这个词，因为 UI 元素只能由 dispatcher 访问，并且使用 Dispatcher.Invoke(IntenseWork())，然后有 Dispatcher.Begininvoke 和 Dispatcher.AsyncIncoke

怀疑：

在这种情况下 async/await 和 task.run 是不够的，甚至在这里使用任务并行库

---

我提出问题并研究并坚持这些结论，这些是我以前的问题

异步导航

在示例问题中使用 async 和 await 实现异步

Answer 1

您正在询问来自不同时期的两种不同技术。

常见的问题是 UI 是单线程的，只能从主 (UI) 线程访问。

您可以并且应该尽可能地将非 UI 工作卸载到另一个线程。 但是通常有结果需要在之后显示。

旧的（但仍然有效）方法是将委托交给 WinForms 中的 Dispatcher.Invoke() 或 Control.Invoke()。

适用于 Task.Run() 和所有 DoSomethingAsync() I/O 方法的较新方法是使用 await：

// use async void only for eventhandlers
async void LoadButton_Click(object s, RouteEventArgs e)
{
   // get input from controls here
   var results = await Task.Run(() => HeavyWorkWithoutUI());
   // update UI with results here
}

WPPF 和 WinForms 支持是您的顶级方法将在等待之前和之后在 UI 线程上运行。 重方法将在另一个线程上运行。 在等待期间，您的 UI 保持响应。

所以 await 更方便一点，让你用更少的努力编写更易读的代码。