BackgroundWorker和线程
使用这两者来实现特定任务的利弊是什么。
百万美元的问题是哪一个使用什么时候？
非常感谢。
我用它来关联BackgroundWorker作为Threads会做什么的包装器。 所以我在GUI工作中使用BackgroundWorker，在更专业或更脏的工作上使用Threads（Windows服务等）
如果你通过“Threads”明确地使用System.Threading.Thread类来创建，配置和启动你自己的线程，那么答案就是这样做对你来说更多的工作，涉及更多的cpu周期而不仅仅是拉线程来自线程池，（这是其他技术所做的），但它为您提供了更大的灵活性，因为它允许您指定线程优先级，以及使用线程池线程无法承受的其他几个特性。
当在设计时不知道所需的线程数时，“线程池”方法更合适。 该池最初包含少量线程，“准备好”供您调用。 它可以根据需要动态创建新线程，并为您管理未使用线程的创建，协调和删除。 您可以使用三种机制来访问和使用池中的线程。
- 使用Delegate.BeginInvoke（）（最常用的技术）
- 使用计时器（几种变体）
- System.Threading.ThreadPool提供了其他几个function（BackGroundWorker类，QueueUserWorkItem（）等）。
看看这个伟大的线程概述 ：
[BackgroundWorker]提供以下function：
一个“取消”标志，用于在不使用Abort的情况下发信号通知工人结束
报告进度，完成和取消的标准协议
IComponent的一个实现，允许它位于工作线程上的Visual Studio Designerexception处理中
能够更新Windows窗体和WPF控件以响应工作进度或完成。
最后两个特性特别有用 – 它意味着您不必在您的worker方法中包含try / catch块，并且可以更新Windows窗体和WPF控件而无需调用Control.Invoke。
只有当您不必使用UI（WinForms或WPF）和后台工作程序时才需要处理UI。
您可以避免UI和后台工作程序的许多问题。
BackgroundWorker类是一种向Form添加线程以在不阻止UI的情况下执行某些繁重操作的简单方法。 您可以使用线程执行相同操作，但编码稍微多一些。
BackgroundWorker类只是为您提供切换到UI线程上下文的事件，但不要混淆; DoWork事件（实际上，你工作的地方）仍然在另一个线程的上下文中执行（因为这是整个事情的重点）并且执行任何类型的UI交互或更新将会抛出exception最好的，最糟糕的是崩溃。 当您尝试执行需要UI更新且范围不超出表单范围的内容时，应在表单上使用BackgroundWorker。 对于其他后台操作，请考虑使用ThreadPool（用于短期操作）或创建自己的Thread。
BackgroundWorker为ProgressChanged事件提供了便利，但是不要太舒服并开始在DoWork中进行UI更新。