天天看點
傳回

深入了解 GCD（一） 深入了解 GCD（一）

深入了解 GCD（一）

原文出處： Derek Selander   譯文出處：nixzhu （@nixzhu）   

原文連結：http://blog.jobbole.com/66866/（譯文），https://www.raywenderlich.com/60749/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 ）上執行提供有力支援。它具有以下優點：

  • GCD 能通過推遲昂貴計算任務并在背景運作它們來改善你的應用的響應性能。
  • GCD 提供一個易于使用的并發模型而不僅僅隻是鎖和線程，以幫助我們避開并發陷阱。
  • 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 下并發執行，但 GCD 會決定有多少并行的需求。并行要求并發，但并發并不能保證并行。

更深入的觀點是并發實際上是關于構造。當你在腦海中用 GCD 編寫代碼，你組織你的代碼來暴露能同時運作的多個工作片段，以及不能同時運作的那些。如果你想深入此主題，看看 this excellent talk by Rob Pike 。

Queues 隊列

GCD 提供有 

dispatch queues

 來處理代碼塊，這些隊列管理你提供給 GCD 的任務并用 FIFO 順序執行這些任務。這就保證了第一個被添加到隊列裡的任務會是隊列中第一個開始的任務，而第二個被添加的任務将第二個開始，如此直到隊列的終點。

所有的排程隊列（dispatch queues）自身都是線程安全的，你能從多個線程并行的通路它們。 GCD 的優點是顯而易見的，即當你了解了排程隊列如何為你自己代碼的不同部分提供線程安全。關于這一點的關鍵是選擇正确類型的排程隊列和正确的排程函數來送出你的工作。

在本節你會看到兩種排程隊列，都是由 GCD 提供的，然後看一些描述如何用排程函數添加工作到隊列的列子。

Serial Queues 串行隊列

串行隊列中的任務一次執行一個，每個任務隻在前一個任務完成是才開始。而且，你不知道在一個 Block 結束和下一個開始之間的時間長度，如下圖所示：

深入了解 GCD（一） 深入了解 GCD（一）

這些任務的執行時機受到 GCD 的控制；唯一能確定的事情是 GCD 一次隻執行一個任務，并且按照我們添加到隊列的順序來執行。

由于在串行隊列中不會有兩個任務并發運作，是以不會出現同時通路臨界區的風險；相對于這些任務來說，這就從競态條件下保護了臨界區。是以如果通路臨界區的唯一方式是通過送出到排程隊列的任務，那麼你就不需要擔心臨界區的安全問題了。

Concurrent Queues 并發隊列

在并發隊列中的任務能得到的保證是它們會按照被添加的順序開始執行，但這就是全部的保證了。任務可能以任意順序完成，你不會知道何時開始運作下一個任務，或者任意時刻有多少 Block 在運作。再說一遍，這完全取決于 GCD 。

下圖展示了一個示例任務執行計劃，GCD 管理着四個并發任務：

深入了解 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 打開它并編譯運作。這個應用看起來如下圖所示：

深入了解 GCD（一） 深入了解 GCD（一）

注意當你選擇 

Le Internet

 選項下載下傳圖檔時，一個 

UIAlertView

 過早地彈出。你将在本系列教程地第二部分修複這個問題。

這個項目中有四個有趣的類：

  • PhotoCollectionViewController：它是應用開始的第一個視圖控制器。它用縮略圖展示所有標明的照片。
  • PhotoDetailViewController：它執行添加曲棍球眼睛到圖像上的邏輯，并用一個 UIScrollView 來顯示結果圖檔。
  • Photo：這是一個類簇，它根據一個 

    NSURL

      的執行個體或一個 

    ALAsset

      的執行個體來執行個體化照片。這個類提供一個圖像、縮略圖以及從 URL 下載下傳的狀态。
  • PhotoManager：它管理所有 

    Photo

      的執行個體.

用 dispatch_async 處理背景任務

回到應用并從你的相機膠卷添加一些照片或使用 

Le Internet

 選項下載下傳一些。

