如何解決窗體假死
概述：在之前的《創建無阻塞的異步調用》中，已經介紹過異步調用的編寫步驟和實施原理。異步調用是CLR爲開發者提供的一種重要的編程手段，它也是構建高性能、可伸縮應用程序的關鍵。在多核CPU越來越普及的今天，異步編程允許使用非常少的線程執行很多操作。
引言
在之前的《創建無阻塞的異步調用》中，已經介紹過異步調用的編寫步驟和實施原理。異步調用是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、迅雷等軟件的載入動畫配合，效果會更理想。
歡迎任何形式的轉載，但請務必註明出處，尊重他人勞動成果
轉載請註明：文章轉載自：慧都控件網 [http://www.evget.com/]
本文地址：http://www.evget.com/zh-CN/info/catalog/16039.html