Xamarin 使用 async./wait VS await Task.Run（在 Xamarin 中）

Question

我一直在研究 async/await 与 await Task.Run 但没有找到明确的结论。

1. “async/await”是否总是在与 UI 不同的线程上运行？如果是，为什么要使用“await Task.Run”？

2. 根据我的研究，建议将“await Task.Run”用于 CPU 密集型任务，将“await/async”用于数据传输场景 (I/O)，但其他人建议使用 await Task.Run（如果需要返回）或只是 Task.Run（即发即弃），用于 Xamarin 中任何更长时间运行的活动。

那么，与仅 async/await 相比，“await Task.Run”的最佳用途是什么，尤其是在 Xamarin 的上下文中？

Answer 1

“async/await”是否总是在与 UI 不同的线程上运行？

No.

根据我的研究，建议将“await Task.Run”用于 CPU 密集型任务，将“await/async”用于数据传输场景 (I/O)

这是 UI 应用程序的一个很好的通用指南。普通的async/await 不使用额外的线程；它只是让你的 UI 保持响应。如果您有 CPU 绑定代码，那么您确实需要另一个线程，因此您可以使用 Task.Run，并且您可以使用 await 来使用它，这可以让您的 UI 在后台线程运行 CPU 时保持响应-绑定代码。

但其他人建议在 Xamarin 中使用 await Task.Run（如果需要返回）或只使用 Task.Run（即发即弃）来进行任何更长时间运行的活动。

我不建议一劳永逸。除其他问题外，它还可以隐藏异常。我建议始终使用await。

那么，与仅 async/await 相比，“await Task.Run”的最佳用途是什么，尤其是在 Xamarin 的上下文中？

上面的一般规则是有效的：使用async/await 用于I/O 操作，Task.Run 用于CPU 绑定操作。每隔一段时间，该规则就有一个例外。例如，有时 I/O 绑定操作是阻塞，并且它们不提供完全异步的 API；在这种情况下，最好使用await Task.Run 来阻止后台线程而不是 UI 线程，即使该操作在技术上受 I/O 限制而不是 CPU 限制。

进一步阅读：

• async best practices
• Task.Run etiquette
• Asynchronous MVVM data binding