注意在按下 

PhotoCollectionViewController

 中的一個 

UICollectionViewCell

 到生成一個新的 

PhotoDetailViewController

 之間花了多久時間；你會注意到一個明顯的滞後，特别是在比較慢的裝置上檢視很大的圖。

在重載 

UIViewController 的 viewDidLoad

 時容易加入太多雜波（too much clutter），這通常會引起視圖控制器出現前更長的等待。如果可能，最好是卸下一些工作放到背景，如果它們不是絕對必須要運作在加載時間裡。

這聽起來像是 

dispatch_async

 能做的事情！

打開 

PhotoDetailViewController

 并用下面的實作替換 

viewDidLoad

 ：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

- (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

});

});

}

下面來說明上面的新代碼所做的事：

  1. 你首先将工作從主線程移到全局線程。因為這是一個 

    dispatch_async()

      ，Block 會被異步地送出，意味着調用線程地執行将會繼續。這就使得 

    viewDidLoad

      更早地在主線程完成，讓加載過程感覺起來更加快速。同時，一個人臉檢測過程會啟動并将在稍後完成。
  2. 在這裡，人臉檢測過程完成，并生成了一個新的圖像。既然你要使用此新圖像更新你的 

    UIImageView

      ，那麼你就添加一個新的 Block 到主線程。記住——你必須總是在主線程通路 UIKit 的類。
  3. 最後，你用 

    fadeInNewImage:

      更新 UI ，它執行一個淡入過程切換到新的曲棍球眼睛圖像。

編譯并運作你的應用；選擇一個圖像然後你會注意到視圖控制器加載明顯變快，曲棍球眼睛稍微在之後就加上了。這給應用帶來了不錯的效果，和之前的顯示差别巨大。

進一步，如果你試着加載一個超大的圖像，應用不會在加載視圖控制器上“挂住”，這就使得應用具有很好伸縮性。

正如之前提到的， 

dispatch_async

 添加一個 Block 都隊列就立即傳回了。任務會在之後由 GCD 決定執行。當你需要在背景執行一個基于網絡或 CPU 緊張的任務時就使用 

dispatch_async

 ，這樣就不會阻塞目前線程。

下面是一個關于在 

dispatch_async

 上如何以及何時使用不同的隊列類型的快速指導：

  • 自定義串行隊列：當你想串行執行背景任務并追蹤它時就是一個好選擇。這消除了資源争用，因為你知道一次隻有一個任務在執行。注意若你需要來自某個方法的資料，你必須内聯另一個 Block 來找回它或考慮使用 

    dispatch_sync

     。
  • 主隊列（串行）：這是在一個并發隊列上完成任務後更新 UI 的共同選擇。要這樣做，你将在一個 Block 内部編寫另一個 Block 。以及，如果你在主隊列調用 

    dispatch_async

      到主隊列，你能確定這個新任務将在目前方法完成後的某個時間執行。
  • 并發隊列：這是在背景執行非 UI 工作的共同選擇。

使用 dispatch_after 延後工作

稍微考慮一下應用的 UX 。是否使用者第一次打開應用時會困惑于不知道做什麼？你是這樣嗎？ :]

如果使用者的 

PhotoManager

 裡還沒有任何照片，那麼顯示一個提示會是個好主意！然而，你同樣要考慮使用者的眼睛會如何在主螢幕上浏覽：如果你太快的顯示一個提示，他們的眼睛還徘徊在視圖的其它部分上，他們很可能會錯過它。

顯示提示之前延遲一秒鐘就足夠捕捉到使用者的注意，他們此時已經第一次看過了應用。

添加如下代碼到到 PhotoCollectionViewController.m 中 showOrHideNavPrompt 的廢止實作裡：

1 2 3 4 5 6 7 8 9 10 11 12 13

- (void)showOrHideNavPrompt

{

NSUInteger count = [[PhotoManager sharedManager] photos].count;

double delayInSeconds = 1.0;

dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delayInSeconds * NSEC_PER_SEC)); // 1

