我确信响应式UI是每个人都在努力的事情，推荐的做事方式是为此使用BackgroundWorker。

我们觉得使用起来容易吗？你经常使用吗？还是我们有自己的框架来处理冗长的任务和报告流程。

我发现我经常使用它，甚至在需要某种进度报告的地方都使用它的委托。

解决方案

回答

我经常将其用于进度指示和后台数据加载\处理等任务。
最近，我发现了开箱即用不支持的用例。这是"可覆盖的任务"。但是Patric Smacchia提出了很好的解决方案。

回答

BackgroundWorker使事情变得容易得多。我发现困难的一件事是Backgroundworker本身具有线程亲和力，即使它应该隐藏线程切换问题。它不会在每种情况下自动切换到UI线程。需要创建它并从UI线程运行该线程，以正确进行线程切换。

回答

我曾经使用过它，并且对此感到非常满意。通常，不需要"大型"多线程，而仅需要2个线程(UI和Worker)，它的工作原理非常好，而不必过多地担心基础线程逻辑。

回答

一开始很难掌握多线程编程(而且退伍军人有时仍会失败)，而BackgroundWorker使其更易于使用。我喜欢BackgroundWorker具有易于实现的功能，但是更容易以微妙的方式(例如取消)错误地实现该功能。
如果需要更新进度条，可以使用它，这样我就可以显示有意义的进度条。

如果不是，我使用一个Thread(或者从ThreadPool借用)，因为我不需要BackgroundWorker的所有功能，并且对线程足够精通以启动Thread并等待其停止。

对于不相关任务的委托，我使用Thread类的委托，例如普通的void ThreadStart()，或者创建自己的委托。

回答

@Gulzar谢谢我们提供此信息：需要创建它并从UI线程运行它才能正确进行线程切换。

使用我发现的后台工作者时要注意的一件事是异常处理。

如果在异步进程上引发异常，则不会向主线程引发异常，该进程将完成，并且将触发BackgroundWorker RunWorkerCompleted事件，并将错误隐藏在RunWorkerCompletedEventArgs.Error中。

我喜欢BackgroundWorker具有易于实现但更容易以微妙的方式(例如取消)错误地实现的功能。

回答

我与后台工作人员类的最大问题是，实际上没有办法知道由于取消而导致工作人员何时结束。 BackgroundWorker不会公开它使用的线程，因此我们不能使用标准技术来同步线程终止(连接等)。我们也不能只在UI线程上循环等待它结束，因为RunWorkerCompleted事件将永远不会触发。我一直必须使用的技巧是简单地设置一个标志，然后启动一个计时器，该计时器将继续检查后台工作程序是否结束。但这非常混乱，并使业务逻辑复杂化。

因此，只要我们不需要支持确定性取消，它就很棒。