Dispacher(1/2)深入解析-详细使用

WPF 中的 Dispatcher 类深入解析

上文我们介绍了UI线程的相关概念.本篇介绍UI线程的核心Dispatcher

[为什么需要 Dispatcher：WPF 的线程模型](#为什么需要 Dispatcher：WPF 的线程模型 "#1-%E4%B8%BA%E4%BB%80%E4%B9%88%E9%9C%80%E8%A6%81-dispatcherwpf-%E7%9A%84%E7%BA%BF%E7%A8%8B%E6%A8%A1%E5%9E%8B")
[Dispatcher 是什么](#Dispatcher 是什么 "#2-dispatcher-%E6%98%AF%E4%BB%80%E4%B9%88")
[Dispatcher 的核心功能](#Dispatcher 的核心功能 "#3-dispatcher-%E7%9A%84%E6%A0%B8%E5%BF%83%E5%8A%9F%E8%83%BD")

1. 为什么需要 Dispatcher：WPF 的线程模型

WPF 沿用了 Win32 GUI 的传统线程模型------UI 线程的"线程亲和性"（Thread Affinity） 。这一模型的核心思想是：一个 UI 元素只能由创建它的那个线程来操作，其他线程无权直接访问它。这个约束并非 WPF 独有，而是从 Win32、WinForms 一路继承下来的设计传统，其根本原因在于 GUI 框架的线程安全设计策略,以前文章我们也列举了这样设计的UI框架,包括现在的Andriod和IOS都是一样的设计。

在 Win32 时代，窗口消息（WM_*）本身就是线程绑定的------每个窗口属于创建它的线程，消息队列也归该线程所有。WPF 在此基础上进一步强化了这一模型：不仅窗口和消息是线程绑定的，所有继承自 DependencyObject 的类型都带有线程亲和性。这意味着：

绝大多数 DependencyObject（包括所有 Visual、UIElement、Control 等可显示元素）只能由创建该对象的线程操作；
创建 UI 元素的那个线程，就是所谓的 UI 线程；
如果后台线程直接访问 UI 控件（改 TextBlock.Text、操作 Canvas 等），WPF 会抛出 InvalidOperationException------"The calling thread cannot access this object because a different thread owns it." 这个异常信息我们前面提到过,也展示过. 这个异常信息非常直白："调用线程无法访问此对象，因为另一个线程拥有它"。它清楚地告诉我们，WPF 在运行时就会主动拦截跨线程的非法访问，而不是等到出现难以排查的诡异行为时才暴露问题。这种"尽早失败"（fail-fast）的设计，虽然让初学者感到困扰，但从工程角度看反而是一种保护------它把线程安全问题暴露在第一时间，而不是让竞态条件在运行时悄悄滋生。
绝大多数 DependencyObject（包括所有 Visual、UIElement、Control 等可显示元素）只能由创建该对象的线程操作；
创建 UI 元素的那个线程，就是所谓的 UI 线程；
如果后台线程直接访问 UI 控件（改 TextBlock.Text、操作 Canvas 等），WPF 会抛出 InvalidOperationException------"The calling thread cannot access this object because a different thread owns it."

例如下面的代码必然抛异常：

csharp 复制代码

private void Button_Click(object sender, RoutedEventArgs e)
{
    Task.Run(() =>
    {
        // 后台线程直接触碰 UI ------ 抛 InvalidOperationException
        this.textBox.Text = "来自后台线程";
    });
}

之所以有这样的限制，是因为 UI 元素不是线程安全的，而且它们的渲染、布局、输入处理都要在 UI 线程上串行完成。跨线程更新 UI 的"标准姿势"是：把工作放到后台线程，把"更新 UI 的委托"封送（marshal）回 UI 线程 。这个封送动作的执行者，就是 Dispatcher。

2. Dispatcher 是什么

Dispatcher（System.Windows.Threading.Dispatcher）是一个与单个线程强关联（thread-affine）的调度服务。它负责：

维护一个按优先级排序的操作队列 （队列元素是待执行的委托 / DispatcherOperation）；
提供消息循环（帧循环），把 Windows 消息队列和自身的操作队列融合在一起处理；
提供 Invoke / BeginInvoke 等 API，让任何线程都能把委托"投递"到拥有该 Dispatcher 的线程上执行。

关键性质：

性质	说明
每个线程至多一个	Dispatcher 存于线程本地存储（Thread-Local Storage）。线程第一次访问 `Dispatcher.CurrentDispatcher` 时惰性创建
线程是"主人"	只有创建它的线程（通常就是 UI 线程）能运行它、执行它的队列里的操作
生命周期	随线程一起存在，`Dispatcher.Run()` 启动消息循环，`Dispatcher.Shutdown()` 结束
WPF 全局默认	`Application` 启动时，UI 线程上会自动创建并运行一个 Dispatcher

获取当前线程的 Dispatcher：

csharp 复制代码

Dispatcher uiDispatcher = Dispatcher.CurrentDispatcher; // 当前线程
Dispatcher uiDispatcher2 = Application.Current.Dispatcher; // 主 UI 线程
Dispatcher uiDispatcher3 = this.Dispatcher;              // 任意 DispatcherObject

本质上，UI 线程 ≈ 拥有并运行 Dispatcher 的线程。说"切回 UI 线程执行"，就是"把委托投递给 UI 线程的 Dispatcher 执行"。

3. Dispatcher 的核心功能

3.1 跨线程封送：Invoke / BeginInvoke / InvokeAsync

这是 Dispatcher 最常用的功能------把一段代码从任意线程安全地"搬到" UI 线程上执行。

csharp 复制代码

// 同步：阻塞调用线程，直到委托在 UI 线程执行完毕
Dispatcher.Invoke(() => { txtStatus.Text = "完成"; });

// 异步：立即返回 DispatcherOperation，不阻塞调用线程
Dispatcher.BeginInvoke(() => { txtStatus.Text = "完成"; });

// 现代写法：返回 Task，可 await
await Dispatcher.InvokeAsync(() => { txtStatus.Text = "完成"; });

典型用法 ------ 后台线程计算结果后回传 UI：

csharp 复制代码

private async void StartButton_Click(object sender, RoutedEventArgs e)
{
    var dispatcher = Dispatcher; // 记住 UI 线程的 Dispatcher

    var result = await Task.Run(() => LongRunningComputation());

    // 这里其实已经被 DispatcherSynchronizationContext 自动送回 UI 线程（见 3.6）
    resultText.Text = result.ToString();

    // 假如你从"任何线程"出发，则显式封送：
    // await dispatcher.InvokeAsync(() => resultText.Text = result.ToString());
}

DispatcherOperation 表示一个已排队的操作，可以拿到它的 Result、Status，也可以调用 .Abort() 尝试取消尚未执行的操作；
DispatcherOperation 实现了 Task 兼容接口（DispatcherOperation<T>.Task），因此能与 async/await 无缝配合；
用 DispatcherPriority 参数可以指定这个操作以何种优先级入队（见 3.2）。

3.2 优先级调度：DispatcherPriority

与 WinForms 那种"先进先出"的消息队列不同，Dispatcher 的队列是按优先级排序的 。DispatcherPriority 枚举（从高到低）：

优先级	值	含义
`Send`	10	最高，立即同步执行（等同于同步调用，一般不排队）
`Normal`	9	正常优先级，默认值
`DataBind`	8	数据绑定相关操作
`Render`	7	渲染（布局、绘图）
`Loaded`	6	元素加载完成
`Input`	5	输入事件（鼠标、键盘）
`ContextIdle`	4	上下文空闲后
`ApplicationIdle`	3	应用空闲后
`SystemIdle`	2	系统空闲后
`Background`	1	后台，仅在队列几乎空闲时执行
`Inactive`	0	无效，不执行

使用示例：

csharp 复制代码

Dispatcher.BeginInvoke(DispatcherPriority.Background, () => HeavyNonUIVisualWork());

Render 优先级的存在解释了 WPF 的一个经典现象：在事件处理器里改 UI，界面不会立刻重绘，而是等事件处理完、回到消息循环、Render 操作执行时才重绘（因此循环里疯狂改 UI 往往只看到最后一帧）。
Input 优先级高于普通操作，保证用户的鼠标键盘输入总能得到及时响应，不会被后台堆积的委托饿死。
Background 优先级让 WPF 可以在"无事可做"（没有窗口消息、没有更高优先级操作）的空闲时间片里执行低优先级工作。

3.3 线程归属检查：CheckAccess / VerifyAccess

csharp 复制代码

if (dispatcher.CheckAccess())
{
    // 当前线程就是 UI 线程，可直接操作
    txt.Text = "直接改";
}
else
{
    dispatcher.Invoke(() => txt.Text = "封送改");
}

// VerifyAccess：不是 UI 线程就直接抛异常
dispatcher.VerifyAccess();

这个方法我们上篇也已经介绍过. 这相当于 WinForms 里 Control.InvokeRequired / Control.CheckForIllegalCrossThreadCalls 的角色（见第 5 节对比表）。

3.4 DispatcherTimer：UI 线程上的定时器

DispatcherTimer 是绑定到 Dispatcher 的定时器：tick 事件在 UI 线程上触发，因此可以直接操作 UI，不需要再封送。

csharp 复制代码

var timer = new DispatcherTimer(DispatcherPriority.Background)
{
    Interval = TimeSpan.FromMilliseconds(500)
};
timer.Tick += (s, e) => clockText.Text = DateTime.Now.ToString("HH:mm:ss");
timer.Start();

与 System.Windows.Forms.Timer 一样，回调发生在 UI 线程，天然线程安全；
但它不是基于 WM_TIMER 消息实现的，而是由 Dispatcher 在帧循环中按时间戳触发，受优先级影响（低优先级下可能被推迟）；
比 WinForms 的 Timer（16ms 左右"不精确"）更可控，也更容易测试。

3.5 DispatcherFrame：嵌套消息循环

DispatcherFrame 可以创建一个"嵌套"的消息循环，在事件处理中途临时泵消息：

csharp 复制代码

public static void DoEvents()
{
    var frame = new DispatcherFrame();
    Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background,
        new Action(() => frame.Continue = false));
    Dispatcher.PushFrame(frame); // 进入嵌套循环，直到 Continue == false
}

Dispatcher.PushFrame(frame) 把当前控制权交给一个新的帧循环 （内部即一个新的消息泵），frame.Continue = false 时退出；
Dispatcher.Run() 的本质就是 PushFrame(new DispatcherFrame())------Application 的消息循环其实就是一层 Dispatcher 帧循环；
Dispatcher.ExitAllFrames() 一次退出所有帧，常用于关窗/退出程序时强制结束嵌套循环；
这正对应 WinForms 的 Application.DoEvents()------"在长任务中临时处理 UI 消息"，同样不推荐滥用（会导致重入，见第 6 节）。

3.6 DispatcherSynchronizationContext 与 async/await

WPF 启动时，会为 UI 线程安装一个 DispatcherSynchronizationContext。它把"上下文切换回 UI 线程"这件事自动化了：

csharp 复制代码

private async void Button_Click(object sender, RoutedEventArgs e)
{
    status.Text = "开始...";            // ① 在 UI 线程
    await Task.Delay(1000);             // ② 在后台继续
    status.Text = "完成...";            // ③ 自动回到 UI 线程（SynchronizationContext 的功劳）
}

await 之后的代码默认通过捕获到的 SynchronizationContext.Post 回到 UI 线程------而 WPF 的上下文实现内部就是 Dispatcher.BeginInvoke。也就是说：async/await + DispatcherSynchronizationContext = 自动跨线程封送。

配套的还有：

csharp 复制代码

// 拿到"UI 线程上下文"的 TaskScheduler，方便 TPL 任务续接到 UI 线程
TaskScheduler uiScheduler = TaskScheduler.FromCurrentSynchronizationContext();

以及 Dispatcher.Yield()：

csharp 复制代码

// 让渡控制权，等下一个空闲时间片再继续（常用于拆分长循环、保持 UI 响应）
for (int i = 0; i < 10000; i++)
{
    ProcessItem(i);
    if (i % 100 == 0) await Dispatcher.Yield(DispatcherPriority.Background);
}

3.7 Dispatcher.Hooks：观察调度过程

Dispatcher.Hooks 暴露了一组事件，可以在框架层面观察/干预 Dispatcher 的行为（测试工具、诊断工具常用）：

OperationStarted / OperationCompleted ------ 每个操作开始/结束；
OperationAborted、OperationPriorityChanged ------ 操作被取消或优先级改变；
DispatcherInactive ------ Dispatcher 进入空闲（没有可执行的操作和消息）；
DispatcherShutdownStarted / DispatcherShutdownFinished。

本篇内容我们详细介绍了Dispatcher的用法,下篇内容我们会继续详细深入到 Dispatcher的内部调用过程.

我是搬运工,欢迎关注

Dispacher(1/2)深入解析-详细使用

WPF 中的 Dispatcher 类深入解析

目录

1. 为什么需要 Dispatcher：WPF 的线程模型

2. Dispatcher 是什么

3. Dispatcher 的核心功能

3.1 跨线程封送：Invoke / BeginInvoke / InvokeAsync

3.2 优先级调度：DispatcherPriority

3.3 线程归属检查：CheckAccess / VerifyAccess

3.4 DispatcherTimer：UI 线程上的定时器

3.5 DispatcherFrame：嵌套消息循环

3.6 DispatcherSynchronizationContext 与 async/await

3.7 Dispatcher.Hooks：观察调度过程