dispatch_after(popTime, dispatch_get_main_queue(), ^(void){ // 2

if (!count) {

[self.navigationItem setPrompt:@"Add photos with faces to Googlyify them!"];

} else {

[self.navigationItem setPrompt:nil];

}

});

}

showOrHideNavPrompt 在 viewDidLoad 中執行，以及 UICollectionView 被重新加載的任何時候。按照注釋數字順序看看：

  1. 你聲明了一個變量指定要延遲的時長。
  2. 然後等待 

    delayInSeconds

      給定的時長，再異步地添加一個 Block 到主線程。

編譯并運作應用。應該有一個輕微地延遲，這有助于抓住使用者的注意力并展示所要做的事情。

dispatch_after

 工作起來就像一個延遲版的 

dispatch_async

 。你依然不能控制實際的執行時間，且一旦 

dispatch_after

 傳回也就不能再取消它。

不知道何時适合使用 

dispatch_after

 ？

  • 自定義串行隊列：在一個自定義串行隊列上使用 

    dispatch_after

      要小心。你最好堅持使用主隊列。
  • 主隊列（串行）：是使用 

    dispatch_after

      的好選擇；Xcode 提供了一個不錯的自動完成模版。
  • 并發隊列：在并發隊列上使用 

    dispatch_after

      也要小心；你會這樣做就比較罕見。還是在主隊列做這些操作吧。

讓你的單例線程安全

單例，不論喜歡還是讨厭，它們在 iOS 上的流行情況就像網上的貓。 :]

一個常見的擔憂是它們常常不是線程安全的。這個擔憂十分合理，基于它們的用途：單例常常被多個控制器同時通路。

單例的線程擔憂範圍從初始化開始，到資訊的讀和寫。

PhotoManager

 類被實作為單例——它在目前的狀态下就會被這些問題所困擾。要看看事情如何很快地失去控制，你将在單例執行個體上建立一個控制好的競态條件。

導航到 

PhotoManager.m

 并找到 

sharedManager

 ；它看起來如下：

1 2 3 4 5 6 7 8 9

+ (instancetype)sharedManager   

{

static PhotoManager *sharedPhotoManager = nil;

if (!sharedPhotoManager) {

sharedPhotoManager = [[PhotoManager alloc] init];

sharedPhotoManager->_photosArray = [NSMutableArray array];

}

return sharedPhotoManager;

}

目前狀态下，代碼相當簡單；你建立了一個單例并初始化一個叫做 

photosArray

 的 

NSMutableArray

 屬性。

然而，

if

 條件分支不是線程安全的；如果你多次調用這個方法，有一個可能性是在某個線程（就叫它線程A）上進入 

if

 語句塊并可能在 

sharedPhotoManager

 被配置設定記憶體前發生一個上下文切換。然後另一個線程（線程B）可能進入 

if

 ，配置設定單例執行個體的記憶體，然後退出。

當系統上下文切換回線程A，你會配置設定另外一個單例執行個體的記憶體，然後退出。在那個時間點，你有了兩個單例的執行個體——很明顯這不是你想要的（譯者注：這還能叫單例嗎？）！

要強制這個（競态）條件發生，替換 

PhotoManager.m

 中的 

sharedManager

 為下面的實作：

1 2 3 4 5 6 7 8 9 10 11 12

+ (instancetype)sharedManager 

{

static PhotoManager *sharedPhotoManager = nil;

if (!sharedPhotoManager) {

[NSThread sleepForTimeInterval:2];

sharedPhotoManager = [[PhotoManager alloc] init];

NSLog(@"Singleton has memory address at: %@", sharedPhotoManager);

[NSThread sleepForTimeInterval:2];

sharedPhotoManager->_photosArray = [NSMutableArray array];

}

return sharedPhotoManager;

}

上面的代碼中你用 

NSThread 的 sleepForTimeInterval:

 類方法來強制發生一個上下文切換。

打開 

AppDelegate.m

 并添加如下代碼到 

application:didFinishLaunchingWithOptions:

 的最開始處：

