在用户界面线程上等待的危险性-Toy模板网

这篇具有很好参考价值的文章主要介绍了在用户界面线程上等待的危险性。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

我们做这么一个假设哈。

如果有一个线程，它拥有一个窗口，则在这个线程的整个运行过程中，我们都不应该调用 Sleep 函数。为什么？

因为 Sleep 调用会导致线程在睡眠等待期停止处理窗口消息。即使对于持续时间较短的睡眠也是如此，例如睡眠几秒钟和醒来以轮询系统中某些内容的状态。

如我之前在另一篇文章中所提到的，轮询会降低系统性能，还会损害系统在低功耗情况下节省能源的能力，并受到终端服务器的放大效应的影响。

如果当前处理器处于空闲状态，那就继续保持闲着。如果处理器很忙，那就赶紧让它完成计算任务，然后重新回到空闲状态。

但有时候我还是会看到如下的代码：

>> 请移步至 topomel.com 以查看图片 <<

请注意，此消息循环长达两秒钟而不处理消息。人们通常不会将两秒钟的睡眠插入负责与最终用户交互的线程中，但他们经常为后台工作线程执行此操作，这些线程为跨线程通信目的创建了隐藏窗口。由于线程没有可见的 UI，因此将最终用户一次挂起几秒钟是不会有明显的感知的。

但是，存在某些特殊情况。

如果系统需要广播消息，则必须等待此休眠线程最终唤醒并处理广播消息。同时，发出广播的组件继续等待。例如，用户可能双击了需要 DDE 才能打开的文档。DDE 过程从广播 WM_DDE_INITIATE 消息开始，该消息停滞在窗口后面。你的无响应隐藏窗口刚刚创建了一个 “Windows 似乎以随机间隔挂起几秒钟” 错误。

请注意，许多人忽略了调用 CoInitialize（可能间接）来初始化 STA 的线程会创建一个隐藏窗口以执行列集。因此，在单线程单元中运行的线程必须不停地处理消息。如果不这样做，由于窗口无响应，将导致神秘的系统级卡顿。