當(dāng)我們處理一些長(zhǎng)線的調(diào)用時(shí)，經(jīng)常會(huì)導(dǎo)致界面停止響應(yīng)或者IIS線程占用過多等問題，這個(gè)時(shí)候我們需要更多的是用異步編程來修正這些問題，但是通常 都是說起來容易做起來難，誠(chéng)然異步編程相對(duì)于同步編程來說，它是一種完全不同的編程思想，對(duì)于習(xí)慣了同步編程的開發(fā)者來說，在開發(fā)過程中難度更大，可控性 不強(qiáng)是它的特點(diǎn)。

在.NET Framework5.0種，微軟為我們系統(tǒng)了新的語言特性，讓我們使用異步編程就像使用同步編程一樣相近和簡(jiǎn)單，本文中將會(huì)解釋以前版本的Framework中基于回調(diào)道德異步編程模型的一些限制以及新型的API如果讓我們簡(jiǎn)單的做到同樣的開發(fā)任務(wù)。

為什么要異步

一直以來，使用遠(yuǎn)程資源的編程都是一個(gè)容易造成困惑的問題，不同于“本地資源”，遠(yuǎn)程資源的訪問總會(huì)有很多意外的情況，網(wǎng)絡(luò)環(huán)境的不穩(wěn)定機(jī)器服務(wù)端的故障，會(huì)造成很多程序員完 全不可控的問題，所以這也就要求程序員需要更多的去保護(hù)遠(yuǎn)程資源的調(diào)用，管理調(diào)用的取消、超市、線程的等待以及處理線程長(zhǎng)時(shí)間沒響應(yīng)的情況等。而 在.NET中我們通常忽略了這些挑戰(zhàn)，事實(shí)上我們會(huì)有多種不用的模式來處理異步編程，比如在處理IO密集型操作或者高延遲的操作時(shí)候不組測(cè)線程，多數(shù)情況 我們擁有同步和異步兩個(gè)方法來做這件事。可是問題在于當(dāng)前的這些模式非常容易引起混亂和代碼錯(cuò)誤，或者開發(fā)人員會(huì)放棄然后使用阻塞的方式去開發(fā)。

而在如今的.NET中，提供了非常接近于同步編程的編程體驗(yàn)，不需要開發(fā)人員再去處理只會(huì)在異步編程中出現(xiàn)的很多情況，異步調(diào)用將會(huì)是清晰的且不透明的，而且易于和同步的代碼進(jìn)行組合使用。

過去糟糕的體驗(yàn)

最好的理解這種問題的方式是我們最常見的一種情況：用戶界面只擁有一個(gè)線程所有的工作都運(yùn)行在這個(gè)線程上，客戶端程序不能對(duì)用戶的鼠標(biāo)時(shí)間做出反 應(yīng)，這很可能是因?yàn)閼?yīng)用程序正在被一個(gè)耗時(shí)的操作所阻塞，這可能是因?yàn)榫€程在等待一個(gè)網(wǎng)絡(luò)ID或者在做一個(gè)CPU密集型的計(jì)算，此時(shí)用戶界面不能獲得運(yùn)行 時(shí)間，程序一直處于繁忙的狀態(tài)，這是一個(gè)非常差的用戶體驗(yàn)。

很多年來，解決這種問題的方法都是做異步花的調(diào)用，不要等待響應(yīng)，盡快的返回請(qǐng)求，讓其他事件可以同時(shí)執(zhí)行，只是當(dāng)請(qǐng)求有了最終反饋的時(shí)候通知應(yīng)用程序讓客戶代碼可以執(zhí)行指定的代碼。

而問題在于：異步代碼完全毀掉了代碼流程，回調(diào)代理解釋了之后如何工作，但是怎么在一個(gè)while循環(huán)里等待？一個(gè)if語句？一個(gè)try塊或者一個(gè)using塊？怎么去解釋“接下來做什么”？

看下面的一個(gè)例子：

public int SumPageSizes(IList<Uri> uris) 
        { 
            int total = 0; 
            foreach (var uri in uris) 
            { 
                txtStatus.Text = string.Format("Found {0} bytes...", total); 
                var data = new WebClient().DownloadData(uri); 
                total += data.Length; 
            } 
            txtStatus.Text = string.Format("Found {0} bytes total", total); 
            return total; 
        } 