1 2 3 4 5 6 7

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{

[PhotoManager sharedManager];

});

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{

[PhotoManager sharedManager];

});

這裡建立了多個異步并發調用來執行個體化單例，然後引發上面描述的競态條件。

編譯并運作項目；檢視控制台輸出，你會看到多個單例被執行個體化，如下所示：

深入了解 GCD（一） 深入了解 GCD（一）

注意到這裡有好幾行顯示着不同位址的單例執行個體。這明顯違背了單例的目的，對吧？:]

這個輸出向你展示了臨界區被執行多次，而它隻應該執行一次。現在，固然是你自己強制這樣的狀況發生，但你可以想像一下這個狀況會怎樣在無意間發生。

注意：基于其它你無法控制的系統事件，NSLog 的數量有時會顯示多個。線程問題極其難以調試，因為它們往往難以重制。

要糾正這個狀況，執行個體化代碼應該隻執行一次，并阻塞其它執行個體在 

if

 條件的臨界區運作。這剛好就是 

dispatch_once

 能做的事。

在單例初始化方法中用 

dispatch_once

 取代 

if

 條件判斷，如下所示：

1 2 3 4 5 6 7 8 9 10 11 12 13

+ (instancetype)sharedManager

{

static PhotoManager *sharedPhotoManager = nil;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

[NSThread sleepForTimeInterval:2];

sharedPhotoManager = [[PhotoManager alloc] init];

NSLog(@"Singleton has memory address at: %@", sharedPhotoManager);

[NSThread sleepForTimeInterval:2];

sharedPhotoManager->_photosArray = [NSMutableArray array];

});

return sharedPhotoManager;

}

編譯并運作你的應用；檢視控制台輸出，你會看到有且僅有一個單例的執行個體——這就是你對單例的期望！:]

現在你已經明白了防止競态條件的重要性，從 

AppDelegate.m

 中移除 

dispatch_async

 語句，并用下面的實作替換 

PhotoManager

單例的初始化：

1 2 3 4 5 6 7 8 9 10

+ (instancetype)sharedManager

{

static PhotoManager *sharedPhotoManager = nil;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

sharedPhotoManager = [[PhotoManager alloc] init];

sharedPhotoManager->_photosArray = [NSMutableArray array];

});

return sharedPhotoManager;

}

dispatch_once()

 以線程安全的方式執行且僅執行其代碼塊一次。試圖通路臨界區（即傳遞給 

dispatch_once

 的代碼）的不同的線程會在臨界區已有一個線程的情況下被阻塞，直到臨界區完成為止。

深入了解 GCD（一） 深入了解 GCD（一）

需要記住的是，這隻是讓通路共享執行個體線程安全。它絕對沒有讓類本身線程安全。類中可能還有其它競态條件，例如任何操縱内部資料的情況。這些需要用其它方式來保證線程安全，例如同步通路資料，你将在下面幾個小節看到。

處理讀者與寫者問題

線程安全執行個體不是處理單例時的唯一問題。如果單例屬性表示一個可變對象，那麼你就需要考慮是否那個對象自身線程安全。

如果問題中的這個對象是一個 Foundation 容器類，那麼答案是——“很可能不安全”！Apple 維護一個有用且有些心寒的清單，衆多的 Foundation 類都不是線程安全的。 

NSMutableArray

，已用于你的單例，正在那個清單裡休息。

雖然許多線程可以同時讀取 

NSMutableArray

 的一個執行個體而不會産生問題，但當一個線程正在讀取時讓另外一個線程修改數組就是不安全的。你的單例在目前的狀況下不能預防這種情況的發生。

要分析這個問題，看看 

PhotoManager.m

 中的 

addPhoto:

，轉載如下：

1 2 3 4 5 6 7 8 9

- (void)addPhoto:(Photo *)photo

{

if (photo) {

[_photosArray addObject:photo];

dispatch_async(dispatch_get_main_queue(), ^{

[self postContentAddedNotification];

});

}

}

這是一個

寫

方法，它修改一個私有可變數組對象。

現在看看 

