c# - 盲目地使用 InvokeRequired 不是一种不好的做法吗？

Question

我是一名新手程序员，所以我在这里可能完全错了，但这个问题比它应该的更让我烦恼。

这实际上是 this 的跟进问题。

公认的答案是，您必须调用 InvokeRequired 以避免一些开销，因为您有可能已经在 UI 线程上操作。

理论上，我同意它可以节省一些时间。经过一些测试，我发现使用 Invoke 比正常调用操作花费大约两倍的时间(测试如设置标签文本 n 次，或在 RichTextBox 中放置一个非常非常大的字符串)。

但是!然后就是练习。

MSDN 文档说:

This property can be used to determine if you must call an invoke method, which can be useful if you do not know what thread owns a control.

在大多数情况下，当您尝试从另一个线程访问控件时，您确实知道。实际上我能想到的唯一情况是，当从线程 X 以及所有者线程可以调用的方法访问控件时。对我来说，这是一种非常不可能的情况。

即使您真的不知道哪个线程试图操纵该控件，但 UI 线程也不必如此频繁地更新这一事实。 25-30 fps 之间的任何值都适合您的 GUI。大多数在 UI 控件中进行的更改执行所需的时间远少于毫秒。

因此，如果我理解正确的话，您必须检查是否需要调用的唯一情况是您不知道哪个线程正在访问控件以及 GUI 更新需要超过 40 毫秒才能完成。

然后就是this的答案了我在 http://programmers.stackexchange.com 上问的问题.其中指出，当您不需要时，您不应该忙于过早的优化。特别是如果它牺牲了代码的可读性。

所以这让我想到了我的问题:当您知道不同的线程访问控件时，您不应该只使用 invoke 吗？仅当您知道您的 UI 线程可以访问那段代码时 < strong>并且您发现它应该运行得更快，您应该检查是否需要调用？

PS:在校对了我的问题之后，听起来我真的在咆哮。但实际上我只是很好奇为什么 InvokeRequired 似乎被许多比我更有经验的程序员过度使用。

Answer 1

你在这里断章取义了。第一个问题you linked链接了另一个问题，该问题专门关于编写线程安全方法来访问 UI 控件。

如果您不需要对 UI 控件的线程安全访问，因为您知道您不会从另一个线程更新它，那么您当然不应该使用这种技术。无需使用 InvokeRequired 或 Invoke 即可简单地更新您的 UI 控件。

另一方面，如果调用将总是源自 UI 线程以外的线程，只需使用 Invoke 而无需首先检查 InvokeRequired.

这引出了三个简单的规则:

1. 如果您仅从 UI 线程更新控件，则既不使用 InvokeRequired 也不使用 Invoke
2. 如果您仅从 UI 线程以外的线程更新控件，请仅使用 Invoke。
3. 如果您同时从 UI 线程和其他线程更新控件，请结合使用 Invoke 和 InvokeRequired。