這個(gè)方法從一個(gè)uri列表里下載文件，統(tǒng)計(jì)他們的大小并且同時(shí)更新狀態(tài)信息，很明顯這個(gè)方法不屬于UI線程因?yàn)樗枰ㄙM(fèi)非常長(zhǎng)的時(shí)間來完成，這樣它會(huì)完全的掛起UI，但是我們又希望UI能被持續(xù)的更新，怎么做呢？

我們可以創(chuàng)建一個(gè)后臺(tái)編程，讓它持續(xù)的給UI線程發(fā)送數(shù)據(jù)來讓UI來更新自身，這個(gè)看起來是很浪費(fèi)的，因?yàn)檫@個(gè)線程把大多時(shí)間花在等下和下載上，但 是有的時(shí)候，這正是我們需要做的。在這個(gè)例子中，WebClient提供了一個(gè)異步版本的DownloadData方法— DownloadDataAsync，它會(huì)立即返回，然后在DownloadDataCompleted后觸發(fā)一個(gè)事件，這允許用戶寫一個(gè)異步版本的方法 分割所要做的事，調(diào)用立即返回并完成接下來的UI線程上的調(diào)用，從而不再阻塞UI線程。下面是第一次嘗試：

public void SumpageSizesAsync(IList<Uri> uris) 
        { 
            SumPageSizesAsyncHelper(uris.GetEnumerator(), 0); 
        } 
 
        public void SumPageSizesAsyncHelper(IEnumerator<Uri> enumerator, int total) 
        { 
            if (enumerator.MoveNext()) 
            { 
                txtStatus.Text = string.Format("Found {0} bytes...", total); 
                var client = new WebClient(); 
                client.DownloadDataCompleted += (sender,e)=>{ 
                    SumPageSizesAsyncHelper(enumerator, total + e.Result.Length); 
                }; 
                client.DownloadDataAsync(enumerator.Current); 
            } 
            else 
            { 
                txtStatus.Text = string.Format("Found {0} bytes total", total); 
            } 
        } 

然后這依然是糟糕的，我們破壞了一個(gè)整潔的foreach循環(huán)并且手動(dòng)獲得了一個(gè)enumerator，每一個(gè)調(diào)用都創(chuàng)建了一個(gè)事件回調(diào)。代碼用遞歸取代了循環(huán)，這種代碼你應(yīng)該都不敢直視了吧。不要著急，還沒有完 。

原始的代碼返回了一個(gè)總數(shù)并且顯示它，新的一步版本在統(tǒng)計(jì)還沒有完成之前返回給調(diào)用者。我們?cè)趺礃硬趴梢缘玫揭粋€(gè)結(jié)果返回給調(diào)用者，答案是：調(diào)用者必須支持一個(gè)回掉，我們可以在統(tǒng)計(jì)完成之后調(diào)用它。

然而異常怎么辦？原始的代碼并沒有關(guān)注異常，它會(huì)一直傳遞給調(diào)用者，在異步版本中，我們必須擴(kuò)展回掉來讓異常來傳播，在異常發(fā)生時(shí)，我們不得不明確的讓它傳播。

最終，這些需要將會(huì)進(jìn)一步讓代碼混亂：

public void SumpageSizesAsync(IList<Uri> uris,Action<int,Exception> callback) 
        { 
            SumPageSizesAsyncHelper(uris.GetEnumerator(), 0, callback); 
        } 
 
        public void SumPageSizesAsyncHelper(IEnumerator<Uri> enumerator, int total,Action<int,Exception> callback) 
        { 
            try 
            { 
                if (enumerator.MoveNext()) 
                { 
                    txtStatus.Text = string.Format("Found {0} bytes...", total); 
                    var client = new WebClient(); 
                    client.DownloadDataCompleted += (sender, e) => 
                    { 
                        SumPageSizesAsyncHelper(enumerator, total + e.Result.Length,callback); 
                    }; 
                    client.DownloadDataAsync(enumerator.Current); 
                } 
                else 
                { 
                    txtStatus.Text = string.Format("Found {0} bytes total", total); 
                    enumerator.Dispose(); 
                    callback(total, null); 
                } 
 
            } 
            catch (Exception ex) 
            { 
                enumerator.Dispose(); 
                callback(0, ex); 
            } 
 
        } 

