2012年(366)
分类: 系统运维
2012-03-27 18:25:59
Dispatcher提供用于管理线程工作项队列的服务。可以理解为消息队列,只是其中保存的是委托,而不是简单的windows消息。Dispatcher通常用来使我们的程序界面对于用户的操作响应更加迅速,通常用来更新UI,例如一个进度条。例如一个耗时操作,我们不想让使用者等得太着急,于是我们想显示一个进度条。
最直接的方法可能是在一个循环中更新,如以下这个错误的代码:
然而直到循环结束,我们的界面都得不到更新,处于停止响应状态。我们利用Dispatcher成功的解决了这个问题:
参考WPF的线程模型知道,WPF使用呈现(render)线程隐藏在后台负责应用程序的呈现,也就是界面的更新;而UI线程负责管理UI,上面的代码就运行在UI线程中,何谓管理UI,我的理解是可以改变UI元素的属性,例如ProgressBar的Value值,也就是可以操作UI元素的意思。遗憾的是我们的UI线程不能通过代码直接调用呈现线程让其更新界面。
我们该怎么理解以上的代码呢?Dispatcher.Invoke的作用是将一个委托消息加入到消息队列中,这个消息队列中的消息是有优先级的,优先级是由DispatcherPriority这个枚举确定的。同时Invoke是一个同步调用,因此是否也是通知Render线程开始刷新我们的界面呢?我们的while其实是在等待Render线程执行完毕后,才继续执行,这令我们想到了线程的同步机制。而代码1的情况,因为没有给Render线程任何通知,也就难怪不刷新了。由此得到的结论就是:Render线程何时开始工作其实是基于消息队列中的特殊消息的,例如我们的Dispatacher.Invoke产生的消息(肯定不是所有的消息,因为你动一下鼠标,界面不会刷新)。DispatcherPriority.Background指示我们的消息的优先级低于Normal,这样我们的UI线程就能停下来,让Render线程的消息优先得到执行。那照你这么说,与我们Dispatcher中排队的是什么样的委托没有关系了?只是起到一个UI线程暂停,同时通知Render线程工作的目的?是的,下面的代码能够到达同样的效果:
我们排队了一个空委托,照样能唤醒Render线程。
我觉得这样的理解已经足够,没有必要请出Windbg,继续深挖下去(其实,那不是我所擅长的领域:))。这个推测足以帮助我们改进代码,怎么,需要改进吗?如果我们的推测正确的话,那么,以上代码虽然使我们的用户界面得到了及时的刷新,但同时也降低了性能。原因很简单:频繁的线程切换。UI线程和Render线程在频繁的切换,以换取界面的及时刷新。short.MaxValue其实只有32767,做一个3万多次的循环加1,却用了20多秒!你不觉得惊讶吗? 改进方法也很简单:减少Dispatcher.Invoke的调用,降低线程切换频率。如下代码只需要352毫秒:
这是多少倍的性能提升啊!同时也证明了我们的推测是正确的!看来,有时遇到不理解的问题,编写测试代码来验证一下是一个不错的选择。