在基于 UI 的应用程序中使用 await Task.Run(() => someMethodAsync()) 与 await someMethodAsync()

Question

我通过这个例子阅读了这个article：

class MyService
{
  /// <summary>
  /// This method is CPU-bound!
  /// </summary>
  public async Task<int> PredictStockMarketAsync()
  {
    // Do some I/O first.
    await Task.Delay(1000);

    // Tons of work to do in here!
    for (int i = 0; i != 10000000; ++i)
      ;

    // Possibly some more I/O here.
    await Task.Delay(1000);

    // More work.
    for (int i = 0; i != 10000000; ++i)
      ;

    return 42;
  }
}

然后描述如何根据您使用的是基于 UI 的应用程序还是 ASP.NET 应用程序来调用它：

//UI based app:
private async void MyButton_Click(object sender, EventArgs e)
{
  await Task.Run(() => myService.PredictStockMarketAsync());
}

//ASP.NET:
public class StockMarketController: Controller
{
  public async Task<ActionResult> IndexAsync()
  {
    var result = await myService.PredictStockMarketAsync();
    return View(result);
  }
}

为什么需要在基于 UI 的应用中使用Task.Run() 来执行PredictStockMarketAsync()？

在基于 UI 的应用程序中使用 await myService.PredictStockMarketAsync(); 不会也不会阻塞 UI 线程吗？

Answer 1

默认情况下，当您await 操作不完整时，会捕获同步上下文（如果存在）。然后，当异步工作完成重新激活时，捕获的同步上下文用于编组工作。很多场景没有sync-context，但是winforms和WPF之类的UI应用do，而sync-context代表UI线程（基本上：这是为了让默认行为变成“my代码有效”而不是“在我的 async 方法中与 UI 对话时出现跨线程异常”）。本质上，这意味着当您从 UI 线程await Task.Delay(1000) 时，它会暂停 1000 毫秒（释放 UI 线程），然后在 UI 线程上恢复。这意味着您“在这里要做的大量工作”发生在 UI 线程上，并阻塞了它。

通常，解决此问题的方法很简单：添加 .ConfigureAwait(false)，它会禁用同步上下文捕获：

await Task.Delay(1000).ConfigureAwait(false);

（通常：在该方法中的 all await 之后添加这个）

请注意，只有当您知道自己不需要同步上下文提供的功能时，才应该这样做。特别是：您不会在之后尝试触摸 UI。如果您确实需要与 UI 对话，则必须明确使用 UI 调度程序。

当您使用Task.Run(...) 时，您通过不同 路由转义了同步上下文 - 即未在 UI 线程上启动（同步上下文通过活动线程指定）。