引言

　　在之前的《創建無阻塞的異步調用》中，已經介紹過異步調用的編寫步驟和實施原理。異步調用是CLR為開發者提供的一種重要的編程手段，它也是構建高性能、可伸縮應用程序的關鍵。在多核CPU越來越普及的今天，異步編程允許使用非常少的線程執行很多操作。我們通常使用異步完成許多計算型、IO型的復雜、耗時操作，去取得我們的應用程序運行所需要的一部分數據。在取得這些數據后，我們需要將它們綁定在UI中呈現。當數據量偏大時，我們會發現窗體變成了空白面板。此時如果用鼠標點擊，窗體標題將會出現”失去響應”的字樣，而實際上UI線程仍在工作著，這對用戶來說是一種極度糟糕的體驗。如果你希望了解其中的原因(并不復雜:))，并徹底解決該問題，那么花時間讀完此文也許是個不錯的選擇。

　　一般來說，窗體阻塞分為兩種情況。一種是在UI線程上調用耗時較長的操作，例如訪問數據庫，這種阻塞是UI線程被占用所導致，可以通過delegate.BeginInvoke的異步編程解決；另一種是窗體加載大批量數據，例如向ListView、DataGridView等控件中添加大量的數據。本文主要探討后一種阻塞。

基礎理論

　　這部分簡單介紹CLR對跨線程UI訪問的處理。作為基礎內容，相信大部分.NET開發者對它并不陌生，讀者可根據實際情況略過此處。

控件的線程安全檢測

　　在傳統的窗體編程中，UI中的控件元素與其他工作線程互相隔離，每次我們訪問一個UI控件，實際上都是在UI線程中進行。如果嘗試在其他線程中訪問控件，CLR針對不同的.NET Framework版本，會有不同的處理。在Framework1.x中，CLR允許應用程序以跨線程的方式運行，而在Framework2.0及以后版本中，System.Windows.Form.Control新增了CheckForIllegalCrossThreadCalls屬性，它是一個可讀寫的bool常量，標記我們是否需要對非UI線程對控件的調用做出檢測。如果指定true，當以其他線程訪問UI，CLR會跑出一個”InvalidOperationException:線程間操作無效，從不是創建控件***的線程訪問它”；如果為false，則不對該錯誤線程的調用進行捕獲，應用程序依然運行。

　　在Framework1.x版本中，這個值默認是false。問什么之后的版本會加入這個屬性來約束我們的UI呢？實際上官方對此的解釋是當有多個并發線程嘗試對UI進行讀寫時，容易造成線程爭用資源帶來的死鎖。所以，CLR默認不允許以非UI線程訪問控件。

　　然而，我們常常需要在窗體中使用異步線程來處理一些操作，例如IO和Socket通訊等。這時跨線程的UI訪問又是必須的，對此，.NET給我們的補充方案就是Control的Invoke和BeginInvoke。

Control的Invoke和BeginInvoke

對于這兩個方法，首先我們要有以下的認識：

1.Control.Invoke，Control.BeginInvoke和delegate.Invoke，delegate.BeginInvoke是不同的。
2.Control.Invoke中的委托方法，執行在主線程，也就是我們的UI線程。而Control.BeginInvoke從命名上來看雖然具有異步調用的特征(Begin)，但也仍然執行在UI線程。
 3.如果在UI線程中直接調用Invoke和BeginInvoke，數據量偏大時，依然會造成UI的假死。

　　有很多開發者在初次接觸這兩個函數時，很容易就將它們同異步聯系起來、有些人會認為他們是獨立于UI線程之外的工作線程，實際上，他們都被這兩個函數的命名所蒙蔽了。如果以傳統調用異步的方式，直接調用Control.BeginInvoke，與同步函數的執行無異，UI線程還是會處理所有辛苦的操作，造成我們的應用程序阻塞。

　　Control.Invoke的調用模型很明確：在UI線程中以代碼順序同步執行，因此，拋開工作線程調用UI元素的干擾，我們可以將Control.Invoke視為同步，本文不做過多介紹。

　　很多開發者在接觸異步后，再來處理窗體假死的問題，很容易想當然的將Control.BeginInvoke視為WinForm封裝的異步。所以我們重點關注這個方法。