photos

 ，轉載如下：

1 2 3 4

- (NSArray *)photos

{

return [NSArray arrayWithArray:_photosArray];

}

這是所謂的

讀

方法，它讀取可變數組。它為調用者生成一個不可變的拷貝，防止調用者不當地改變數組，但這不能提供任何保護來對抗當一個線程調用讀方法 

photos

 的同時另一個線程調用寫方法 

addPhoto:

 。

這就是軟體開發中經典的

讀者寫者問題

。GCD 通過用 

dispatch barriers

 建立一個

讀者寫者鎖

 提供了一個優雅的解決方案。

Dispatch barriers 是一組函數，在并發隊列上工作時扮演一個串行式的瓶頸。使用 GCD 的障礙（barrier）API 確定送出的 Block 在那個特定時間上是指定隊列上唯一被執行的條目。這就意味着所有的先于排程障礙送出到隊列的條目必能在這個 Block 執行前完成。

當這個 Block 的時機到達，排程障礙執行這個 Block 并確定在那個時間裡隊列不會執行任何其它 Block 。一旦完成，隊列就傳回到它預設的實作狀态。 GCD 提供了同步和異步兩種障礙函數。

下圖顯示了障礙函數對多個異步隊列的影響：

深入了解 GCD（一） 深入了解 GCD（一）

注意到正常部分的操作就如同一個正常的并發隊列。但當障礙執行時，它本質上就如同一個串行隊列。也就是，障礙是唯一在執行的事物。在障礙完成後，隊列回到一個正常并發隊列的樣子。

下面是你何時會——和不會——使用障礙函數的情況：

  • 自定義串行隊列：一個很壞的選擇；障礙不會有任何幫助，因為不管怎樣，一個串行隊列一次都隻執行一個操作。
  • 全局并發隊列：要小心；這可能不是最好的主意，因為其它系統可能在使用隊列而且你不能壟斷它們隻為你自己的目的。
  • 自定義并發隊列：這對于原子或臨界區代碼來說是極佳的選擇。任何你在設定或執行個體化的需要線程安全的事物都是使用障礙的最佳候選。

由于上面唯一像樣的選擇是自定義并發隊列，你将建立一個你自己的隊列去處理你的障礙函數并分開讀和寫函數。且這個并發隊列将允許多個多操作同時進行。

打開 

PhotoManager.m

，添加如下私有屬性到類擴充中：

1 2 3 4

@interface PhotoManager ()

@property (nonatomic,strong,readonly) NSMutableArray *photosArray;

@property (nonatomic, strong) dispatch_queue_t concurrentPhotoQueue; ///< Add this

@end

找到 

addPhoto:

 并用下面的實作替換它：

1 2 3 4 5 6 7 8 9 10 11

- (void)addPhoto:(Photo *)photo

{

if (photo) { // 1

dispatch_barrier_async(self.concurrentPhotoQueue, ^{ // 2

[_photosArray addObject:photo]; // 3

dispatch_async(dispatch_get_main_queue(), ^{ // 4

[self postContentAddedNotification];

});

});

}

}

你新寫的函數是這樣工作的：

  1. 在執行下面所有的工作前檢查是否有合法的相片。
  2. 添加寫操作到你的自定義隊列。當臨界區在稍後執行時，這将是你隊列中唯一執行的條目。
  3. 這是添加對象到數組的實際代碼。由于它是一個障礙 Block ，這個 Block 永遠不會同時和其它 Block 一起在 concurrentPhotoQueue 中執行。
  4. 最後你發送一個通知說明完成了添加圖檔。這個通知将在主線程被發送因為它将會做一些 UI 工作，是以在此為了通知，你異步地排程另一個任務到主線程。

這就處理了寫操作，但你還需要實作 

photos

 讀方法并執行個體化 

concurrentPhotoQueue

 。

在寫者打擾的情況下，要確定線程安全，你需要在 

concurrentPhotoQueue

 隊列上執行讀操作。既然你需要從函數傳回，你就不能異步排程到隊列，因為那樣在讀者函數傳回之前不一定運作。

