标签：后台运行 存储 延迟 verify wpf 服务 元素 异常 接收
一、线程概述：
WPF 应用程序从两个线程开始：
一个用于处理呈现
一个用于管理 UI
呈现线程有效地隐藏在后台运行，而UI线程则接收输入、处理事件、绘制屏幕以及运行应用程序代码。
大多数应用程序都使用一个 UI 线程，但在某些情况下，最好使用多个线程。我们将在后面举例说明这一点。
UI 线程对一个名为 Dispatcher 的对象内的工作项进行排队。
Dispatcher基于优先级选择工作项，并运行每一个工作项，直到完成。每个UI线程都必须至少有一个Dispatcher，并且每个 Dispatcher 都只能在一个线程中执行工作项。
要构建响应速度快、且用户友好的应用程序，诀窍是减小工作项，以最大限度地提高Dispatcher吞吐量。这样，工作项将永远不会因为在Dispatcher队列中等待处理而失效。输入与响应之间的任何可察觉的延迟都会使用户不快。
那么，WPF应用程序应如何处理大型操作呢？如果您的代码涉及大型计算，或者需要查询某台远程服务器上的数据库，应怎么办呢？通常的办法是在单独的线程中处理大型操作，而专门让UI线程来负责处理Dispatcher队列中的工作项。当大型操作完成时，可以将结果报告给 UI 线程来显示。
一直以来，Windows只允许创建UI元素的线程访问这些元素。这意味着负责某项长时间运行任务的后台线程无法更新已完成的文本框。Windows 这样做是为了确保 UI 组件的完整性。如果列表框的内容在绘制过程中被后台线程更新，那么该列表框看上去将会很奇怪。
WPF 使用一种内置互斥机制来强制执行这种协调。WPF 中的大多数类都派生自 DispatcherObject。DispatcherObject 在构造时存储对链接到当前所运行线程的 Dispatcher 的引用。实际上，DispatcherObject与创建它的线程关联。
在程序执行过程中，DispatcherObject 可以调用它的公共 VerifyAccess 方法。
VerifyAccess 检查与当前线程关联的 Dispatcher，并将它与构造过程中存储的 Dispatcher 引用进行比较。
如果两者不匹配，VerifyAccess将引发异常。VerifyAccess 用于在每个属于 DispatcherObject 的方法的开头调用。
如果只有一个线程可以修改 UI，那么后台线程如何与用户交互呢？
后台线程可以请求 UI 线程代表它执行操作。这是通过向 UI 线程的 Dispatcher 注册工作项来完成的。
Dispatcher 类提供两个注册工作项的方法：Invoke 和 BeginInvoke。
这两个方法均调度一个委托来执行。
Invoke 是同步调用，也就是说，直到 UI 线程实际执行完该委托它才返回。
BeginInvoke 是异步的，将立即返回。
Dispatcher 按优先级对其队列中的元素进行排序。向 Dispatcher 队列中添加元素时可指定 10 个级别。
这些优先级在 DispatcherPriority 枚举中维护。有关 DispatcherPriority 级别的详细信息可以在 Windows SDK 文档中找到。
标签：后台运行 存储 延迟 verify wpf 服务 元素 异常 接收
原文地址：http://www.cnblogs.com/tranw/p/6443825.html
