c# - 多线程

Question

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

我目前正试图说服我的雇主，我们应该将这些操作推送到主应用程序中的单独线程（在任何给定时间，我们最多需要两个工作线程处于活动状态），但我的同事声称：

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

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

我不正确吗？如果是这样，有人可以提供解释吗？

编辑：

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

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

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

Answer 1

你是对的。正如您所描述的，后台线程是通过调用操作保持 UI 活动的本质。将所有内容都保留在 GUI 线程上，最终会堵塞管道并使 GUI 无响应。

Answer 2

最终的答案是将其作为概念验证来实施，然后分析应用程序以查看可能存在或不存在哪种潜在的性能影响。也许在一个

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

尤其是像任务并行库这样的东西，基本的多线程并不是很困难。

Answer 3

是的，你是对的。一般原则是，负责响应用户并保持用户界面最新的线程（通常称为 UI 线程）永远不应该用于执行任何冗长的操作。
根据经验，任何可能需要超过 30 毫秒的时间都可以从 UI 线程中删除。这有点激进——30ms 大约是大多数人认为不是瞬时的最短间隔，实际上它比电影屏幕上显示的连续帧之间的间隔略短。