體驗BeginInvoke

　　前面說過，BeginInvoke除了命名上來看像異步，其實很多時候我們調用起來根本沒有異步的”非阻塞”特性，我用下面這個例子簡單的嘗試一次對BeginInvoke的調用。

　　如你所見，我現在創建了一個簡陋的Form，其中放置了一個Lable控件lable1,一個Button控件btn_Start，下面，開始code:

private void btn_Start_Click(object sender, EventArgs e)
{
// 儲存UI線程的標識符
int curThreadID = Thread.CurrentThread.ManagedThreadId;

new Thread((ThreadStart)delegate()
{
PrintThreadLog(curThreadID);
})
.Start();
}

private void PrintThreadLog(int mainThreadID)
{
// 當前線程的標識符
// A代碼塊
int asyncThreadID = Thread.CurrentThread.ManagedThreadId;

// 輸出當前線程的扼要信息，及與UI線程的引用比對結果
// B代碼塊
label1.BeginInvoke((MethodInvoker)delegate()
{
// 執行BeginInvoke內的方法的線程標識符
int curThreadID = Thread.CurrentThread.ManagedThreadId;

label1.Text = string.Format("Async Thread ID:{0},Current Thread ID:{1},Is UI Thread:{2}",
asyncThreadID, curThreadID, curThreadID.Equals(mainThreadID));
});

// 掛起當前線程3秒，模擬耗時操作
// C代碼塊
Thread.Sleep(3000);
}

　　這段代碼在新的線程中訪問了UI，所以我們使用了label1.BeginInvoke函數。新的線程中，我們取得了當前工作線程的線程標識符，也取得了BeginInvoke函數內的線程。然后，將它與UI線程的標志符作比對，將結果輸出于Label1控件上。最后，我們掛起當前工作線程3秒，用于模擬一些常見的耗時操作。

　　為了便于區分，我們將這段代碼分為A、B、C三個代碼塊。

運行結果：

我們能得到以下結論：

●PrintThreadLog函數主體(A、C代碼塊)執行在新的線程，它執行了不被BeginInvoke所包含的其他代碼。
●當我們調用了Control.BeginInvoke之后，線程調度權回歸到了UI線程。也就是說，BeginInvoke內部的代碼(B代碼塊)均執行在UI線程。
●在UI線程執行BeginInvok中封裝的代碼時，工作線程內的剩余代碼(C代碼塊)同時進行。它與BeginInvoke中的UI線程并行執行，互不干擾。
 ●由于Thread.Sleep(3000)是隔離在UI線程外的工作線程，因此這行代碼帶來的線程阻塞實際上阻塞了工作線程，不會給UI帶來任何影響。

Control.BeginInvoke的真正含義

　　既然Control.BeginInvoke其中的委托函數仍執行在UI線程內，那這個”異步”到底指的是什么？話題回到本文最初：我們在上文已經提到了”控件的線程安全檢測”概念，相信大家對這種工作線程內調用Control.BeginInvoke的做法已經太熟悉了。我們也提到了”CLR不喜歡工作線程調用UI元素”。微軟的決心如此之大，以至于CLR團隊在.NET Framework2.0中添加了CheckForIllegalCrossThreadCalls和Control.Invoke、Control.BeginInvoke方法。這是一次相當重大的改革，CLR團隊希望達到這樣的效果：

　　如果不申明CheckForIllegalCrossThreadCalls = false;這樣的”不安全”代碼，你就只能使用Control.Invoke和Control.BeginInvoke；而只要使用后兩者，不論它們的上下文運行環境是其它工作線程還是UI線程，它們封裝的代碼都會執行在UI線程內。所以，msdn對Control.BeginInvoke給出了這樣的解釋：在創建控件的基礎句柄所在線程上異步執行指定委托。

　　它的真正含義是：BeginInvoke所謂的異步，是相對于調用線程的異步，而不是相對于UI線程的異步。

