GCD 深入理解（一）

這篇文章是上一篇iOS 多執行緒和GCD(Grand Central Dispath) 教程 （一）的續篇

因為第一篇只是一個簡單的入門，來告訴大傢什麼是多執行緒和GCD，並沒有詳細解釋GCD的眾多用法。

因此才有這麼一篇，後面還會有一篇。

上一篇文章呢是我自己翻譯那個老外的，今天這個是網上其他人翻譯好的，我就直接借用啦~

原文地址：GCD 深入理解 （一）

————————————————————————————————————————————————————————————————————————

OK，開始！

本文由@nixzhu翻譯至raywenderlich的《grand-central-dispatch-in-depth-part-1》

雖然 GCD 已經出現過一段時間了，但不是每個人都明瞭其主要內容。這是可以理解的；併發一直很棘手，而 GCD 是基於 C 的 API ，它們就像一組尖銳的稜角戳進 Objective-C 的平滑世界。我們將分兩個部分的教程來深入學習 GCD 。   在這兩部分的系列中，第一個部分的將解釋 GCD 是做什麼的，並從許多基本的 GCD 函式中找出幾個來展示。在第二部分，你將學到幾個 GCD 提供的高階函式。   什麼是 GCD GCD 是 libdispatch 的市場名稱，而 libdispatch 作為 Apple 的一個庫，為併發程式碼在多核硬體（跑 iOS 或 OS X ）上執行提供有力支援。它具有以下優點： 1.GCD 能通過推遲昂貴計算任務並在後臺執行它們來改善你的應用的響應效能。 2.GCD 提供一個易於使用的併發模型而不僅僅只是鎖和執行緒，以幫助我們避開併發陷阱。 3.GCD 具有在常見模式（例如單例）上用更高效能的原語優化你的程式碼的潛在能力。   本教程假設你對 Block 和 GCD 有基礎瞭解。如果你對 GCD 完全陌生，先看看 

