多线程

Question

我目前正在开发的应用程序执行一些I/O或CPU密集型操作(文件压缩、文件传输、与第三方API通信等)。当用户按下“发送”按钮时发生的。

目前，我正试图说服我的雇主，我们应该将这些操作推开到主应用程序中的不同线程中(在任何特定时间，我们最多需要两个工作线程)，但我的同事声称：

在低优先级线程上执行的任何额外处理都可能影响GUI的可用性。

我的观点是，将I/O或CPU密集型活动推到工作线程，在进度报告期间使用Invoke调用更新UI，这是处理密集型活动的非常标准的做法。

我错了吗？如果是的话，有人能给出解释吗？

编辑：

到目前为止谢谢你的回答。

我要澄清的是:该同事的非阻塞解决方案是生成一个包含计时器循环的子进程，该进程扫描文件夹并处理文件压缩/传输活动。(请注意，这并不包括对第三方API的调用--我不知道他的解决方案是什么。

这种方法的主要问题是，主应用程序失去了对任何活动状态的所有范围。导致IMHO进一步复杂化(他的进度报告解决方案是在两个进程中公开Windows消息泵，并在两个进程之间发送自定义消息)。

Answer 1

你是对的。后台线程正是通过调用操作保持UI活动的本质，正如您所描述的那样。将所有内容保持在GUI线程上，最终会阻塞用户界面，使GUI无法响应。

Answer 2

最终的答案是将其作为概念的证明来实现，然后对应用程序进行分析，看看可能存在或不存在什么样的潜在性能冲击。也许在一个

话虽如此，但对我来说，这听起来就像垃圾。事实上，情况正好相反--使用额外的线程通常是保持UI响应性的最佳方法。

特别是像任务并行库这样的东西，基本的多线程并不难。

Answer 3

是的，你是对的。一般原则是，负责响应用户并保持用户界面更新的线程(通常称为UI线程)不应用于执行任何冗长的操作。

根据经验，任何花费超过30 is的东西都是从UI线程中移除的候选对象。这有点咄咄逼人--30毫秒是大多数人认为不是瞬间的最短间隔，实际上比电影屏幕上显示的连续帧之间的间隔要小一些。