　　CLR把Control.BeginInvoke(delegate method)中的異步函數執行在UI內，如果你像我上文那樣用新線程調用BeginInvoke，那么method相對于這個新線程內的其他函數是異步的。畢竟method執行在了UI線程，新線程立即回調，不必等待Control.BeginInvoke的完成。所以，這個后臺線程充分享受了”異步”的好處，不再阻塞，只是我們看不到而已；當然，如果你在BeginInvoke內執行一段耗時的代碼，無論是從遠程服務器獲取數據庫資料、IO讀取，還是在控件內加載一大批數據，UI線程還是阻塞的。

　　正如傳統的Delegate.BeginInvoke的異步工作線程取自于.NET線程池，Control.BeginInvoke的異步工作線程就是UI線程。

　　現在您明白兩種BeginInvoke的區別了嗎？

Control.Invoke、BeginInvoke與Windows消息

　　實際上，Invoke和BeginInvoke的原理是將調用的方法Marshal成消息，然后調用Win32Api的RegisterWindowMessage()向UI發送消息。我們使用Reflector，可以看到以下代碼：

Control.Invoke:

public object Invoke(Delegate method, params object[] args)
{
using (new MultithreadSafeCallScope())
{
return this.FindMarshalingControl().MarshaledInvoke(this, method, args, true);
}
}

Control.BeginInvoke:

[EditorBrowsable(EditorBrowsableState.Advanced)]
public IAsyncResult BeginInvoke(Delegate method, params object[] args)
{
using (new MultithreadSafeCallScope())
{
return (IAsyncResult)this.FindMarshalingControl().MarshaledInvoke(this, method, args, false);
}
}

　　在以上代碼中我們看到Control.Invoke和BeginInvoke的不同之處，在于調用MarshaledInvoke時，Invoke向最后一個參數傳遞了false，而BeginInvoke則是true。

MarshaledInvoke的結構是這樣的：

private object MarshaledInvoke(Control caller, Delegate method, object[] args, bool synchronous)

　　很明顯，最后一個參數synchronous表示是否按照同步處理。MarshaledInvoke內部這樣處理這個參數：

if (!synchronous)
{
return entry;
}
if (!entry.IsCompleted)
{
this.WaitForWaitHandle(entry.AsyncWaitHandle);
}

　　所以，BeginInvoke的處理就是直接回調，Invoke卻在等待異步函數執行完后，才繼續執行。

　　到此為止，Invoke和BeginInvoke的工作就結束了，其余的工作就是UI對消息的處理，它由Control的WndProc(ref Message m)來執行。消息處理到底會給我們的UI帶來什么樣的影響？接著來看Application.DoEvents()函數。

Application.DoEvents

　　Application.DoEvents()函數是WinForm編程中極為重要的函數，但實際編程中，大多數開發者極少調用它。如果您對這個函數缺乏了解，那很可能會在以后長期的編程中對“窗體假死”這樣的現象陷入迷惑。

　　當運行 Windows 窗體時，它將創建新窗體，然后該窗體等待處理事件。該窗體在每次處理事件時，均將處理與該事件關聯的所有代碼。所有其他事件在隊列中等待。當代碼處理事件時，應用程序不會響應。例如，如果將甲窗口拖到乙窗口之上，則乙窗口不會重新繪制。

　　如果在代碼中調用 DoEvents，則您的應用程序可以處理其他事件。 例如，如果您有向ListBox添加數據的窗體，并將 DoEvents 添加到代碼中，那么當將另一窗口拖到您的窗體上時，該窗體將重新繪制。如果從代碼中移除 DoEvents，那么在按鈕的單擊事件處理程序執行結束以前，您的窗體不會重新繪制。

　　因此，如果我們在窗體執行事件時，不處理消息隊列中的windows消息，窗體必然會失去響應。而上文已經介紹過，Control.Invoke和BeginInvoke都會向UI發送消息，造成UI對消息的處理，因此，這為我們解決窗體加載大量數據時的假死提供了思路。

解決方案

嘗試”無假死”

　　這次我們使用開發中出現頻率極高的ListView控件，體驗一次理想的”異步刷新”,窗體中有一個ListView控件命名為listView1,并將View設置為Detail，添加兩個ColumnHeader；一個Button命名為btn_Start，設計視圖如下：

開始code：

