WPF的消息机制（一）- 让应用程序动起来

原文:WPF的消息机制（一）- 让应用程序动起来

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/powertoolsteam/article/details/6106485

前言

谈起“消息机制”这个词，我们都会想到Windows的消息机制，系统将键盘鼠标的行为包装成一个Windows Message，然后系统主动将这些Windows Message派发给特定的窗口，实际上消息是被Post到特定窗口所在线程的消息队列，应用程序的消息循环再不断的从消息队列当中获取消息，然后再派发给特定窗口类的窗口过程来处理，在窗口过程中完成一次用户交互。

其实，WPF的底层也是基于Win32的消息系统，那么对于WPF应用程序来说，它是如何跟Win32的消息交互，这里到底存在一个什么样的机制？接下来我会通过下面几篇博文介绍这个消息机制:

WPF的消息机制（一）-让应用程序动起来

WPF的消息机制（二）-WPF内部的5个窗口

（1）隐藏消息窗口：句柄984620

（2）处理激活和关闭的消息的窗口和系统资源通知窗口

（3）用于用户交互的可见窗口：句柄3474914

（4）用于UI窗口绘制的可见窗口：句柄1115704

WPF的消息机制（三）-WPF输入事件的来源

WPF的消息机制（四）-WPF中UI的更新

 

让应用程序动起来

谈到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窗口，正是这些窗口，处理着来自系统，或者来自应用程序内部的消息。

敬请期待～