标签：
谈到桌面应用程序，我们第一反应就是它的消息机制是怎么处理的，那么我们就先聊聊这个windows消息机制
谈起“消息机制”这个词，我们都会想到Windows的消息机制，系统将键盘鼠标的行为包装成一个Windows Message，然后系统主动将这些Windows Message派发给特定的窗口，实际上消息是被Post到特定窗口所在线程的消息队列，应用程序的消息循环再不断的从消息队列当中获取消息，然后再派发给特定窗口类的窗口过程来处理，在窗口过程中完成一次用户交互。
其实，WPF的底层也是基于Win32的消息系统，那么对于WPF应用程序来说，它是如何跟Win32的消息交互，这里到底存在一个什么样的机制？接下来我会通过下面几篇博文介绍这个消息机制:
谈到WPF的消息，首先应该知道DispactherObject以及Dispatcher在WPF系统中的作用。
WPF大部分的对象都是从DispatcherObject派生的，从这里派生的对象具有一个明显的特征，那就是：修改对象时所在的线程，和创建对象时所在线程必须为同一个线程，这就是微软所谓的线程亲缘性（Thread affinity）的最简单理解。那么谁能保证线程亲缘性呢？那就是Dispacher了。从DispatcherObject派生的类型继承三个重要的成员：Dispatcher属性，CheckAccess(), VerifyAccess()方法。其中后面两个方法就是检验线程亲缘性的。按照WPF的实现，如果你自己定义了个WPF的类型，并且是DispatcherObject的子类，你就必须在public的成员定义的逻辑开始处，调用base.Dispatcher.VerifyAccess()，检验线程亲缘性。那么Dispatcher到底还做了什么事情呢？
首先，我们看一下一个WPF的Application在启动之后都走了哪些逻辑：
通过调用堆栈可以看出，蓝色的部分是启动了一个线程，VisualStudio在Host的进程当中运行当前应用程序；红色的部分是从Application.Main函数开始执行，经过几个函数到达Dispatcher.Run()，最后到达Dispather.PushFrameInpl()方法。那么一个Application在Run之后,为什么要调用Dispatcher.Run()呢，他做了些什么事情你？如果通过Reflector仔细查看Application.Run()，你会发现里面实际起作用的代码并不多，最后都是Dispatcher.Run在做事情。那么一个Application启动之后，按照以前对Win32的消息机制的理解，当应用程序启动后，必须进入消息循环，对于WPF，也是一样的。那么WPF应用程序是在什么地方进入消息循环呢？其实这就是Dispatcher.Run()做的事情。查看上图最后一步Dispacther.PushFrameImpl()的代码，你会看到有下面的一段代码：
很明显，橙色的部分是一个循环，看起来是不是很眼熟，跟Win32编程碰到的消息循环是否很像？对了，这就是WPF应用程序进入了消息循环。循环调用GetMessage方法从当前线程的消息队列当中不停的获取消息，取出一个msg之后，交给TranslateAndDispatchMessage方法Dispatch到不同的窗口过程去处理。这样以来，任何需要应用程序处理的消息通过这个过程，被不同的窗口处理了，应用程序就动起来了。
下面的一篇我会介绍WPF当中的Win32窗口，正是这些窗口，处理着来自系统，或者来自应用程序内部的消息。
对于Windows系统来说，它是一个消息系统，消息系统的核心就是窗口。对于WPF来说也是如此。那么WPF内部为什么需要窗口，又存在哪些窗口呢？
前面，我们频繁的提及“线程”，“Dispatcher”其实，运行WPF应用程序所在的线程就是WPF所谓的UI线程，在Application.Run之后，调用Dispatcher.Run时会检查当前线程是否已经存在了一个Dispatcher对象，如果没有就构造一个，在这里，一个线程对应一个Dispatcher。因此，WPF的对象在获取this.Dispatcher属性时，不同对象取的都是同一个Dispatcher实例。另外，前面提到的“消息循环”，“消息队列”等都是Win32应用程序的概念，我们知道，提起这些概念，必然会跟Win32的“窗口”，“Handle”，“WndProc”之类的概念离不开，那么WPF里面究竟有没有“窗体”，“Handle”，“WndProc”呢？
我想说的是：有，还不止一个，只不过没有暴露出来，外面不需要关心这些。
通常情况下，一个WPF应用程序在运行起来的时候，后台会创建5个Win32的窗口，帮助WPF系统来处理操作系统以及应用程序内部的消息。在这5个窗口中，只有一个是可见的，可以处理输入事件与用户交互，其他4个窗口都是不可见的，帮助WPF处理来自其他方面的消息。接下来我会来介绍究竟这5个Win32的窗口如何帮助WPF处理消息，我会根据每个窗口创建的顺序来介绍。
创建时机：在Application的构造函数调用基类DispatcherObject的构造函数的时候，会创建一个Dispatcher对象，在Dispatcher的私有构造函数当中。
用途：实现WPF线程模型的异步调用。
谈到异步调用，相信许多人都不陌生。WinForm下，我们通常为了使一些花费较多时间的方法调用不影响UI的响应，会将这个操作分为很多步，然后使用BeginInvoke调用每一步，这样UI响应就不会被阻塞。BeginInvoke的本质是往消息队列当中PostMessage，而不是直接调用，与此同时，UI行为（MouseMove）导致系统也往消息队列当中PostMessage更新UI，但由于彼此花费的时间很短，就感觉两个消息是被同时处理似的，界面就不会觉得被阻塞了。WPF同样面临这样的问题，他是如何解决的呢？在这里Window 1#起着至关重要的作用。通过下面一副图我们来看看Window 1#在做什么事情？
WPF也是通过BeginInvoke来解决的，而Wpf的BeginInvoke是在Dispatcher上面暴露了，因为整个消息系统都是Dispatcher在协调。从上面图可以看出Dispatcher在调用BeginInvoke之后所经历的流程，最终是什么时候Foo()被真正执行的。
第一步，就是将调用的Delegate和优先级包装成一个DispatcherOperation放入Dispatcher维护的优先级队列当中，这个Queue是按DispatcherPriority排序的，总是高优先级的DispatcherOperation先被处理。关于优先级相关知识可以参考MSDN对WPF线程模型的解释。
第二步，往当前线程的消息队列当中Post一个名为MsgProcessQueue的Message。这个消息是WPF自己定义的，见Dispatcher的静态构造函数当中的
_msgProcessQueue = UnsafeNativeMethods.RegisterWindowMessage("DispatcherProcessQueue");
这个消息被Post到消息队列之前，还要设置MSG.Handle，这个Handle就是Window 1#的Handle。指定Handle是为了在消息循环Dispatch消息的时候，指定哪个窗口的WndProc（窗口过程）处理这个消息。在这里所有BeginInvoke引起的消息都是Window1#的窗口过程来处理的。
第三步，消息循环读取消息。
第四步，系统根据获取消息的Handle，发现跟Window1#的Handle相同，那么这个消息派发到Window1#的窗口过程，让其处理。
第五步，在窗口过程中，优先级队列当中取一个DispatcherOperation。
第六步，执行DispatcherOperation.Invoke方法，Invoke方法的核心就是调用DispatcherOperation构造时传入的Delegate，也就是Dispatcher.BeginInvoke传入的Delegate。最终这个Foo()方法就被执行了。
通过上面的六步过程，一次Dispatcher.BeginInvoke就被处理完成。而这个过程需要消息不断的流动，就必须加入消息队列，最后还要特定的窗口过程处理，而核心的东西就是这个隐藏的Window1#，他在WPF当中只负责处理异步调用，其他的消息他不关心，剩余的4个窗口在处理。这个Window1#在WPF当中被包了一层壳子，如果感兴趣，你可以去查看类型MessageOnlyHwndWrapper。
创建时机：在调用Application.Run之后，运行到Application.EnsureHwndSource()方法当中。
用途：派发Application的Activated，Deactivated，SessionEnding事件。
WPF为了安全起见没有让UI窗口来处理应用程序激活，反激活，以及操作系统关闭时对应的消息，而是内部创建了一个隐藏的窗口，专门用来接收WM_ACTIVATEAPP和WM_QUERYENDSESSION两个Windows消息。从线程的消息队列拿到这两个消息后，会触发WPF的Application.Activated，Application.Deactivated，Application.SessionEnding这三个事件。
更详细的可参考Application类型的EnsureHwndSource(),AppFilterMessage(),这两个方法。
上面的过程可用下图描述：
创建时机：Application的MainWindow的Xaml被反序列化成对象之后，需要确认Window的ThemeStyle的时候。
用途：处理当操作系统的Theme发生改变后，以及诸如SystemColors，SystemFonts，电源，显示器等跟系统关联的资源发生改变时，更新WPF这边的表现。
WPF在应用出现的MainWindow在初始化完成后，会创建一个隐藏的窗口，专门处理来自系统相关资源更新后的消息，比如WM_ThemeChanged，WM_SystemColorChanged，WM_DisplayChange,WM_PowerBroadcast等等。跟Window2#的初衷类似，为了安全起见，没有通过可见的UI窗口来处理这些消息，而是内容创建了这个隐藏的Window4#窗口来处理这些消息，确保UI窗口可以安全的更新由于系统Theme及相关资源改变后的表现。
上面的过程可用下图描述：
本来想自己写这个WPF消息机制的逻辑，毕竟资历有限，看到网上有个大神写得比较全面，细致，我就引用了下，做了点更改，让你们看起来会更容易理解一点，后面好多东西我们会基于这样一个windows消息机制来处理问题，尤其是View 层与Viewmodel层的消息通知，还有一些线程安全的问题。
参考：http://www.cnblogs.com/therock/articles/2140459.html
从0 开始 WPF MVVM 企业级框架实现与说明 ---- 第一讲 WPF中 windows消息机制
标签：
原文地址：http://www.cnblogs.com/hwy425/p/4970721.html