private readonly int Max_Item_Count = 10000;

private void button1_Click(object sender, EventArgs e)
{
new Thread((ThreadStart)(delegate()
{
for (int i = 0; i < Max_Item_Count; i++)
{
// 此處警惕值類型裝箱造成的"性能陷阱"
listView1.Invoke((MethodInvoker)delegate()
{
listView1.Items.Add(new ListViewItem(new string[]
{ i.ToString(), string.Format("This is No.{0} item", i.ToString()) }));
});
};
}))
.Start();
}

　　代碼運行后，你將會看到一個飛速滾動的ListView列表，在加載的過程中，列表以令人眼花繚亂的速度添加數據，此時你嘗試拉動滾動條，或者移動窗體，都會發現這次的效果與以往的”白板”、”假死”截然不同！這是一個令人欣喜的變化。

運行過程：

　　從我的截圖中可以看出，窗體在加載數據的過程中，依然繪制界面，并沒有出現”假死”。

　　如果上述代碼調用的是Control.BeginInvoke，程序會發生些奇怪的現象，想想是為什么？

好吧，到了現在，我們終于可以松了一口氣了，界面響應的問題已經被解決，一切美好。但是，這樣的窗體還是暴漏出兩個大問題：
1． 比起傳統加載，”無假死窗體”加載速度明顯減慢。
2． 加載數據過程中，窗體發生劇烈閃爍現象。

問題分析

　　我們在調用Control.Invoke時，強迫窗體處理消息，從而使界面得到了響應，同時也產生了一些副作用。其中之一就是消息處理使得窗體發生了在循環中發生了重繪，”閃爍”現象就是窗體重繪引發的，有過GDI+開發經驗的開發者應該比較熟悉。同時，每次調用Invoke都會使UI處理消息，也直接增加了控件對數據處理的時間成本，導致了性能問題。

　　對于”性能問題”，我并沒有什么解決方案(有自己見解的朋友歡迎提出)。有些控件(ListView、ListBox)具有BeginUpdate和EndUpdate函數，可以臨時掛起刷新，加快性能。但畢竟我們這里創建了一個會滾動的界面，這種數據的”動態加載”方式是前者無法比擬的。

　　對于”閃爍”，我先來解釋問題的原因。通常，控件的繪制包括兩個環節：擦出原對象與繪制新對象。首先windows發送一個消息，通知控件擦除原圖像，然后進行繪制。如果要在控件面板上以SolidBrush繪制，控件就會在其面板上直接繪制內容。當用戶改變了控件尺寸，Windows將會調用很多繪制回收操作，當每次回收和繪制發生時，由于”繪制”較”擦除”更為延后，才會給用戶帶來”閃爍”的感覺。以往我們為解決此類問題，往往需要在Control.WndProc中作出復雜的處理。而.NET Framework為我們提供了更為優雅的一種方案，那就是雙緩沖，我們直接調用它即可。

最終方案

1.新建Windows組件DBListView.cs,讓它繼承自ListView。
2.在控件中添加如下代碼： public DBListView()
{

// 打開控件的雙緩沖
SetStyle(ControlStyles.OptimizedDoubleBuffer | ControlStyles.AllPaintingInWmPaint, true);
}

將項目重新生成，然后從工具箱中拖出新增的組建DBListView到窗體上，命名為dbListView1，執行以下代碼： private void button1_Click(object sender, EventArgs e)
{
new Thread((ThreadStart)(delegate()
{
for (int i = 0; i < Max_Item_Count; i++)
{
// 此處警惕值類型裝箱造成的"性能陷阱"
dbListView1.Invoke((MethodInvoker)delegate()
{
dbListView1.Items.Add(new ListViewItem(new string[]
{ i.ToString(), string.Format("This is No.{0} item", i.ToString()) }));
});
};
}))
.Start();
} >

　　現在”閃爍”的問題是不是已經得到了解決？

　　在我們的實際應用中，這種加載數據引起的阻塞是很常見的，在用戶對界面性能關注度不高的情況下，使用本文介紹的方式處理這種阻塞是一種不錯的選擇，如果以類似IE8、迅雷等軟件的載入動畫配合，效果會更理想。