在這種情況下，

dispatch_sync

 就是一個絕好的候選。

dispatch_sync()

 同步地送出工作并在傳回前等待它完成。使用 

dispatch_sync

 跟蹤你的排程障礙工作，或者當你需要等待操作完成後才能使用 Block 處理過的資料。如果你使用第二種情況做事，你将不時看到一個 

__block

 變量寫在 

dispatch_sync

 範圍之外，以便傳回時在 

dispatch_sync

 使用處理過的對象。

但你需要很小心。想像如果你調用 

dispatch_sync

 并放在你已運作着的目前隊列。這會導緻死鎖，因為調用會一直等待直到 Block 完成，但 Block 不能完成（它甚至不會開始！），直到目前已經存在的任務完成，而目前任務無法完成！這将迫使你自覺于你正從哪個隊列調用——以及你正在傳遞進入哪個隊列。

下面是一個快速總覽，關于在何時以及何處使用 

dispatch_sync

 ：

  • 自定義串行隊列：在這個狀況下要非常小心！如果你正運作在一個隊列并調用 

    dispatch_sync

      放在同一個隊列，那你就百分百地建立了一個死鎖。
  • 主隊列（串行）：同上面的理由一樣，必須非常小心！這個狀況同樣有潛在的導緻死鎖的情況。
  • 并發隊列：這才是做同步工作的好選擇，不論是通過排程障礙，或者需要等待一個任務完成才能執行進一步處理的情況。

繼續在 

PhotoManager.m

 上工作，用下面的實作替換 

photos

 ：

1 2 3 4 5 6 7 8

- (NSArray *)photos

{

__block NSArray *array; // 1

dispatch_sync(self.concurrentPhotoQueue, ^{ // 2

array = [NSArray arrayWithArray:_photosArray]; // 3

});

return array;

}

這就是你的讀函數。按順序看看編過号的注釋，有這些：

  1. __block

      關鍵字允許對象在 Block 内可變。沒有它，

    array

      在 Block 内部就隻是隻讀的，你的代碼甚至不能通過編譯。
  2. 在 

    concurrentPhotoQueue

      上同步排程來執行讀操作。
  3. 将相片數組存儲在 

    array

      内并傳回它。

最後，你需要執行個體化你的 

concurrentPhotoQueue

 屬性。修改 

sharedManager

 以便像下面這樣初始化隊列：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

+ (instancetype)sharedManager

{

static PhotoManager *sharedPhotoManager = nil;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

sharedPhotoManager = [[PhotoManager alloc] init];

sharedPhotoManager->_photosArray = [NSMutableArray array];

// ADD THIS:

sharedPhotoManager->_concurrentPhotoQueue = dispatch_queue_create("com.selander.GooglyPuff.photoQueue",

DISPATCH_QUEUE_CONCURRENT);

});

return sharedPhotoManager;

}

這裡使用 

dispatch_queue_create

 初始化 

concurrentPhotoQueue

 為一個并發隊列。第一個參數是反向DNS樣式命名慣例；確定它是描述性的，将有助于調試。第二個參數指定你的隊列是串行還是并發。

注意：當你在網上搜尋例子時，你會經常看人們傳遞   或者 

NULL

  給 

dispatch_queue_create

  的第二個參數。這是一個建立串行隊列的過時方式；明确你的參數總是更好。

恭喜——你的 

PhotoManager

 單例現在是線程安全的了。不論你在何處或怎樣讀或寫你的照片，你都有這樣的自信，即它将以安全的方式完成，不會出現任何驚吓。

A Visual Review of Queueing 隊列的虛拟回顧

依然沒有 100% 地掌握 GCD 的要領？確定你可以使用 GCD 函數輕松地建立簡單的例子，使用斷點和 

NSLog

 語句保證自己明白當下發生的情況。

我在下面提供了兩個 GIF動畫來幫助你鞏固對 

dispatch_async

 和 

