周沭玲，金 楠，侯海平

隨著互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，各種應(yīng)用軟件層出不窮，例如即時(shí)通訊軟件、辦公軟件、信息資訊、購(gòu)物娛樂(lè)軟件等，用戶(hù)花在軟件上的時(shí)間越來(lái)越多，時(shí)間不斷被各種軟件割裂，用戶(hù)時(shí)間的碎片化越趨明顯.通過(guò)應(yīng)用軟件占領(lǐng)用戶(hù)的時(shí)間、增加用戶(hù)粘度是企業(yè)追求的目標(biāo)，實(shí)現(xiàn)這一目標(biāo)的關(guān)鍵就是提升應(yīng)用軟件操作的用戶(hù)體驗(yàn).用戶(hù)的操作響應(yīng)速度則是提升應(yīng)用軟件用戶(hù)體驗(yàn)的關(guān)鍵因素之一，通常一個(gè)用戶(hù)無(wú)法忍受3～5 秒以上的響應(yīng)等待.例如Android 操作系統(tǒng)中服務(wù)的響應(yīng)時(shí)間要求為10 秒以?xún)?nèi)，廣播消息的響應(yīng)時(shí)間為10～60 秒，UI 操作的響應(yīng)時(shí)間為5 秒以?xún)?nèi).當(dāng)程序響應(yīng)超出這個(gè)時(shí)間，就會(huì)出現(xiàn)卡頓假死狀態(tài)，用戶(hù)被迫等待，無(wú)法進(jìn)行軟件的下一步操作［1］.這就會(huì)造成用戶(hù)放棄使用或者卸載該軟件，軟件用戶(hù)的流失對(duì)于互聯(lián)網(wǎng)時(shí)代的企業(yè)是無(wú)法接受的，因此減少UI 線(xiàn)程阻塞成為優(yōu)化軟件性能的主要研究對(duì)象［2］.

大多數(shù)基于不同平臺(tái)的開(kāi)發(fā)框架都支持線(xiàn)程技術(shù)，開(kāi)發(fā)者可以將耗時(shí)費(fèi)力的工作任務(wù)遷移到子線(xiàn)程中去運(yùn)行，從而減少主線(xiàn)程或者UI 線(xiàn)程壓力［3］，做到快速響應(yīng)用戶(hù)操作，然而這種解決傳統(tǒng)單UI 線(xiàn)程阻塞問(wèn)題的方法并不適合多UI 控件高并發(fā)訪(fǎng)問(wèn)場(chǎng)景.

本文提出一套多UI 線(xiàn)程高并發(fā)的解決方案，涉及多UI 線(xiàn)程、操作系統(tǒng)消息機(jī)制、子線(xiàn)程通信等知識(shí).整體實(shí)驗(yàn)過(guò)程如下：首先，還原傳統(tǒng)單UI 線(xiàn)程阻塞問(wèn)題的解決方法；再次，模擬單個(gè)UI 線(xiàn)程高并發(fā)訪(fǎng)問(wèn)的問(wèn)題場(chǎng)景，發(fā)現(xiàn)使用傳統(tǒng)方法無(wú)法解決阻塞問(wèn)題，從而引出操作系統(tǒng)消息機(jī)制；第三，使用操作系統(tǒng)消息機(jī)制解決單個(gè)UI 控件高并發(fā)訪(fǎng)問(wèn)的阻塞問(wèn)題；最后，模擬多個(gè)UI 控件高并發(fā)訪(fǎng)問(wèn)的阻塞問(wèn)題，提出將每個(gè)UI 控件放入獨(dú)立UI 線(xiàn)程中的解決方法，利用操作系統(tǒng)消息機(jī)制實(shí)現(xiàn)多個(gè)子線(xiàn)程與多個(gè)UI 線(xiàn)程通信，最終實(shí)現(xiàn)多個(gè)UI 控件高并發(fā)條件下也能夠?qū)崟r(shí)刷新.

以下實(shí)驗(yàn)全部在Windows 操作系統(tǒng)環(huán)境中完成，采用Windows Presentation Foundation開(kāi)發(fā)框架技術(shù)實(shí)現(xiàn)實(shí)驗(yàn)功能，下文統(tǒng)一簡(jiǎn)稱(chēng)WPF.