iOS 上的多執行緒和 GCD 入門教程 學習其要領。   GCD 術語 要理解 GCD ，你要先熟悉與執行緒和併發相關的幾個概念。這兩者都可能模糊和微妙，所以在開始 GCD 之前先簡要地回顧一下它們。   Serial vs. Concurrent 序列 vs. 併發 這些術語描述當任務相對於其它任務被執行，任務序列執行就是每次只有一個任務被執行，任務併發執行就是在同一時間可以有多個任務被執行。   雖然這些術語被廣泛使用，本教程中你可以將任務設定為一個 Objective-C 的 Block 。不明白什麼是 Block ？看看  iOS 5 教程中的如何使用 Block 。實際上，你也可以在 GCD 上使用函式指標，但在大多數場景中，這實際上更難於使用。Block 就是更加容易些！   Synchronous vs. Asynchronous 同步 vs. 非同步 在 GCD 中，這些術語描述當一個函式相對於另一個任務完成，此任務是該函式要求 GCD 執行的。一個同步函式只在完成了它預定的任務後才返回。   一個非同步函式，剛好相反，會立即返回，預定的任務會完成但不會等它完成。因此，一個非同步函式不會阻塞當前執行緒去執行下一個函式。   注意——當你讀到同步函式“阻塞（Block）”當前執行緒，或函式是一個“阻塞”函式或阻塞操作時，不要被搞糊塗了！動詞“阻塞”描述了函式如何影響它所在的執行緒而與名詞“程式碼塊（Block）”沒有關係。程式碼塊描述了用 Objective-C 編寫的一個匿名函式，它能定義一個任務並被提交到 GCD 。   譯者注：中文不會有這個問題，“阻塞”和“程式碼塊”是兩個詞。   Critical Section 臨界區 就是一段程式碼不能被併發執行，也就是，兩個執行緒不能同時執行這段程式碼。這很常見，因為程式碼去操作一個共享資源，例如一個變數若能被併發程序訪問，那麼它很可能會變質（譯者注：它的值不再可信）。   Race Condition 競態條件 這種狀況是指基於特定序列或時機的事件的軟體系統以不受控制的方式執行的行為，例如程式的併發任務執行的確切順序。競態條件可導致無法預測的行為，而不能通過程式碼檢查立即發現。   Deadlock 死鎖 兩個（有時更多）東西——在大多數情況下，是執行緒——所謂的死鎖是指它們都卡住了，並等待對方完成或執行其它操作。第一個不能完成是因為它在等待第二個的完成。但第二個也不能完成，因為它在等待第一個的完成。   Thread Safe 執行緒安全 執行緒安全的程式碼能在多執行緒或併發任務中被安全的呼叫，而不會導致任何問題（資料損壞，崩潰，等）。執行緒不安全的程式碼在某個時刻只能在一個上下文中執行。一個執行緒安全程式碼的例子是 NSDictionary 。你可以在同一時間在多個執行緒中使用它而不會有問題。另一方面，NSMutableDictionary 就不是執行緒安全的，應該保證一次只能有一個執行緒訪問它。   Context Switch 上下文切換 一個上下文切換指當你在單個程序裡切換執行不同的執行緒時儲存與恢復執行狀態的過程。這個過程在編寫多工應用時很普遍，但會帶來一些額外的開銷。   Concurrency vs Parallelism 併發與並行 併發和並行通常被一起提到，所以值得花些時間解釋它們之間的區別。   併發程式碼的不同部分可以“同步”執行。然而，該怎樣發生或是否發生都取決於系統。多核裝置通過並行來同時執行多個執行緒；然而，為了使單核裝置也能實現這一點，它們必須先執行一個執行緒，執行一個上下文切換，然後執行另一個執行緒或程序。這通常發生地足夠快以致給我們併發執行地錯覺，如下圖所示：    雖然你可以編寫程式碼在 GCD 下併發執行，但 GCD 會決定有多少並行的需求。並行要求併發，但併發並不能保證並行。   更深入的觀點是併發實際上是關於構造。當你在腦海中用 GCD 編寫程式碼，你組織你的程式碼來暴露能同時執行的多個工作片段，以及不能同時執行的那些。如果你想深入此主題，看看  this excellent talk by Rob Pike 。   Queues 佇列 GCD 提供有 dispatch queues 來處理程式碼塊，這些佇列管理你提供給 GCD 的任務並用 FIFO 順序執行這些任務。這就保證了第一個被新增到佇列裡的任務會是佇列中第一個開始的任務，而第二個被新增的任務將第二個開始，如此直到佇列的終點。   所有的排程佇列（dispatch queues）自身都是執行緒安全的，你能從多個執行緒並行的訪問它們。 GCD 的優點是顯而易見的，即當你瞭解了排程佇列如何為你自己程式碼的不同部分提供執行緒安全。關於這一點的關鍵是選擇正確型別的排程佇列和正確的排程函式來提交你的工作。   在本節你會看到兩種排程佇列，都是由 GCD 提供的，然後看一些描述如何用排程函式新增工作到佇列的列子。   Serial Queues 序列佇列    這些任務的執行時機受到 GCD 的控制；唯一能確保的事情是 GCD 一次只執行一個任務，並且按照我們新增到佇列的順序來執行。   由於在序列佇列中不會有兩個任務併發執行，因此不會出現同時訪問臨界區的風險；相對於這些任務來說，這就從競態條件下保護了臨界區。所以如果訪問臨界區的唯一方式是通過提交到排程佇列的任務，那麼你就不需要擔心臨界區的安全問題了。   Concurrent Queues 併發佇列   在併發佇列中的任務能得到的保證是它們會按照被新增的順序開始執行，但這就是全部的保證了。任務可能以任意順序完成，你不會知道何時開始執行下一個任務，或者任意時刻有多少 Block 在執行。再說一遍，這完全取決於 GCD 。   下圖展示了一個示例任務執行計劃，GCD 管理著四個併發任務：    注意 Block 1,2 和 3 都立馬開始執行，一個接一個。在 Block 0 開始後，Block 1等待了好一會兒才開始。同樣， Block 3 在 Block 2 之後才開始，但它先於 Block 2 完成。   何時開始一個 Block 完全取決於 GCD 。如果一個 Block 的執行時間與另一個重疊，也是由 GCD 來決定是否將其執行在另一個不同的核心上，如果那個核心可用，否則就用上下文切換的方式來執行不同的 Block 。   有趣的是， GCD 提供給你至少五個特定的佇列，可根據佇列型別選擇使用。   Queue Types 佇列型別 首先，系統提供給你一個叫做 主佇列（main queue） 的特殊佇列。和其它序列佇列一樣，這個佇列中的任務一次只能執行一個。然而，它能保證所有的任務都在主執行緒執行，而主執行緒是唯一可用於更新 UI 的執行緒。這個佇列就是用於發生訊息給 UIView 或傳送通知的。   系統同時提供給你好幾個併發佇列。它們叫做 全域性排程佇列（Global Dispatch Queues） 。目前的四個全域性佇列有著不同的優先順序：background、low、default 以及 high。要知道，Apple 的 API 也會使用這些佇列，所以你新增的任何任務都不會是這些佇列中唯一的任務。   最後，你也可以建立自己的序列佇列或併發佇列。這就是說，至少有五個佇列任你處置：主佇列、四個全域性排程佇列，再加上任何你自己建立的佇列。   以上是排程佇列的大框架！   GCD 的“藝術”歸結為選擇合適的佇列來排程函式以提交你的工作。體驗這一點的最好方式是走一遍下邊的列子，我們沿途會提供一些一般性的建議。   入門 既然本教程的目標是優化且安全的使用 GCD 呼叫來自不同執行緒的程式碼，那麼你將從一個近乎完成的叫做 GooglyPuff 的專案入手。   GooglyPuff 是一個沒有優化，執行緒不安全的應用，它使用 Core Image 的人臉檢測 API 來覆蓋一對曲棍球眼睛到被檢測到的人臉上。對於基本的影象，可以從相機膠捲選擇，或用預設好的URL從網際網路下載。   點選此處下載專案   完成專案下載之後，將其解壓到某個方便的目錄，再用 Xcode 開啟它並編譯執行。這個應用看起來如下圖所示：   注意當你選擇 Le Internet 選項下載圖片時，一個 UIAlertView 過早地彈出。你將在本系列教程地第二部分修復這個問題。   這個專案中有四個有趣的類： 1. PhotoCollectionViewController：它是應用開始的第一個檢視控制器。它用縮圖展示所有選定的照片。 2. PhotoDetailViewController：它執行新增曲棍球眼睛到影象上的邏輯，並用一個 UIScrollView 來顯示結果圖片。 3. Photo：這是一個類簇，它根據一個 NSURL 的例項或一個 ALAsset 的例項來例項化照片。這個類提供一個影象、縮圖以及從 URL 下載的狀態。 4. PhotoManager：它管理所有 Photo 的例項.   用 dispatch_async 處理後臺任務 回到應用並從你的相機膠捲新增一些照片或使用 Le Internet 選項下載一些。   注意在按下 PhotoCollectionViewController 中的一個 UICollectionViewCell 到生成一個新的 PhotoDetailViewController 之間花了多久時間；你會注意到一個明顯的滯後，特別是在比較慢的裝置上檢視很大的圖。   在過載 UIViewController 的 viewDidLoad 時容易加入太多雜波（too much clutter），這通常會引起檢視控制器出現前更長的等待。如果可能，最好是卸下一些工作放到後臺，如果它們不是絕對必須要執行在載入時間裡。   這聽起來像是 dispatch_async 能做的事情！   開啟 PhotoDetailViewController 並用下面的實現替換 viewDidLoad ： [objc]  view plain copy

