詳解WPF線程模型和Dispatcher
開始著手寫這個WPF系列，這里的一站式，就是力爭在每一個點上能把它講透，當然，做不到那么盡善盡美，如果有不對的地方也歡迎朋友們指正，我會逐步補充，爭取把這個系列寫好。
通常，WPF應用程序從兩個線程開始：一個用于處理呈現，一個用于管理UI。呈現線程有效地隱藏在后臺運行，而 UI 線程則接收輸入、處理事件、繪制屏幕以及運行應用程序代碼。
UI 線程對一個名為Dispatcher的對象內的工作項進行排隊。Dispatcher基于優先級選擇工作項，并運行每一個工作項，直到完成。每個 UI 線程都必須至少有一個Dispatcher，并且每個Dispatcher都只能在一個線程中執行工作項。
這兩段是MSDN上關于WPF線程模型的描述。主要介紹了兩個概念：一，WPF中線程一分為二，一個用于呈現（Render），一個用于管理UI；二，在UI線程中，使用了一個名為Dispatcher的類幫助UI線程處理任務。
那么這個線程模型和Dispatcher到底是怎樣的呢，它又有什么特點，有什么優缺點呢？在正式分析線程模型和Dispatcher之前，我先找一個插入點，希望這個插入點能為朋友們所理解。
作為一個Presentation的基架，WPF的使命就是要編寫圖形化的操作界面。而在Windows操作系統上，圖形化界面是建立在消息機制這個基礎上的，那么創建一個窗口，要經歷哪些步驟呢？
1. 創建窗口類。 WNDCLASSEX wcex； RegisterClassEx(&wcex);
2. 創建窗口。CreateWindow(…); ShowWindow(…); UpdateWindow(…);
3. 建立消息泵。
- while (GetMessage(&msg, NULL, 0, 0))
- {
- TranslateMessage(&msg);
- DispatchMessage(&msg);
- }
打個比方，我們在一個自動化的廠房里生產設備?；谡?，我們會首先定義好該設備的模板，這就是創建窗口類，這里”類”更多表示類別的意思。模板定義完畢，我們可以正式生產設備了，這就是創建窗口，這個CreateWindow的時候會通過字符串來匹配到我們定義的模板（窗口類）。創建成功后，我們要讓設備動起來，就要像人一樣，體內一定要有類似于血液的流傳機制，把命令傳達到設備的各個部分，這就是消息泵，這個泵就像我們的心臟一樣，源源不斷的通過GetMessage并Dispatch來分發血液（消息）。既然我們通過消息來對設備下達指令，那么就要有消息隊列來存儲消息，在Windows中，線程為基本的調度單位，這個消息隊列就在線程上，當循環使用GetMessage時，就是在當前線程的消息隊列中任勞任怨的取出消息，然后分發到對應的窗口中去。
那么具體到WPF，它又是一個怎么樣的情況，如何和老的技術兼容，又有什么新的突破呢？
WPF引入了Dispatcher的概念，這個Dispatcher的主要功能類似于Win32中的消息隊列，在它的內部函數，仍然調用了傳統的創建窗口類，創建窗口，建立消息泵等操作。Dispatcher本身是一個單例模式，構造函數私有，暴露了一個靜態的CurrentDispatcher方法用于獲得當前線程的Dispatcher。對于線程來說，它對Dispatcher是一無所知的，Dispatcher內部維護了一個靜態的List
那么這個創建窗口，建立消息泵又是什么時候被調用的呢？在Dispatcher內部，維護了一個HwndWrapper的字段，在Dispatcher的構造函數中，調用了HwndWrapper的構造函數，這個創建窗口類，創建窗口就是在這個函數中被調用的。這里實際的類是MessageOnlyHwndWrapper，這個Message-Only，是Windows編程中常用的伎倆，創建一個隱藏窗口，僅僅用來派發消息。那么循環讀取消息的消息泵又是什么時候建立起來的呢？
Dispatcher對外提供了一個靜態的Run函數，顧名思義，就是啟動Dispatcher，在函數內部，調用了PushFrame函數，在這個函數中，可以找到熟悉的GetMessage, TranslateAndDispatchMessage。那么這個PushFrame是怎么回事，Frame這個概念又是如何而來的呢？
這個就是WPF線程模型引入的一個新的概念，嵌套消息泵，就是在一個While(GetMessage(...))內部又啟動了一個While(GetMessage(...))。每調用一次PushFrame，就會啟動一個新的嵌套的消息泵。每調用一次GetMessage，就在線程的消息隊列中取出一個消息，直至取出WM_QUIT的時候GetMessage才返回False。這個GetMessage函數Windows內部進行了處理，當消息隊列為空時，掛起執行線程，避免死循環的發生。關于嵌套消息泵的優缺點，我們稍后再講，先來看看Dispatcher是如何處理任務的：
Windows中定義了很多Message，以WM_開頭，在注冊窗口類的時候需要設置窗口過程函數，GetMessage取得的消息再分發到窗口過程函數中，整個過程為：
這個圖來自于侯捷的經典書籍《深入淺出MFC》，1.首先創建Window并指定窗口的過程函數WndProc。2.當窗口創建時一個WM_CREATE被放入到消息隊列中，3.消息泵通過GetMessage取得該消息后分發到窗口，窗口過程函數處理這個WM_CREATE消息…
那么WPF線程模型的Dispatcher在這個過程中扮演了什么角色呢？前面的1,2,3仍然如此，當窗口過程函數接收到消息時，它需要根據消息的類別把Windows消息轉譯成內部的RoutedEvent或者調用布局函數等來處理。前面提到了Dispatcher主要功能類似于Win32中的消息隊列，這個隊列中存放的對象是DispatcherOperation，這個DispatcherOperation，顧名思義，就是把每一個執行項封裝成一個對象，類似：
這個隊列的類型為PriorityQueue，是一個含有優先級的隊列。WPF定義了這個優先級DispatcherPriority，有
當對這個PriorityQueue調用DeQueue時，就會取出優先級***的任務。那么這個隊列中的任務是什么時候被添加的，又是什么時候被取出執行的呢？
Dispatcher暴露了兩個方法，Invoke和BeginInvoke，這兩個方法還有多個不同參數的重載。其中Invoke內部還是調用了BeginInvoke，一個典型的BeginInvoke參數如下：
public DispatcherOperation BeginInvoke(Delegate method, DispatcherPriority priority, params object[] args);
在這個BeginInvoke內部，會把執行函數method與參數args封裝成DispatcherOperation,并按priority加入到PriorityQueue中，這個返回值就是內部創建的DispatcherOperation。也就是說每調用一次Invoke和BeginInvoke，就向Dispatcher中加入了一個任務，那么這個任務什么時候被執行呢？
DispatcherPriority定義了很多優先級，WPF將這些優先級主要分成兩類。前臺優先級和后臺優先級，其中前臺包括Loaded~Send，后臺包括Background~Input。剩下的幾個優先級除了Invalid和Inactive都屬于空閑優先級，處理順序同后臺優先級。這個前臺優先級和后臺優先級的分界線是以Input來區分的，這里的Input指的是鍵盤輸入和鼠標移動、點擊等等。ProrityQueue的來源有：
當然，這里Hwnd級別Hook到的消息最終也是調用Dispatcher的Invoke/BeginInvoke方法加入到Dispatcher的隊列中去的。當處理這個PriorityQueue時，會首先取得隊列中的***優先級，如果它屬于前臺優先級，執行。如果屬于后臺優先級，那么它要去掃描線程的消息隊列，看看其中是由有類似WM_MOUSEMOVE之類的Input消息。如果沒有，執行。如果存在，則放棄執行，并啟動一個Timer，當Timer喚起時繼續判斷是否可以執行。
那么處理PriorityQueue的時機呢？當你調用BeginInvoke，向隊列中加入執行項的同時，也會調用處理Queue的判斷。判斷邏輯和上面類似，隊列中***優先級是前臺優先級，向隱藏窗口PostMessage，這個消息是Disptcher使用RegisterWinodwMessage注冊的自定義消息。然后在GetMessage的時候如果取出這個自定義消息，則處理PriorityQueue。如果是后臺優先級，掃描線程消息隊列的Input消息，決定是否啟動Timer還是PostMessage。
舉個例子，在后臺線程中向UI線程中使用Invoke來發送請求，經歷的過程為：
1. 調用Invoke，對傳入的參數DispatcherPriority進行判斷，如果是Send，這是個特殊的優先級，直接切換線程上下文，執行任務并返回。如果是其他的優先級，調用BeginInvoke。
2. 在BeginInvoke中，把傳入的Delegate和參數封裝成DispatcherOperation，加入到PriorityQueue中。
3. 調用隊列處理的請求函數，希望處理PriorityQueue。
4. 如果隊列中***優先級屬于前臺優先級，調用PostMessage向隱藏窗口發送自定義消息。后臺處理這里省略不表。
5. 在GetMessage中取得消息并分發到隱藏窗口，這里使用的是常見的SubWindow（注釋一），消息通過Hook發送到Dispatcher的WndProcHook函數進行處理。
6. 在WndProcHook中，如果接收到的Window消息是Dispatcher自定義的消息，則真正處理PriorityQueue。
7. 處理PriorityQueue，從中取出一個任務，進行前后臺優先級判斷，決定是否處理還是啟動Timer稍后處理。
回過頭來，說一說嵌套的消息循環，這個要從模態對話框說起，一個通常的模態對話框場景如下：
SomeCodeA();
bool? result = dlg.ShowDialog();
SomeCodeB();
代碼運行在UI線程中，當執行到dlg.ShowDialog時，啟動模態對話框，等待用戶點擊Yes/No或者關閉對話框，對話框關閉后程序繼續執行SomeCodeB代碼。那么程序要在SomeCodeB處等待ShowDialog返回后才繼續執行。當然你可以使用WaitHandle來同步，不過這個需要掛起當前(UI)線程，如果主窗口中有動畫等UI動作，那么會停止得不到響應。這里WPF使用的是PushFrame，就是在ShowDialog內部又建立起了一個消息泵。While(GetMessage(…))。一方面，可以確保UI線程中的消息可以被處理；另一方面，因為是While循環，在對話框關閉時返回，可以確保SomeCodeB的執行順序。
那么是不是這個嵌套的消息循環真的如此***呢？當然不是，它打開了一扇門的同時，也打開了另一扇門。一個情景，當收到WM_SIZE消息的時候，Layout系統開始處理，如果在這個處理過程中，又啟動了PushFrame，那么嵌套的消息泵就會繼續從消息隊列中取出消息，如果下一個消息也是WM_SIZE，那么進行處理。假設這個消息處理結束后這個嵌套的消息泵返回了，那么***個WM_SIZE得以繼續處理。這樣就發生了錯誤，本來12的處理順序變成了121。當然這種情況不僅僅發生在Layout中，所以WPF在Dispatcher中加入了一個DisableProcessing函數，在Layout等關鍵過程中調用了這個函數，在這個過程中停止pump消息和禁止PushFrame。
在WPF中，所有的WPF對象都派生自DispatcherObject，DispatcherObject暴露了Dispatcher屬性用來取得創建對象線程對應的Dispatcher。鑒于線程親緣性，DispatcherObject對象只能被創建它的線程所訪問，其他線程修改DispatcherObject需要取得對應的Dispatcher，調用Invoke或者BeginInvoke來投入任務。一個UI線程至少有一個Dispatcher來建立消息泵處理任務，一個Dispatcher只能對應一個UI線程。那么UI線程和Render線程又如何呢？
開篇提到，WPF線程模型一分為二，一個是UI線程，一個是Render線程。這兩個被設計成分離的關系，通過Channel（event）來進行通信。兩者之間的數量關系是一個WPF進程只能有一個Render線程，旦可以有大于等于一個的UI線程。通常情況下是一個UI線程，也就是一個Dispatcher，那么什么情況下需要建立多個呢？
大多情況下是不需要的，少數情況下，比如MediaElement，或者Host其他ActiveX控件，我們期望在其他線程中創建，以提高性能。可以新建線程，在新線程中創建控件，并調用Dispatcher.Run啟動Dispatcher。這樣主Window和新控件就處在不同線程中，兩者間的通信可以使用VisualTarget連接視覺樹或者使用D3DImage拷貝新控件到主Window中顯示。
開篇有益，WPF沒有什么全新的技術，但提出了很多新的概念。
注釋一: SubWindow，子窗口子類化。通常情況，所有同類別Window會共用同一個消息處理函數WndProc，子Window可以調用SetWindowLong用SubWndProc替換WndProc，這個通常稱為Sub-Window。
本文來自周永恒的博客園文章《一站式WPF—線程模型和Dispatcher》
【編輯推薦】
