雖然 GCD 已經(jīng)出現(xiàn)過一段時間了，但不是每個人都明了其主要內(nèi)容。這是可以理解的；并發(fā)一直很棘手，而 GCD 是基于 C 的 API ，它們就像一組尖銳的棱角戳進(jìn) Objective-C 的平滑世界。我們將分兩個部分的教程來深入學(xué)習(xí) GCD 。
在這兩部分的系列中，第一個部分的將解釋 GCD 是做什么的，并從許多基本的 GCD 函數(shù)中找出幾個來展示。在第二部分，你將學(xué)到幾個 GCD 提供的高級函數(shù)。
本文翻譯自 http://www.raywenderlich.com/60749/grand-central-dispatch-in-depth-part-1
什么是GCD
GCD是libdispatch 的市場名稱，而libdispatch作為Apple的一個庫，為并發(fā)代碼在多核硬件（跑iOS或OSX）上執(zhí)行提供有力支持。它具有以下優(yōu)點(diǎn)：
- GCD能通過推遲昂貴計算任務(wù)并在后臺運(yùn)行他們來改善你的應(yīng)用的響應(yīng)性能
- GCD提供一個易于使用的并發(fā)模型而不僅僅是鎖和線程，以幫助我們避開并發(fā)陷進(jìn)。
- GCD具有常見模式（例如單例）上用更高性能的原語優(yōu)化你的代碼的潛在能力。
本教程假設(shè)你對Block合GCD有基礎(chǔ)了解。如果你對GCD完全陌生，先看看iOS上德多線程和GCD入門教程 學(xué)習(xí)其要領(lǐng)。
GCD術(shù)語
要理解GCD，你要熟悉與線程和并發(fā)相關(guān)的幾個概念。這兩者都可能模糊和微妙，所以在開始GCD之前先簡要地回顧以下它們。
Serial vs. Concurrent 串行 vs. 并行
這些術(shù)語描述當(dāng)任務(wù)相對于其它任務(wù)被執(zhí)行，任務(wù)串行執(zhí)行就是每次只有一個任務(wù)被執(zhí)行，任務(wù)并發(fā)執(zhí)行就是在同一時間可以有多個任務(wù)被執(zhí)行。
雖然這些術(shù)語被廣泛使用，本教程中你可以將任務(wù)設(shè)定為一個Objective-C的Block。不明白什么是Block?看看iOS5教程中的如何使用Block。實(shí)際上，你也可以在GCD上使用函數(shù)指針，但在大多數(shù)場景中，這實(shí)際上更難于使用。Block就是更加容易些！
Synchonous vs. Asynchronous 同步 vs. 異步
在GCD中，這些術(shù)語描述當(dāng)一個函數(shù)相對于另外一個任務(wù)完成，此任務(wù)是該函數(shù)要求GCD執(zhí)行的。一個同步函數(shù)只在完成了它預(yù)定的任務(wù)后才返回。
一個異步函數(shù)，剛好相反，會立即返回，預(yù)定的任務(wù)會完成但不會等它完成。因此，一個異步函數(shù)不會阻塞當(dāng)前線程去執(zhí)行下一個函數(shù)。
注意--當(dāng)你讀到同步函數(shù)“阻塞(Block)”當(dāng)前線程，或函數(shù)是一個“阻塞”函數(shù)或阻塞操作時，不要被搞糊涂了！動詞“阻塞”描述了函數(shù)如何影響它所在的線程而與名詞“代碼塊(Block)”沒有關(guān)系。代碼塊描述了用Objective-C編寫的一個匿名函數(shù)，它能定義一個任務(wù)并被提交到GCD。
譯者注：中文不會有這個問題，“阻塞”和“代碼塊”是兩個詞。
Critical Section 臨界區(qū)
就是一段代碼不能被并發(fā)執(zhí)行，也就是，兩個線程不能同時執(zhí)行這段代碼。這很常見，因?yàn)榇a去操作一個共享資源，例如一個變量若能被并發(fā)進(jìn)程訪問，那么它很肯能會變質(zhì)（譯者注：它的值不再可信）。
Race Condition 競態(tài)條件
這種狀況是指基于特定序列或時機(jī)的事件的軟件系統(tǒng)以不受控制的方式運(yùn)行的行為，例如程序的并發(fā)任務(wù)執(zhí)行的確切順序。競態(tài)條件可導(dǎo)致無法預(yù)測的行為，而不能通過代碼檢查立即發(fā)現(xiàn)。
Deadlock 死鎖
兩個（有時更多）東西--在大多數(shù)情況下,是線程--所謂的死鎖是指他們都卡住了，并等待對方完成或執(zhí)行其他操作。第一個不能完成是因?yàn)樗诘却诙€的完成。但第二個也不能完成，因?yàn)樗诘却谝粋€的完成。
Thread Safe 線程安全
線程安全的代碼能在多線程或并發(fā)任務(wù)中被安全調(diào)用，而不會導(dǎo)致任何問題（數(shù)據(jù)算壞，奔潰，等）。線程不安全的代碼在摸個時刻只能在一個上下文中運(yùn)行。一個線程安全代碼的例子是NSDictionary。你可以在同一時間在多個線程中使用它而不會有問題。另一方面，NSMutableDictionary就不是線程安全的，應(yīng)該保證一次只能有一個線程訪問它。
Context Switch 上下文切換
一個上下文切換指當(dāng)你在當(dāng)個進(jìn)程里切換執(zhí)行不同的線程時存儲與恢復(fù)執(zhí)行狀態(tài)的過程。這個過程在編寫多任務(wù)應(yīng)用時很普遍，但會帶來一些額外的開銷。
Concurrency vs. Parallelism 并發(fā)與并行
并發(fā)和并行通常被一起提到，所以值得花些時間解釋他們之間的區(qū)別。
并發(fā)代碼的不同部分可以“同步”執(zhí)行。然而，改怎樣發(fā)生或是否發(fā)生都決定于多系統(tǒng)。多核設(shè)備通過并行來同事執(zhí)行多個線程；然而，為了使單核設(shè)備也能實(shí)現(xiàn)這一點(diǎn)，他們必須先運(yùn)行一個線程，執(zhí)行一個上下文切換，然后運(yùn)行另一個線程或進(jìn)程。這通常發(fā)生得足夠快以致給我們并發(fā)執(zhí)行的錯覺，如下圖所示：
雖然你可以編寫代碼在GCD下并發(fā)執(zhí)行，但GCD會決定有多少并行的需求。并行要求并發(fā)，但并發(fā)并不能保證并行。
更深入的觀點(diǎn)是并發(fā)實(shí)際上是關(guān)于構(gòu)造。當(dāng)你在腦海中用GCD編寫代碼，你組織你的代碼來暴露同時運(yùn)行的多個工作片段，以及不能同時運(yùn)行的那些。如果你想深入此主題，看看這個由Rob Pike做的精彩的講座
Queues 隊列
GCD提供有dispatch queues來處理代碼塊，這些隊列管理提供給GCD的任務(wù)并用FIFO順序執(zhí)行這些任務(wù)。這就保證了第一個被添加到隊列里地任務(wù)回事隊列中第一個開始的任務(wù)，而第二個被添加的任務(wù)將第二個開始，如此知道隊列的終點(diǎn)。
所有的調(diào)度隊列（dispatch queues）自身都是線程安全的，你能從多個線程并行地訪問他們。當(dāng)你了解了調(diào)度隊列如何為自己代碼的不同部分提供線程安全后，GCD的優(yōu)點(diǎn)就是顯而易見的。關(guān)于這一點(diǎn)的關(guān)鍵是選擇正確類型的調(diào)度隊列和正確地調(diào)度函數(shù)來提交你的工作。
在本節(jié)你會看到兩種調(diào)度隊列，都是由GCD提供的，然后看一些描述如何用調(diào)度函數(shù)添加工作到隊列的例子。
Serial Queues 串行隊列
串行隊列中得任務(wù)一次執(zhí)行一個，每個任務(wù)只在前一個任務(wù)完成時才開始。而且，你不知道在一個Block結(jié)束和下一個開始之間的時間長度，如下圖所示：
這些任務(wù)執(zhí)行的時機(jī)受到GCD的控制；唯一能確保的事情是GCD一次只能執(zhí)行一個任務(wù)，并且按照我們添加到隊列的順序來執(zhí)行。
由于在串行隊列中不會有兩個任務(wù)并發(fā)運(yùn)行，因此不會出新同時訪問臨界區(qū)的風(fēng)險；相對于這些任務(wù)來說，這就從競態(tài)條件下保護(hù)了臨界區(qū)。所以如果訪問臨界區(qū)的唯一方式是通過提交到調(diào)度隊列的任務(wù)，那么你就不需要擔(dān)心臨界區(qū)安全問題了。
Concurrent Queues 并發(fā)隊列
在并發(fā)隊列中得任務(wù)能得到的保證是它們會按照被添加的順序開始執(zhí)行，但這既是全部的保證了。任務(wù)可能以任意順序完成，你不會知道何時開始運(yùn)行下一個任務(wù)，或者任意時刻有多少Block在運(yùn)行。再說一遍，這完全取決于GCD。
下圖展示了一個示例任務(wù)執(zhí)行計劃，GCD管理者四個并發(fā)任務(wù)：
注意Block1，2和3都立馬開始運(yùn)行，一個接一個。在Block0開始后，Block1等待了好一會兒才開始。同樣，Block3在Block2之后才開始，但它先于Block2完成。
何時開始一個Block完全取決于GCD。如果一個Block的執(zhí)行時間與另一個重疊，也是由GCD來決定是否將其運(yùn)行在另一個不同的核心上，如果那個核心可用，否則就用上下文切換的方式來執(zhí)行不同的Block。
有趣的是，GCD提供給你至少五個特定的隊列，可根據(jù)隊列類型選擇使用。
Queue Types 隊列類型
首先，系統(tǒng)提供給你一個叫做主隊列（main queue）的特殊隊列。和其他串行隊列一樣，這個隊列中得任務(wù)一次只能執(zhí)行一個。然而，它能保證所有的任務(wù)都在主線程執(zhí)行，而主線程是唯一可用于更新UI的線程。這個隊列就是用于發(fā)生消息給UIView或發(fā)送通知的。系統(tǒng)同時提供給你好幾個并發(fā)隊列。它們叫做全局調(diào)度隊列(Global Dispatch Queues)。目前的四個全局隊列有著不同的優(yōu)先級：background、low、default以及high。要知道，Apple的API也會使用這些隊列，所以你添加的任何任務(wù)都不會是這些隊列中唯一的任務(wù)。
最后，你也可以創(chuàng)建自己的串行隊列或并發(fā)隊列。這就是說，至少有五個隊列任你處置：主隊列、四個全局調(diào)度隊列，再加上任何你自己創(chuàng)建的隊列。
以上是調(diào)度隊列的大框架！
GCD的“藝術(shù)”歸結(jié)為選擇合適的隊列來調(diào)度函數(shù)以提交你的工作。體驗(yàn)這一點(diǎn)的最好方式是走一遍下邊的例子，我們沿途會提供一些一般性的建議。
入門
既然本教程的目標(biāo)是優(yōu)化且安全的使用GCD調(diào)用來自不同線程的代碼，那么你將從一個近乎完成的叫做googlyPuff的項目入手。
GooglyPuff是一個沒有優(yōu)化，線程不安全的應(yīng)用，它使用Core Image 的人臉檢測API來覆蓋一對曲棍球眼睛到被檢測到得人臉上。對于基本的圖像，可以從相機(jī)膠卷選擇，或用預(yù)設(shè)好的URL從互聯(lián)網(wǎng)下載。
完成項目下載之后，將其解壓到某個方便的目錄，再用Xcode打開它并編譯運(yùn)行。這個應(yīng)用看起來如下圖所示：
注意當(dāng)你選擇Le Internet選項下載圖片時，一個UIAlertView過早地彈出。你將在本系列教程的第二部分修復(fù)這個問題。
這個項目中有四個有趣的類：
- PhotoCollectionViewController:他是應(yīng)用開始的第一個視圖控制器。它用縮略圖展示所有選定的照片。
- PhotoDetailViewController:它執(zhí)行添加曲棍球眼睛到圖像上德邏輯，并用一個UIScrollView來顯示結(jié)果圖片。
- Photo:這是一個類，它根據(jù)一個
NSURL的實(shí)例或一個ALAsset的實(shí)例來實(shí)例化照片。這個類提供一個圖像、縮略圖以及從URL下載的狀態(tài)。 - PhotoManager:它管理所有
Photo的實(shí)例。
用dispatch_async處理后臺任務(wù)
回到應(yīng)用并從你的相機(jī)膠卷添加一些照片或使用Le Internet選項下載一些。
注意在按下PhotoCollectionViewController中得一個UICollectionViewCell到生成一個新的PhotoDetailViewController之間花了多久時間；你會注意到一個明顯的滯后，特變是在比較慢得設(shè)備上查看很大的圖。
在重載UIViewController的viewDidLoad時容易加入太多雜波(too much clutter)，這通常會引起視圖控制器出現(xiàn)前更長的等待。如果可能，最好是卸下一些工作放到后臺，如果他們不是絕對必須要運(yùn)行在加載時間里。
這聽起來像是dispatch_async能做的事情！
打開PhotoDetailViewController并用下面的實(shí)現(xiàn)替換viewDidLoad:
- (void)viewDidLoad
{
[super viewDidLoad];
NSAssert(_image, @"Image not set; required to use view controller");
self.photoImageView.image = _image;
//Resize if neccessary to ensure it's not pixelated
if (_image.size.height <= self.photoImageView.bounds.size.height &&
_image.size.width <= self.photoImageView.bounds.size.width) {
[self.photoImageView setContentMode:UIViewContentModeCenter];
}
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{ // 1
UIImage *overlayImage = [self faceOverlayImageFromImage:_image];
dispatch_async(dispatch_get_main_queue(), ^{ // 2
[self fadeInNewImage:overlayImage]; // 3
});
});
}