1 問(wèn)題場(chǎng)景

1.1 傳統(tǒng)場(chǎng)景中問(wèn)題及常規(guī)處理方法

傳統(tǒng)業(yè)務(wù)場(chǎng)景中常見(jiàn)的問(wèn)題如“下載數(shù)據(jù)時(shí)更新UI 界面中的進(jìn)度條”“用戶(hù)使用網(wǎng)絡(luò)時(shí)實(shí)時(shí)監(jiān)控網(wǎng)絡(luò)流量和速度”“接收通知消息顯示到UI 界面中”等，通過(guò)建立子線(xiàn)程或服務(wù)程序都能得到很好地解決［4］.在主線(xiàn)程或UI線(xiàn)程中開(kāi)啟子線(xiàn)程或服務(wù)，將上述耗時(shí)且易產(chǎn)生線(xiàn)程阻塞的工作任務(wù)添加到子線(xiàn)程或服務(wù)中執(zhí)行，等到子線(xiàn)程或服務(wù)中的任務(wù)執(zhí)行完成后，系統(tǒng)再回傳完成的消息給主線(xiàn)程，繼而完成一次耗時(shí)任務(wù)處理［5］.可以看出，開(kāi)啟子線(xiàn)程或服務(wù)這種方法能夠較好處理此類(lèi)問(wèn)題.

1.2 UI 控件高并發(fā)訪(fǎng)問(wèn)場(chǎng)景中問(wèn)題的發(fā)現(xiàn)

如果軟件在相對(duì)較短的時(shí)間內(nèi)加載較少圖片時(shí)（加載圖片相當(dāng)于線(xiàn)程中的工作任務(wù)），并不會(huì)暴露出軟件的性能問(wèn)題.但如果切換到新場(chǎng)景中，多人共同操作UI 界面，需要將軟件加載圖片的數(shù)量增加到10 000 張（相當(dāng)于UI 線(xiàn)程工作任務(wù)量較大，此處可以看成是一個(gè)耗時(shí)任務(wù)），甚至更多的圖片，實(shí)驗(yàn)結(jié)果發(fā)現(xiàn)此時(shí)UI 控件則會(huì)出現(xiàn)假死狀態(tài)，即使提高計(jì)算機(jī)性能配置也很難改變這一現(xiàn)象，因?yàn)闊o(wú)法知道用戶(hù)是否需要加載更多的圖片.

