如何解决Xamarin 使用 async./wait VS await Task.Run在 Xamarin 中
我一直在研究 async/await 与 await Task.Run 但没有找到明确的结论。
-
“async/await”是否总是在与 UI 不同的线程上运行？如果是，为什么要使用“await Task.Run”？
-
根据我的研究，建议对 cpu 密集型任务使用“await Task.Run”，对数据传输场景 (I/O) 使用“await/async”，但其他人建议使用 await Task.Run (如果需要返回）或只是 Task.Run（即发即忘），用于在 Xamarin 中运行任何更长时间的活动。
与 async/await 相比，“await Task.Run”的最佳用途是什么，尤其是在 Xamarin 的上下文中？
解决方法
“async/await”是否总是在与 UI 不同的线程上运行？
No。
根据我的研究，建议对 CPU 密集型任务使用“await Task.Run”，对数据传输场景 (I/O) 使用“await/async”
这是 UI 应用程序的一个很好的一般准则。普通的 async/await 不使用额外的线程；它只是让你的 UI 保持响应。如果您有受 CPU 限制的代码，那么您确实需要另一个线程，因此您可以使用 Task.Run，并且您可以使用 await 来使用它，这使您的 UI 在后台保持响应线程运行受 CPU 限制的代码。
但其他人建议在 Xamarin 中使用 await Task.Run（如果需要返回）或仅使用 Task.Run（即发即弃）来处理任何长时间运行的活动。
我不建议一劳永逸。除其他问题外，它还可以隐藏异常。我建议始终使用 await。
与 async/await 相比，“await Task.Run”的最佳用途是什么，尤其是在 Xamarin 的上下文中？
上述一般规则是有效的：对 I/O 操作使用 async/await，对 CPU 密集型操作使用 Task.Run。每隔一段时间，这条规则就会有一个例外。例如，有时 I/O 绑定操作是阻塞，并且它们不提供完全异步的 API；在这种情况下，即使操作在技术上受 I/O 限制而不是 CPU 限制，也可以正确使用 await Task.Run 来阻止后台线程而不是 UI 线程。
进一步阅读：
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
