我一直在研究async/await和await任务。跑了，但还没有找到明确的结论。
-
做"async/await"总是运行在一个单独的线程从UI?如果是，为什么要使用await task . run ?
-
根据我的研究，建议使用"await Task.Run"对于CPU密集型任务和await/async"用于数据传输场景(I/O)，但其他人建议使用await Task。运行(如果需要返回)或直接运行Task。在Xamarin中运行任何长时间运行的活动
那么await Task.Run"的最佳用途是什么呢?特别是在Xamarin的上下文中，与async/await相比?
是否" async/await ";总是运行在一个单独的线程从UI?
号
根据我的研究，建议使用"await Task.Run"对于CPU密集型任务和await/async"用于数据传输场景(I/O)
这是UI应用程序的一个很好的通用指导原则。普通async/await不使用额外的线程;它只是让你的UI保持响应。如果你有cpu绑定的代码，那么你做需要另一个线程，所以你使用Task.Run，你可以使用await它保持你的UI响应而后台线程运行cpu绑定的代码。
，但其他人建议使用await Task。运行(如果需要返回)或直接运行Task。在Xamarin中运行任何长时间运行的活动
我不推荐立即走人。在其他问题中，它可以隐藏异常。我建议始终使用await。
那么await task . run的最佳用途是什么呢?特别是在Xamarin的上下文中，与async/await相比?
上面的一般规则是有效的:I/O操作使用async/await, cpu绑定操作使用Task.Run。每隔一段时间就会有例外。例如，有时I/o绑定操作会阻塞，并且它们不提供完全异步的API;在这种情况下，使用await Task.Run来阻塞后台线程而不是UI线程是正确的，即使该操作在技术上是I/o限制而不是cpu限制。
进一步阅读:
async最佳实践Task.Run礼仪- 异步MVVM数据绑定