當(dāng)你再看這些代碼的時(shí)候，你還能立馬清楚的說出這是什么JB玩意嗎？

恐怕不能，我們開始只是想和同步方法那樣只是用一個(gè)異步的調(diào)用來替換阻塞的調(diào)用，讓它包裝在一個(gè)foreach循環(huán)中，想想一下試圖去組合更多的異步調(diào)用或者有更復(fù)雜的控制結(jié)構(gòu)，這不是一個(gè)SubPageSizesAsync的規(guī)模能解決的。

我們的真正問題在于我們不再可以解釋這些方法里的邏輯，我們的代碼已經(jīng)完全無章可循。異步代碼中很多的工作讓整件事情看起來難以閱讀并且似乎充滿了BUG。

#p#

一個(gè)新的方式

如今，我們擁有了一個(gè)新的功能來解決上述的問題，異步版本的代碼將會(huì)如下文所示：

public async Task<int> SumPageSizesAsync(IList<Uri> uris) 
        { 
            int total = 0; 
            foreach (var uri in uris) 
            { 
                txtStatus.Text = string.Format("Found {0} bytes...", total); 
                var data = await new WebClient().DownloadDataTaskAsync(uri); 
                total += data.Length; 
            } 
            txtStatus.Text = string.Format("Found {0} bytes total", total); 
            return total; 
        } 

除了添加的高亮的部分，上文中的代碼與同步版本的代碼非常相似,代碼的流程也從未改變，我們也沒有看到任何的回調(diào)，但是這并不代表實(shí)際上沒有回調(diào)操作，編譯器會(huì)搞定這些工作，不再需要您去關(guān)心。

異步的方法是用了Task<int>替代了原來返回的Int類型，Task和Task<T>是在如今的framework提供的，用來代表一個(gè)正在運(yùn)行的工作。

異步的方法沒有額外的方法，依照慣例為了區(qū)別同步版本的方法，我們?cè)诜椒筇砑覣sync作為新的方法名。上文中的方法也是異步的，這表示方法體會(huì)讓編譯器區(qū)別對(duì)待，允許其中的一部分將會(huì)變成回調(diào)，并且自動(dòng)的創(chuàng)建Task<int>作為返回類型。

關(guān)于這個(gè)方法的解釋：在方法內(nèi)部，調(diào)用另外一個(gè)異步方法DownloadDataTaskAsync，它快速的返回一個(gè) Task<byte[]>類型的變量，它會(huì)在下載數(shù)據(jù)完成以后被激活，到如前為止，在數(shù)據(jù)沒有完成之前，我們不想做任何事，所以我們使用 await來等待操作的完成。

看起來await關(guān)鍵字阻塞了線程直到task完成下載的數(shù)據(jù)可用，其實(shí)不然，相反它標(biāo)志了任務(wù)的回調(diào)，并且立即返回，當(dāng)這個(gè)任務(wù)完成之后，它會(huì)執(zhí)行回調(diào)。

Tasks

Task和Task<T>類型已經(jīng)存在于.NET Framework 4.0中，一個(gè)Task代表一個(gè)進(jìn)行時(shí)的活動(dòng)，它可能是一個(gè)運(yùn)行在單獨(dú)線程中的一個(gè)CPU密集型的工作或者一個(gè)IO操作，手動(dòng)的創(chuàng)建一個(gè)不工作在單獨(dú)線程的任務(wù)也是非常容易的：

static Task ReadFileAsync(string filePath,out byte[] buffer) 
        { 
            Stream stream = File.Open(filePath, FileMode.Open); 
            buffer = new byte[stream.Length]; 
            var tcs = new TaskCompletionSource<double>(); 
            stream.BeginRead(buffer, 0, buffer.Length, arr => 
            { 
                var length = stream.EndRead(arr); 
                tcs.SetResult(stream.Length); 
            }, null); 
            return tcs.Task; 
        } 
 