dispatch_sync

 的了解。包含在每個 GIF 中的代碼可以提供視覺輔助；仔細注意 GIF 左邊顯示代碼斷點的每一步，以及右邊相關隊列的狀态。

dispatch_sync 回顧

1 2 3 4 5 6 7 8 9 10 11 12

- (void)viewDidLoad

{

[super viewDidLoad];

dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{

NSLog(@"First Log");

});

NSLog(@"Second Log");

}
深入了解 GCD（一） 深入了解 GCD（一）

下面是圖中幾個步驟的說明：

  1. 主隊列一路按順序執行任務——接着是一個執行個體化 

    UIViewController

      的任務，其中包含了 

    viewDidLoad

      。

  2. viewDidLoad

      在主線程執行。
  3. 主線程目前在 

    viewDidLoad

      内，正要到達 

    dispatch_sync

      。

  4. dispatch_sync

      Block 被添加到一個全局隊列中，将在稍後執行。程序将在主線程挂起直到該 Block 完成。同時，全局隊列并發處理任務；要記得 Block 在全局隊列中将按照 FIFO 順序出列，但可以并發執行。
  5. 全局隊列處理 

    dispatch_sync

      Block 加入之前已經出現在隊列中的任務。
  6. 終于，輪到 

    dispatch_sync

      Block 。
  7. 這個 Block 完成，是以主線程上的任務可以恢複。

  8. viewDidLoad

      方法完成，主隊列繼續處理其他任務。

dispatch_sync

 添加任務到一個隊列并等待直到任務完成。

dispatch_async

 做類似的事情，但不同之處是它不會等待任務的完成，而是立即繼續“調用線程”的其它任務。

dispatch_async 回顧

1 2 3 4 5 6 7 8 9 10 11 12

- (void)viewDidLoad

{

[super viewDidLoad];

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{

NSLog(@"First Log");

});

NSLog(@"Second Log");

}
深入了解 GCD（一） 深入了解 GCD（一）
  1. 主隊列一路按順序執行任務——接着是一個執行個體化 

    UIViewController

      的任務，其中包含了 

    viewDidLoad

      。

  2. viewDidLoad

      在主線程執行。
  3. 主線程目前在 

    viewDidLoad

      内，正要到達 

    dispatch_async

      。

  4. dispatch_async

      Block 被添加到一個全局隊列中，将在稍後執行。

  5. viewDidLoad

      在添加 

    dispatch_async

      到全局隊列後繼續進行，主線程把注意力轉向剩下的任務。同時，全局隊列并發地處理它未完成地任務。記住 Block 在全局隊列中将按照 FIFO 順序出列，但可以并發執行。
  6. 添加到 

    dispatch_async

      的代碼塊開始執行。

  7. dispatch_async

      Block 完成，兩個 

    NSLog

      語句将它們的輸出放在控制台上。

在這個特定的執行個體中，第二個 

NSLog

 語句執行，跟着是第一個 

NSLog

 語句。并不總是這樣——着取決于給定時刻硬體正在做的事情，而且你無法控制或知曉哪個語句會先執行。“第一個” 

NSLog

 在某些調用情況下會第一個執行。

下一步怎麼走？

在本教程中，你學習了如何讓你的代碼線程安全，以及在執行 CPU 密集型任務時如何保持主線程的響應性。

你可以下載下傳 GooglyPuff 項目，它包含了目前所有本教程中編寫的實作。在本教程的第二部分，你将繼續改進這個項目。

如果你計劃優化你自己的應用，那你應該用 

Instruments

 中的 

Time Profile

 模版分析你的工作。對這個工具的使用超出了本教程的範圍，你可以看看 如何使用Instruments 來得到一個很好的概述。

同時請確定在真實裝置上分析，而在模拟器上測試會對程式速度産生非常不準确的印象。

在教程的下一部分，你将更加深入到 GCD 的 API 中，做一些更 Cool 的東西。

如果你有任何問題或評論，可自由地加入下方的讨論！

iOS入門 iOS GCD
上一篇: 面向構件的SOA架構設計
下一篇: POJ 3970 Party

繼續閱讀