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