為了能夠解決上述問(wèn)題，嘗試采用1.1 中常規(guī)處理方法.模擬實(shí)驗(yàn)過(guò)程為：主線(xiàn)程創(chuàng)建ListView 控件用于呈現(xiàn)10 000 張圖片，而呈現(xiàn)10 000 張圖片是一件非常耗費(fèi)時(shí)間的任務(wù)，按照1.1 中處理方法需要將這個(gè)耗時(shí)任務(wù)放到子線(xiàn)程中去完成，結(jié)果發(fā)現(xiàn)這樣并不能啟動(dòng)這個(gè)子線(xiàn)程，因?yàn)樗`背了WPF 線(xiàn)程親緣性規(guī)則.WPF 線(xiàn)程親緣性要求控件的創(chuàng)建和使用必須在同一個(gè)線(xiàn)程中，而當(dāng)前情形是在主線(xiàn)程中創(chuàng)建Listview，在子線(xiàn)程中訪(fǎng)問(wèn)Listview，兩個(gè)線(xiàn)程同時(shí)擁有一個(gè)控件，這是不被WPF開(kāi)發(fā)框架允許的，因此實(shí)驗(yàn)失敗.

在監(jiān)控多個(gè)客戶(hù)端數(shù)據(jù)的場(chǎng)景中，作為服務(wù)器一端實(shí)時(shí)獲取多個(gè)客戶(hù)端數(shù)據(jù)，并同時(shí)呈現(xiàn)到UI 界面上多個(gè)控件中，服務(wù)器端程序UI 界面中每一個(gè)控件對(duì)應(yīng)一個(gè)客戶(hù)端，并負(fù)責(zé)呈現(xiàn)對(duì)應(yīng)客戶(hù)端的數(shù)據(jù)，如果其中一個(gè)控件處在高并發(fā)處理數(shù)據(jù)中，則整個(gè)UI 界面會(huì)出現(xiàn)假死狀態(tài)，其他控件更是無(wú)法處理對(duì)應(yīng)的客戶(hù)端數(shù)據(jù).

同樣嘗試采用上述子線(xiàn)程方法處理多個(gè)客戶(hù)端數(shù)據(jù).模擬實(shí)驗(yàn)過(guò)程為：主線(xiàn)程中創(chuàng)建多個(gè)UI 控件，根據(jù)客戶(hù)端創(chuàng)建對(duì)應(yīng)的子線(xiàn)程，有多少客戶(hù)端就建立多少個(gè)子線(xiàn)程，每個(gè)子線(xiàn)程用于接收客戶(hù)端數(shù)據(jù)，根據(jù)前述實(shí)驗(yàn)結(jié)論可以發(fā)現(xiàn)不能在子線(xiàn)程中操作其他線(xiàn)程創(chuàng)建的控件.另外，如果在子線(xiàn)程中采用循環(huán)方式采集對(duì)應(yīng)客戶(hù)端的數(shù)據(jù)，也非常容易造成UI 線(xiàn)程阻塞，因?yàn)檫@些數(shù)據(jù)最終還是要通過(guò)循環(huán)方式加載到UI 控件中，循環(huán)加載是造成UI 線(xiàn)程阻塞的主要因素.因此，采用傳統(tǒng)子線(xiàn)程處理耗時(shí)任務(wù)的方式并不能成功解決UI 控件高并發(fā)問(wèn)題.

2 使用WPF 消息機(jī)制解決單UI 線(xiàn)程阻塞問(wèn)題

2.1 WPF 消息機(jī)制原理

WPF 中UI 控件造成卡頓假死現(xiàn)象是由于UI 控件所在線(xiàn)程阻塞造成的.WPF 消息機(jī)制給解決此類(lèi)問(wèn)題提供了可能性.其原理如圖1所示.

步驟1：Windows 操作系統(tǒng)收到中斷消息，使用PostMessage（）方法將消息發(fā)送給Message Queue（消息隊(duì)列），這些中斷消息可以是用戶(hù)鼠標(biāo)的點(diǎn)擊、鍵盤(pán)的輸入，也可以是封裝的Message 消息.在使用PostMessage（）發(fā)送消息時(shí)，將最新的Message 插入到Message Queue 尾部.

步 驟2：調(diào) 用Dispatcher.PushFrameImpl（）方法消費(fèi)Message Queue 中的消息，這是一種循環(huán)機(jī)制，Dispatch 內(nèi)部通過(guò)GetMessage（）方法不斷地從Message Queue 中獲取消息.

步驟3：在WPF 中，Dispatcher 將獲取的消息分發(fā)到指定的窗口，對(duì)于一個(gè)WPF 程序來(lái)說(shuō)將會(huì)有一個(gè)隱藏的窗口來(lái)接收分發(fā)的消息.

步驟4：這個(gè)隱藏窗口使用類(lèi)似Win32 系統(tǒng)中WndProc（）方法處理收到的消息，從而更新UI 界面.

步驟5：如果當(dāng)前窗口又產(chǎn)生新的消息，將再交由Windows 操作系統(tǒng)來(lái)處理消息，進(jìn)入下一輪循環(huán).

2.2 拆分任務(wù)解決線(xiàn)程阻塞問(wèn)題

通常UI 線(xiàn)程阻塞是因?yàn)樵诋?dāng)前窗口處理的任務(wù)過(guò)大，耗時(shí)過(guò)多，任務(wù)不能及時(shí)處理，造成UI 線(xiàn)程不能接收Windows 操作系統(tǒng)傳來(lái)的消息造成的.例如UI 線(xiàn)程在處理一個(gè)大任務(wù)（加載10 000 張圖片）時(shí)，Windows 操作系統(tǒng)的消息就無(wú)法及時(shí)傳遞到當(dāng)前窗口，導(dǎo)致UI界面假死狀態(tài).窗口標(biāo)題欄會(huì)出現(xiàn)“沒(méi)有響應(yīng)”字樣.

圖1 WPF 框架中Windows 消息機(jī)制時(shí)序圖

對(duì)以上過(guò)程中步驟4 進(jìn)行分析，如果UI線(xiàn)程接收到的操作系統(tǒng)消息指令是處理一個(gè)工作量較大的任務(wù)時(shí)，可以將工作量過(guò)大的任務(wù)切分成一個(gè)個(gè)小的任務(wù)，每一個(gè)小的任務(wù)完成后，向Windows 操作系統(tǒng)傳遞一個(gè)消息，從而保證UI 線(xiàn)程可以正常接收到Windows 操作系統(tǒng)的消息，讓當(dāng)前UI 線(xiàn)程有響應(yīng).例如：在處理加載10 000 張圖片時(shí)，如果等10 000 張圖片加載完成再去更新UI 線(xiàn)程，就會(huì)造成長(zhǎng)時(shí)間阻塞UI 線(xiàn)程.因此不必一次加載全部圖片，可以一次只加載10 張圖片，然后通過(guò)發(fā)送消息給操作系統(tǒng)更新一次UI 線(xiàn)程，總的任務(wù)就可以分解成1 000 次去更新UI 線(xiàn)程，從而在界面響應(yīng)上保證用戶(hù)的體驗(yàn)，這種方法稱(chēng)為“拆分任務(wù)”.通過(guò)“拆分任務(wù)”在上一個(gè)任務(wù)處理和下一個(gè)任務(wù)處理的空檔中，利用WPF 的消息機(jī)制將消息傳遞到當(dāng)前窗口進(jìn)行處理，保證UI 線(xiàn)程及時(shí)響應(yīng).

2.3 使用WPF 中Dispatcher 實(shí)現(xiàn)任務(wù)拆分實(shí)時(shí)更新UI 線(xiàn)程

WPF 對(duì)應(yīng)用程序中產(chǎn)生的消息使用DispatcherOperation 進(jìn)行了封裝，這種封裝暴露了消息的優(yōu)先級(jí)Priority，定義了DispatcherOperation 消息的結(jié)束事件和取消事件.通過(guò)Dispatcher 對(duì)象創(chuàng)建消息、處理窗口消息形成消息產(chǎn)生到消費(fèi)的閉環(huán)，這就為解決UI 線(xiàn)程阻塞提供了可能性.具體做法如下：

步驟1：開(kāi)發(fā)者調(diào)用Dispatcher 的Invoke 或BeginInvoke，發(fā)送DispatcherOperation 消息，確定消息的Priority 級(jí)別.

步驟2：該DispatcherOperation 消息加入到DispatcherOperation 消息隊(duì)列中，也就是之前所說(shuō)的Message Queue 中.

步驟3：對(duì)應(yīng)的隱藏窗口收到Dispatcher-Operation 消息，按優(yōu)先級(jí)執(zhí)行該消息中包含的任務(wù).

步驟4：UI 線(xiàn)程更新.

根據(jù)這一過(guò)程分析得到，在拆分任務(wù)時(shí)使用Dispatcher 向系統(tǒng)消息隊(duì)列發(fā)送任務(wù)消息，能夠保證UI 線(xiàn)程及時(shí)更新，運(yùn)行過(guò)程不阻塞.

2.4 使用Dispatcher 對(duì)象的Invoke 和Begin‐Invoke 解決UI 線(xiàn)程更新問(wèn)題

Dispatcher 對(duì)象給開(kāi)發(fā)者解決UI 線(xiàn)程阻塞帶來(lái)了可能性，Dispatcher 提供了Invoke 和BeginInvoke 方法，使用這兩個(gè)方法向Dispatcher-Operation 的消息隊(duì)列發(fā)送消息，一方面可以保證在UI 線(xiàn)程中進(jìn)行任務(wù)拆分并及時(shí)更新UI 線(xiàn)程，另一方面也可以保證子線(xiàn)程完成耗時(shí)任務(wù)后發(fā)送消息回到UI 線(xiàn)程，更新UI 線(xiàn)程.這兩個(gè)方法的具體描述如下：

（1）Invoke 的方法簽名及使用場(chǎng)景

object Invoke（Delegate method，object［］args）；

參數(shù)1method 是一個(gè)委托類(lèi)型，可以理解為是一個(gè)方法的地址，表示發(fā)送到Dispatcher-Operation 消息隊(duì)列中的一個(gè)任務(wù)方法；參數(shù)2args 是這個(gè)方法調(diào)用時(shí)傳入的參數(shù)值，這樣就將一個(gè)要執(zhí)行的任務(wù)傳遞給Windows 消息機(jī)制處理.

Invoke 方法用于同步處理場(chǎng)景，當(dāng)用戶(hù)需要等待方法執(zhí)行返回結(jié)果才能繼續(xù)往下執(zhí)行時(shí)采用Invoke 方法，它可以保證消息傳遞過(guò)程中消息保持一定順序被執(zhí)行.但是如果該消息中含有較大執(zhí)行任務(wù)，也就是該委托對(duì)應(yīng)的方法中執(zhí)行的程序耗時(shí)比較長(zhǎng)時(shí)，會(huì)造成線(xiàn)程阻塞.

（2）BeginInvoke 的方法簽名及使用場(chǎng)景

IAsyncResultBeginInvoke（Delegate method，object［］args）；

參數(shù)的表達(dá)意思同Invoke 方法.參數(shù)1 表示委托，參數(shù)2 表示方法執(zhí)行時(shí)傳遞的參數(shù)值.不同的是該方法用于異步處理場(chǎng)景，當(dāng)用戶(hù)不需要等待method 參數(shù)方法執(zhí)行完畢就繼續(xù)往下執(zhí)行其他程序時(shí)，可以采用該方法.它雖然不能保證消息按順序地執(zhí)行完成，但是可以保證程序很好的性能，從而提供給用戶(hù)較好的體驗(yàn).

對(duì)于使用BeginInvoke 方法產(chǎn)生消息的亂序，可以通過(guò)在進(jìn)行參數(shù)傳遞時(shí)提供時(shí)間戳來(lái)標(biāo)記消息的先后順序.然后通過(guò)定時(shí)器定時(shí)獲取一組已經(jīng)有序的消息并執(zhí)行它們，為了保證性能問(wèn)題，需要通過(guò)多輪測(cè)試最終選取定時(shí)器的間隔時(shí)間和一組消息的組大小.

3 多UI 線(xiàn)程并發(fā)阻塞問(wèn)題的解決方案

3.1 多UI 線(xiàn)程并發(fā)阻塞問(wèn)題的實(shí)驗(yàn)設(shè)計(jì)

為了方便展示實(shí)驗(yàn)過(guò)程，建立一個(gè)數(shù)據(jù)采集系統(tǒng)，設(shè)置兩個(gè)終端持續(xù)不斷地將數(shù)據(jù)發(fā)送到程序主界面，接收方軟件主界面通過(guò)兩個(gè)區(qū)域的UI 可視化控件來(lái)展示這些由終端1 和終端2 發(fā)出的數(shù)據(jù).為了方便觀(guān)察效果，這里將數(shù)據(jù)以點(diǎn)的形式繪制在界面上.具體場(chǎng)景結(jié)構(gòu)關(guān)系如圖2 所示.

圖2 多終端數(shù)據(jù)展示過(guò)程

終端1 持續(xù)不斷地將數(shù)據(jù)發(fā)送到區(qū)域1控件，區(qū)域1 持續(xù)不斷地將這些數(shù)據(jù)以點(diǎn)的形式繪制在區(qū)域1 的位置；終端2 持續(xù)不斷地將數(shù)據(jù)發(fā)送到區(qū)域2 控件，區(qū)域2 持續(xù)不斷地將這些數(shù)據(jù)以點(diǎn)的形式繪制在區(qū)域2 的位置.問(wèn)題場(chǎng)景中，終端與程序之間的通信是建立在網(wǎng)絡(luò)環(huán)境中，終端需要知道程序所在服務(wù)器的IP 地址，程序需要知道終端的唯一標(biāo)識(shí)，讓服務(wù)器程序能清楚知道是誰(shuí)發(fā)送過(guò)來(lái)的.實(shí)驗(yàn)過(guò)程中發(fā)現(xiàn)存在兩個(gè)問(wèn)題.

（1）兩個(gè)終端的數(shù)據(jù)展示工作使用單UI線(xiàn)程將無(wú)法完成，必須為每一區(qū)域內(nèi)的數(shù)據(jù)展示過(guò)程建立獨(dú)立的UI 線(xiàn)程去處理數(shù)據(jù)繪制工作，兩個(gè)終端需要建立兩個(gè)UI 線(xiàn)程.

（2）終端數(shù)據(jù)是通過(guò)循環(huán)不斷向外發(fā)出的，如果將這些點(diǎn)直接繪制在UI 控件上，UI線(xiàn)程會(huì)立即造成阻塞.實(shí)驗(yàn)時(shí)看到的畫(huà)面將是所有消息發(fā)送完畢，這些點(diǎn)一次展示到UI界面上，這與實(shí)時(shí)展示數(shù)據(jù)點(diǎn)是不相符的.

3.2 解決創(chuàng)建多UI 線(xiàn)程的問(wèn)題

WPF 開(kāi)發(fā)框架提供了VisualTarget 類(lèi)給程序創(chuàng)建多UI 線(xiàn)程帶來(lái)了可能性，創(chuàng)建多UI 線(xiàn)程的好處就是為每一個(gè)UI 線(xiàn)程建立自己的消息循環(huán)隊(duì)列，每個(gè)UI 控件可以在自己的消息循環(huán)隊(duì)列中使用GetMessage（）獲取消息，相互不干擾，根據(jù)前面問(wèn)題場(chǎng)景的模擬，可以建立兩個(gè)UI 線(xiàn)程，以下是使用VisualTarget 類(lèi)創(chuàng)建多UI 線(xiàn)程的步驟.

步驟1：創(chuàng)建一個(gè)自定義類(lèi)繼承FrameworkElement，其目的是建立新UI 線(xiàn)程中控件的宿主，將新的UI 線(xiàn)程中的UI 控件加入到當(dāng)前UI 控件的可視化樹(shù)中.

步驟2：實(shí)例化剛剛創(chuàng)建的可視化宿主類(lèi)，將WPF 框架提供的HostVisual 實(shí)例化后加入其中，并將可視化宿主類(lèi)實(shí)例加入到當(dāng)前UI 控件可視化樹(shù)中.

步驟3：建立子線(xiàn)程，在子線(xiàn)程中創(chuàng)建每個(gè)區(qū)域繪制數(shù)據(jù)點(diǎn)的UI 控件，這里選擇WPF框架中的InkCanvas 控件，并使用VisualTarget類(lèi)創(chuàng)建一個(gè)實(shí)例，將HostVisual 實(shí)例加入其中，這樣就將子線(xiàn)程中UI 控件與可視化樹(shù)中的宿主建立了聯(lián)系，在WPF 中每一個(gè)UI 控件必須在可視化樹(shù)中掛載才可以顯示.

步驟4：將創(chuàng)建的線(xiàn)程設(shè)置為單線(xiàn)程單元狀態(tài)，也就是讓當(dāng)前線(xiàn)程可以建立獨(dú)立消息循環(huán)隊(duì)列.

步驟5：重復(fù)上面步驟，創(chuàng)建第二個(gè)UI 線(xiàn)程，至此兩個(gè)UI 線(xiàn)程創(chuàng)建完畢.

3.3 解決多UI 線(xiàn)程阻塞問(wèn)題

根據(jù)之前實(shí)驗(yàn)結(jié)論可以知道使用循環(huán)方式在InkCanvas 控件上展示數(shù)據(jù)點(diǎn)，會(huì)出現(xiàn)線(xiàn)程阻塞狀態(tài)，直接導(dǎo)致所有數(shù)據(jù)收集完畢后所有數(shù)據(jù)點(diǎn)一次性展示，給用戶(hù)造成的視覺(jué)感受就是沒(méi)有中間過(guò)程，要么沒(méi)有數(shù)據(jù)點(diǎn)，要么一次將一萬(wàn)個(gè)點(diǎn)一次展示，中間過(guò)程界面是假死狀態(tài).要想解決UI 線(xiàn)程阻塞問(wèn)題就必須 引 入Dispatcher 的Invoke 和BeginInvoke 方法.通過(guò)前述分析，可以知道Invoke 方法對(duì)于數(shù)據(jù)量大時(shí)，也會(huì)造成當(dāng)前線(xiàn)程阻塞，使用BeginInvoke 方法則會(huì)造成執(zhí)行亂序，這里可以采用將兩種方法結(jié)合的方式來(lái)處理，將每次執(zhí)行BeginInvoke 方法之間的間隔時(shí)間稍微增大，降低亂序發(fā)生的可能性，將數(shù)據(jù)累積到一個(gè)小批量后使用Invoke 方法執(zhí)行，保證順序的正確性.所以，在外側(cè)循環(huán)使用BeginInvoke 方法，在內(nèi)側(cè)循環(huán)使用Invoke，降低Invoke循環(huán)執(zhí)行的次數(shù)，例如100 以?xún)?nèi)，因?yàn)閿?shù)字過(guò)大執(zhí)行時(shí)間過(guò)長(zhǎng)會(huì)造成線(xiàn)程阻塞.

3.4 實(shí)驗(yàn)效果

通過(guò)使用VisualTarget 創(chuàng)建了兩個(gè)UI 線(xiàn)程，并且在每一個(gè)UI 線(xiàn)程中建立展示數(shù)據(jù)的InkCanvas，解決了多線(xiàn)程創(chuàng)建和數(shù)據(jù)展示問(wèn)題；通過(guò)使用Dispatcher 的Invoke 和BeginInvoke方法，利用WPF 消息機(jī)制很好地解決了大量數(shù)據(jù)處理造成多UI 線(xiàn)程阻塞的問(wèn)題.最終可以看到圖3 效果.

圖3 數(shù)據(jù)點(diǎn)展示過(guò)程

圖3 中（a）（b）（c）呈現(xiàn)了程序執(zhí)行的動(dòng)態(tài)過(guò)程.點(diǎn)擊按鈕后，開(kāi)始收集數(shù)據(jù)，數(shù)據(jù)點(diǎn)展示是動(dòng)態(tài)變化的，并且是左右兩個(gè)區(qū)域同時(shí)展示，展示過(guò)程中UI 界面按鈕是可以點(diǎn)擊的狀態(tài)，表示兩個(gè)UI 線(xiàn)程并沒(méi)有阻塞.

4 結(jié)語(yǔ)

UI 線(xiàn)程阻塞問(wèn)題是軟件開(kāi)發(fā)過(guò)程中處理用戶(hù)體驗(yàn)問(wèn)題的關(guān)鍵，在WPF 開(kāi)發(fā)框架中可以利用Windows 消息機(jī)制很好地處理UI 線(xiàn)程阻 塞問(wèn)題，WPF 提供了Dispatcher 的Invoke 和BeginInvoke 方法，可以使用這兩種方法向Windows 消息隊(duì)列發(fā)送信息更新UI 線(xiàn)程.同時(shí)，在多UI 線(xiàn)程場(chǎng)景中，可以利用VisualTarget 和HostVisual 建立多UI 線(xiàn)程控件的宿主，將多個(gè)UI 線(xiàn)程中的控件連接到同一個(gè)WPF 可視化樹(shù)中，再運(yùn)用Windows 消息機(jī)制解決多UI 線(xiàn)程阻塞問(wèn)題.該解決方案優(yōu)化了多UI 線(xiàn)程高并發(fā)訪(fǎng)問(wèn)的處理效率，即使在并發(fā)處理的任務(wù)較大時(shí)，也能通過(guò)“拆分任務(wù)”很好地解決多UI 線(xiàn)程的阻塞問(wèn)題，大大改善和提升了應(yīng)用軟件的用戶(hù)體驗(yàn).