一旦創(chuàng)建了一個(gè)TaskCompletionSource對(duì)象，你就可以返回與它關(guān)聯(lián)的Task對(duì)象，問相關(guān)的工作完成后，客戶代碼才得到最終的結(jié)果，這時(shí)Task沒有占據(jù)自己的線程。 
 
如果實(shí)際任務(wù)失敗，Task從樣可以攜帶異常并且向上傳播，如果使用await將觸發(fā)客戶端代碼的異常： 
 
static async void ReadAssignedFile() 
        { 
            byte[] buffer; 
            try 
            { 
                double length = await ReadFileAsync("SomeFileDoNotExisted.txt", out buffer); 
            } 
            catch (Exception ex) 
            { 
                Console.WriteLine(ex.Message); 
            } 
        } 
 
        static Task<double> ReadFileAsync(string filePath,out byte[] buffer) 
        { 
            Stream stream = File.Open(filePath, FileMode.Open); 
            buffer = new byte[stream.Length]; 
            var tcs = new TaskCompletionSource<double>(); 
            stream.BeginRead(buffer, 0, buffer.Length, arr => 
            { 
                try 
                { 
                    var length = stream.EndRead(arr); 
                    tcs.SetResult(stream.Length); 
                } 
                catch (IOException ex) 
                { 
                    tcs.SetException(ex); 
                } 
            }, null); 
            return tcs.Task; 
        } 

基于任務(wù)的異步編程模型

上文中解釋了異步方法應(yīng)該是的樣子-Task-based asynchronous Pattern(TAP)，上文中異步的體現(xiàn)只需要一個(gè)調(diào)用方法和異步異步方法，后者返回一個(gè)Task或者Task<T>。

下文中將介紹一些TAP中的約定，包括怎么處理“取消”和“進(jìn)行中”，我們將進(jìn)一步講解基于任務(wù)的編程模型。

Async和await

理解async方法不運(yùn)行在自己的線程是非常重要的，事實(shí)上，編寫一個(gè)async方法但是沒有任何await的話，它就將會(huì)是一個(gè)不折不扣的同步方法：

static async Task<int> TenToSevenAsync() 
{ 
    await Task.Delay(3000); 
    return 7; 
} 

假如你調(diào)用這個(gè)方法，將會(huì)阻塞線程10秒后返回7，這也許不是你期望的，在VS中也將得到一個(gè)警告，因?yàn)檫@可能永遠(yuǎn)不是想要的結(jié)果。

只有一個(gè)async方法運(yùn)行到一個(gè)await語句時(shí)，它才立即把控制權(quán)返回給調(diào)用方，然而只有當(dāng)?shù)却娜蝿?wù)完成之后，它才會(huì)真正的返回結(jié)果，這意味著你需要確保async方法中的代碼不會(huì)做過多的任務(wù)或者阻塞性能的調(diào)用。下面的實(shí)例才是你所期望的效果

static async Task<int> TenToSevenAsync() 
{ 
    await Task.Delay(3000); 
    return 7; 
} 

Task.Delay實(shí)際上是異步版本的Tread,Sleep，它返回一個(gè)Task,這個(gè)Task將會(huì)在指定的時(shí)間內(nèi)完成。

時(shí)間處理程序和無返回值的異步方法

異步方法可以從其他異步方法使用await創(chuàng)建，但是異步在哪里結(jié)束？

在客戶端程序中，通常的回答是異步方法由事件發(fā)起，用戶點(diǎn)擊一個(gè)按鈕，一個(gè)異步方法被激活，直到它完成，事件本身并不關(guān)系方法何時(shí)執(zhí)行完成。這就是通常所說的“發(fā)后既忘”

為了適應(yīng)這種模式，異步方法通常明確的被設(shè)計(jì)為“發(fā)后既忘”-使用void作為返回值替代Task<TResult>類型，這就讓方法 可以直接作為一個(gè)事件處理程序。當(dāng)一個(gè)void saync的方法執(zhí)行時(shí)，沒有Task被返回，調(diào)用者也無法追蹤調(diào)用是否完成。

private async void someButton_Click(object sender, RoutedEventArgs e) 
{ 
    someButton.IsEnabled = false; 
    await SumPageSizesAsync(GetUrls())); 
    someButton.IsEnabled = true; 
} 

結(jié)束語

越寫到最后，越不說人話啦。。。。。