前言

　　談起“消息機制”這個詞，我們都會想到Windows的消息機制，系統將鍵盤鼠標的行為包裝成一個Windows Message，然后系統主動將這些Windows Message派發給特定的窗口，實際上消息是被Post到特定窗口所在線程的消息隊列，應用程序的消息循環再不斷的從消息隊列當中獲取消息，然后再派發給特定窗口類的窗口過程來處理，在窗口過程中完成一次用戶交互。

　　其實，WPF的底層也是基于Win32的消息系統，那么對于WPF應用程序來說，它是如何跟Win32的消息交互，這里到底存在一個什么樣的機制？接下來我會通過下面幾篇博文介紹這個消息機制:

　　WPF的消息機制（一）-讓應用程序動起來

　　WPF的消息機制（二）-WPF內部的5個窗口

　　（1）隱藏消息窗口

　　（2）處理激活和關閉的消息的窗口和系統資源通知窗口

　　（3）用于UI窗口繪制的可見窗口

　　（4）用于用戶交互的可見窗口

　　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窗口，正是這些窗口，處理著來自系統，或者來自應用程序內部的消息。