时间戳

首页 > 解决方案 > Xamarin 使用 async./wait VS await Task.Run（在 Xamarin 中）

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

问题描述

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

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

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

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

标签： multithreadingxamarinasync-await

解决方案

“异步/等待”是否总是在与 UI 不同的线程上运行？

没有。

根据我的研究，建议将“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.RunCPU 绑定操作。每隔一段时间，该规则就有一个例外。例如，有时 I/O 绑定操作是阻塞的，并且它们不提供完全异步的 API；await Task.Run在这种情况下，即使操作在技术上受 I/O 限制而不是 CPU 限制，也可以正确使用阻止后台线程而不是 UI 线程。

进一步阅读：

推荐阅读