通过实例理解WPF的Dispatcher

Dispatcher提供用于管理线程工作项队列的服务。可以理解为消息队列，只是其中保存的是委托，而不是简单的windows消息。Dispatcher通常用来使我们的程序界面对于用户的操作响应更加迅速，通常用来更新UI，例如一个进度条。例如一个耗时操作，我们不想让使用者等得太着急，于是我们想显示一个进度条。

最直接的方法可能是在一个循环中更新，如以下这个错误的代码：

ProgressBar1.Minimum = 0; 
 ProgressBar1.Maximum = short.MaxValue; //模拟一个耗时计算
 ProgressBar1.Value = 0; 
 while (ProgressBar1.Value < ProgressBar1.Maximum) 
 { 
 this.ProgressBar1.Value += 1; 
 }

然而直到循环结束，我们的界面都得不到更新，处于停止响应状态。我们利用Dispatcher成功的解决了这个问题： 

ProgressBar1.Minimum = 0; 
 ProgressBar1.Maximum = short.MaxValue; 
 ProgressBar1.Value = 0; 
 while (ProgressBar1.Value < ProgressBar1.Maximum) 
 { 
 Dispatcher.Invoke(new Action(() =>
 { 
 this.ProgressBar1.Value += 1; 
 }),System.Windows.Threading.DispatcherPriority.Background); 
 }

参考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线程工作的目的？是的，下面的代码能够到达同样的效果：

ProgressBar1.Minimum = 0; 
 ProgressBar1.Maximum = short.MaxValue; 
 ProgressBar1.Value = 0; 
 while (ProgressBar1.Value < ProgressBar1.Maximum) 
 { 
 this.ProgressBar1.Value += 1; 
 Dispatcher.Invoke(new Action(() =>
 { 
　　　　　　　　　}),System.Windows.Threading.DispatcherPriority.Background); 
 }

我们排队了一个空委托，照样能唤醒Render线程。

我觉得这样的理解已经足够，没有必要请出Windbg，继续深挖下去（其实，那不是我所擅长的领域：））。这个推测足以帮助我们改进代码，怎么，需要改进吗？如果我们的推测正确的话，那么，以上代码虽然使我们的用户界面得到了及时的刷新，但同时也降低了性能。原因很简单：频繁的线程切换。UI线程和Render线程在频繁的切换，以换取界面的及时刷新。short.MaxValue其实只有32767，做一个3万多次的循环加1，却用了20多秒！你不觉得惊讶吗? 改进方法也很简单：减少Dispatcher.Invoke的调用，降低线程切换频率。如下代码只需要352毫秒：

ProgressBar1.Minimum = 0; 
 ProgressBar1.Maximum = short.MaxValue ; 
 ProgressBar1.Value = 0; 
 double m = short.MaxValue / ProgressBar1.ActualWidth; 
 int n = 0; 
 while (ProgressBar1.Value < ProgressBar1.Maximum) 
 { 
 this.ProgressBar1.Value += 1; 
 n += 1; 
 if (n >= m) 
 { 
 Dispatcher.Invoke(new Action(() =>
 { 
 }), System.Windows.Threading.DispatcherPriority.Background); 
 n = 0; 
 } 
　　　　　　　}

这是多少倍的性能提升啊！同时也证明了我们的推测是正确的！看来，有时遇到不理解的问题，编写测试代码来验证一下是一个不错的选择。