1. - (void)viewDidLoad  
2. {     
3.     [super viewDidLoad];  
4.     NSAssert(_image, @"Image not set; required to use view controller");  
5.     self.photoImageView.image = _image;  
6.    
7.     //Resize if neccessary to ensure it's not pixelated  
8.     if (_image.size.height <= self.photoImageView.bounds.size.height &&  
9.         _image.size.width <= self.photoImageView.bounds.size.width) {  
10.         [self.photoImageView setContentMode:UIViewContentModeCenter];  
11.     }  
12.    
13.     dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{ // 1  
14.         UIImage *overlayImage = [self faceOverlayImageFromImage:_image];  
15.         dispatch_async(dispatch_get_main_queue(), ^{ // 2  
16.             [self fadeInNewImage:overlayImage]; // 3  
17.         });  
18.     });  
19. }  

下面來說明上面的新程式碼所做的事：   1. 你首先將工作從主執行緒移到全域性執行緒。因為這是一個 dispatch_async() ，Block 會被非同步地提交，意味著呼叫執行緒地執行將會繼續。這就使得 viewDidLoad 更早地在主執行緒完成，讓載入過程感覺起來更加快速。同時，一個人臉檢測過程會啟動並將在稍後完成。 2. 在這裡，人臉檢測過程完成，並生成了一個新的影象。既然你要使用此新影象更新你的 UIImageView ，那麼你就新增一個新的 Block 到主執行緒。記住——你必須總是在主執行緒訪問 UIKit 的類。 3. 最後，你用 fadeInNewImage: 更新 UI ，它執行一個淡入過程切換到新的曲棍球眼睛影象。 編譯並執行你的應用；選擇一個影象然後你會注意到檢視控制器載入明顯變快，曲棍球眼睛稍微在之後就加上了。這給應用帶來了不錯的效果，和之前的顯示差別巨大。   進一步，如果你試著載入一個超大的影象，應用不會在載入檢視控制器上“掛住”，這就使得應用具有很好伸縮性。   正如之前提到的， dispatch_async 新增一個 Block 都佇列就立即返回了。任務會在之後由 GCD 決定執行。當你需要在後臺執行一個基於網路或 CPU 緊張的任務時就使用 dispatch_async ，這樣就不會阻塞當前執行緒。   下面是一個關於在 dispatch_async 上如何以及何時使用不同的佇列型別的快速指導： 1. 自定義序列佇列：當你想序列執行後臺任務並追蹤它時就是一個好選擇。這消除了資源爭用，因為你知道一次只有一個任務在執行。注意若你需要來自某個方法的資料，你必須內聯另一個 Block 來找回它或考慮使用 dispatch_sync。 2. 主佇列（序列）：這是在一個併發佇列上完成任務後更新 UI 的共同選擇。要這樣做，你將在一個 Block 內部編寫另一個 Block 。以及，如果你在主佇列呼叫 dispatch_async 到主佇列，你能確保這個新任務將在當前方法完成後的某個時間執行。 3. 併發佇列：這是在後臺執行非 UI 工作的共同選擇。