为什么在 Blazor wasm 中使用await Task.Delay(1)？

Question

许多 SO 答案用于await Task.Delay(1)解决 Blazor (wasm) 中的各种异步渲染问题。我什至在我自己的代码中发现了许多地方这样做“使它起作用”。

然而，它总是按事实陈述，没有彻底的解释，而且我在文档中也找不到这种技术。

一些问题：

• 为什么使用await Task.Delay(1)- 我什么时候使用这种技术，用例是什么？
• 文档没有讨论这个（我可以找到）；是因为它是黑客攻击，还是处理用例的合法方法？
• Task.Delay(1)和之间有什么区别吗Task.Yield()？

Answer 1

为什么使用await Task.Delay(1) - 我什么时候会使用这种技术，用例是什么？

它使 UI 有机会在代码中间更新和重绘。

文档没有讨论这个（我可以找到）；是因为它是黑客攻击，还是处理用例的合法方法？

这是一个黑客行为。但在 Blazor/WASM 的特定情况下（没有其他 Blazor 或 .NET 运行时），没有很多其他选择。如果可能的话，我建议拆分你的逻辑，这样你的应用程序就不会同时做这么多事情；但有时这是不可能的（或容易的）。

Task.Delay(1) 和 Task.Yield() 之间有什么区别吗？

是的，具体取决于浏览器详细信息。

在 Windows UI 应用程序上，Task.Yield这不起作用，因为 UI 消息循环是一个优先级队列，并且“运行此代码”具有最高优先级。因此（同样，对于 Windows UI 应用程序），这会将方法的其余部分排队，然后返回到消息循环，然后消息循环将继续执行代码，而不是刷新 UI（这是优先级较低的消息）。

对于 Blazor/WASM，是否Task.Yield有效取决于其（隐式）消息循环的浏览器实现。如果它有一个类似的优先级队列，那么您最终会遇到与 Windows UI 相同的问题，其中Task.Yield确实屈服于消息循环但不会耗尽它。

在所有平台上，Task.Delay(1)实际上都会对计时器回调进行排队，这通常足以在代码继续运行之前处理一些 UI 更新。