我确信响应式 UI 是每个人都在努力的目标，推荐的方法是为此使用 BackgroundWorker。
你觉得工作容易吗？你经常用吗？或者您是否有自己的框架来处理冗长的任务和报告流程。
我发现我经常使用它，甚至在我需要某种进度报告的地方使用它的代表。
Tomas Pajonk
问问题
775 次
6 回答
3
BackgroundWorker 让事情变得容易多了。我发现困难的一件事是 Backgroundworker 本身具有线程亲和力，即使它应该隐藏线程切换问题。它不会在每种情况下都自动切换到 UI 线程。它需要从 UI 线程创建和运行，才能正确进行线程切换。
于 2008-09-08T14:31:08.357 回答
3
多线程编程一开始很难掌握（老手有时还是会失败），BackgroundWorker 使它更容易使用。我喜欢 BackgroundWorker 具有易于实现的功能，但更容易以微妙的方式错误地实现，例如取消。如果我有并且需要进度更新，我会使用它，这样我就可以显示一个有意义的进度条。
如果没有，我使用 Thread（或从 ThreadPool 借用），因为我不需要 BackgroundWorker 的所有功能，并且对线程足够熟练，可以启动 Thread 并等待它停止。
至于不相关任务的委托，我使用 Thread 类的委托，例如 plain void ThreadStart()，或者我自己创建。
于 2008-09-08T14:42:21.513 回答
1
我经常将它用于进度指示和后台数据加载\处理等任务。
最近我发现了不支持开箱即用的用例。这是“可覆盖的任务”。然而 Patric Smacchia 想出了很好的解决方案。
于 2008-09-08T14:31:08.230 回答
1
我用过一次，很满意。通常，不需要“大”多线程，而只需要 2 个线程（UI 和 Worker），而且它工作得非常好，而不必过多担心底层的线程逻辑。
于 2008-09-08T14:34:32.543 回答
0
@Gulzar 感谢您提供这条信息：需要从 UI 线程创建和运行它才能正确进行线程切换。
使用我发现的后台工作程序时要注意的一件事是异常处理。
如果在异步进程上抛出异常，它不会向主线程抛出异常，进程将完成并且 BackgroundWorker RunWorkerCompleted 事件将触发，错误隐藏在 RunWorkerCompletedEventArgs.Error 中。
我喜欢 BackgroundWorker 具有易于实现的功能，但更容易以微妙的方式错误地实现，例如取消。
于 2008-09-08T15:06:27.243 回答
-1
我对后台工人阶级的最大问题是，由于取消，工人真的无法知道何时完成。BackgroundWorker 不公开它使用的线程，因此您不能使用标准技术来同步线程终止（连接等）。您也不能只是在 UI 线程上循环等待它结束，因为 RunWorkerCompleted 事件永远不会触发。我一直不得不使用的技巧是简单地设置一个标志，然后启动一个计时器，该计时器将继续检查后台工作人员是否结束。但它非常混乱并且使业务逻辑复杂化。
因此，只要您不需要支持确定性取消，它就很棒。
于 2008-09-17T14:50:54.927 回答