BackgroundWorker与后台线程我有一个关于我应该在Windows窗体应用程序上使用的后台线程实现的选择的风格问题。目前我BackgroundWorker在一个具有无限(while(true))循环的表单上。在这个循环中,我WaitHandle.WaitAny用来保持线程打盹直到感兴趣的事情发生。我等待的一个事件句柄是一个“ StopThread”事件,这样我就可以摆脱循环。来自我被覆盖的事件会发出此事件的信号Form.Dispose()。我读到的某个地方BackgroundWorker真的是用于那些你不想将UI绑定到并且具有有限结束的操作 - 比如下载文件或处理一系列项目。在这种情况下,“结束”是未知的,并且仅在窗口关闭时。因此,使用后台线程而不是BackgroundWorker为此目的更合适吗?
3 回答
慕运维8079593
TA贡献1876条经验 获得超5个赞
根据我对您的问题的理解,您使用的BackgroundWorker
是标准线程。
为什么原因BackgroundWorker
建议的事情,你不想占用UI线程是因为它做赢形式的发展时,暴露了一些不错的活动。
事件喜欢RunWorkerCompleted
在线程完成它需要做的事情时发出信号,以及ProgressChanged
在线程进度上更新GUI 的事件。
因此,如果您没有使用这些,我认为使用标准线程不会对您需要做什么造成任何伤害。
紫衣仙女
TA贡献1839条经验 获得超15个赞
几乎是马特戴维斯所说的,还有以下几点:
对我来说,主要区别BackgroundWorker
在于通过自动编组已完成的事件SynchronizationContext
。在UI上下文中,这意味着已完成的事件在UI线程上触发,因此可用于更新UI。如果您BackgroundWorker
在UI上下文中使用,这是一个主要的区别。
通过它执行的任务ThreadPool
不能轻易取消(包括ThreadPool
。QueueUserWorkItem
和委托执行异步)。因此,虽然它避免了线程旋转的开销,但是如果你需要取消使用BackgroundWorker
或者(更可能在UI之外)启动一个线程并保持对它的引用,这样你就可以调用Abort()
。
- 3 回答
- 0 关注
- 785 浏览
添加回答
举报
0/150
提交
取消