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;
}
}
这是多少倍的性能提升啊！同时也证明了我们的推测是正确的！看来，有时遇到不理解的问题，编写测试代码来验证一下是一个不错的选择。
------------------------2010-3-28更新---------------------------------------------
以上代码为什么不使用BeginInvoke？
Invoke和BeginInvoke一个是同步调用，一个是异步调用。如果在While中进行异步调用，由于不等调用完成就循环下一次了，循环结束条件始终得不到满足，造成死循环了。如果非要BeginInvoke的话：
ProgressBar1.Minimum = 0;
ProgressBar1.Maximum = short.MaxValue;
ProgressBar1.Value = 0;
while (ProgressBar1.Value < ProgressBar1.Maximum)
{
Dispatcher.BeginInvoke(new Action(() =>
{
this.ProgressBar1.Value += 1;
}), System.Windows.Threading.DispatcherPriority.Background).Wait();
}
这样又变成了一个同步，没有得到性能的提升。
使用一个新的线程：
我惊奇的发现以下代码，使用一个新的Thread。不但不需要设置队列的优先级为Background，而且运行时间大大缩短，只需要2秒多：
ProgressBar1.Minimum = 0;
ProgressBar1.Maximum = short.MaxValue;
ProgressBar1.Value = 0;
double value = ProgressBar1.Value;
double max = ProgressBar1.Maximum;
new Thread(() =>
{
while (value < max)
{
value += 1;
Dispatcher.Invoke(new Action(() =>
{
this.ProgressBar1.Value = value;
}));
}
}).Start();
看来我们代码2的20多秒，不光浪费在线程切换上。至于更深层次的原因留到以后遇到了再说吧！