在本節(jié)中，您將深入了解蘋果最流行且易于使用的編寫和管理并發(fā)任務(wù)的機(jī)制——Grand Central Dispatch。您將學(xué)習(xí)如何利用隊(duì)列和線程來控制應(yīng)用程序中任務(wù)的執(zhí)行，以及如何將這些任務(wù)分組在一起。您還將了解使用并發(fā)性的常見陷阱和危險，以及如何避免它們。

第3章:隊(duì)列和線程:這一章教你如何使用一個GCD隊(duì)列從主線程卸載工作。你還會學(xué)到什么是“線程”。
第4章:組和信號量:在上一章中，您了解了隊(duì)列是如何工作的。在本章中，您將擴(kuò)展知識，學(xué)習(xí)如何向隊(duì)列提交多個任務(wù)，這些任務(wù)需要作為一個“組”一起運(yùn)行，這樣當(dāng)它們?nèi)客瓿蓵r，您可以得到通知。您還將了解如何包裝現(xiàn)有API，以便可以異步調(diào)用它。
第5章:并發(fā)問題:現(xiàn)在你已經(jīng)知道了GCD是如何讓你的應(yīng)用程序更快。如果不小心，本章將向您展示并發(fā)的一些危險，以及如何避免它們

第三章 隊(duì)列和線程

分派隊(duì)列和線程現(xiàn)在已經(jīng)提到過幾次了，現(xiàn)在您可能想知道它們是什么。在本章中，您將對調(diào)度隊(duì)列和線程有更深入的理解，以及如何最好地將它們合并到您的開發(fā)工作流中。

3.1 線程

你可能聽說過多線程這個詞，對吧?對于執(zhí)行線程來說，線程確實(shí)很短，它是一個正在運(yùn)行的進(jìn)程在系統(tǒng)上跨資源分割任務(wù)的方式。你的iOS應(yīng)用程序是一個利用多線程運(yùn)行多個任務(wù)的進(jìn)程。你可以有許多線程執(zhí)行一次，因?yàn)槟阌泻诵脑谀愕脑O(shè)備的CPU。

把應(yīng)用程序的工作分成多個線程有很多好處:

• 更快的執(zhí)行:通過在線程上運(yùn)行任務(wù)，工作可以并發(fā)地完成，這將使它比串行地完成所有工作更快。
• 響應(yīng)性:如果你只在主UI線程上執(zhí)行用戶可見的工作，那么用戶不會注意到應(yīng)用程序會因?yàn)榭梢栽谄渌€程上執(zhí)行的工作而周期性地變慢或凍結(jié)。
• 優(yōu)化的資源消耗:操作系統(tǒng)對線程進(jìn)行了高度優(yōu)化。

聽起來不錯,對吧?更多的核，更多的線程，更快的應(yīng)用程序。我打賭你準(zhǔn)備學(xué)習(xí)如何創(chuàng)建一個，對嗎?太糟糕了!實(shí)際上，您永遠(yuǎn)不會發(fā)現(xiàn)自己需要顯式地創(chuàng)建線程。操作系統(tǒng)將使用更高的抽象為您處理所有線程創(chuàng)建。

Apple提供了線程管理所需的api，但如果您嘗試自己直接管理它們，實(shí)際上可能會降低而不是提高性能。操作系統(tǒng)跟蹤許多統(tǒng)計(jì)信息，以了解何時應(yīng)該、何時不應(yīng)該分配或銷毀線程。不要欺騙自己，以為它就像你想要一根線的時候把線繞起來那么簡單。由于這些原因，本書將不涉及直接線程管理。

3.1.1 Dispatch queues

使用線程的方法是創(chuàng)建一個DispatchQueue。當(dāng)您創(chuàng)建一個隊(duì)列時，OS可能會創(chuàng)建一個或多個線程并將其分配給隊(duì)列。如果現(xiàn)有線程可用，它們可以被重用;如果沒有，那么操作系統(tǒng)將根據(jù)需要創(chuàng)建它們。

對于您來說，創(chuàng)建調(diào)度隊(duì)列非常簡單，如下面的示例所示:

let label = "com.raywenderlich.mycoolapp.networking"

let queue = DispatchQueue(label: label)

唷，相當(dāng)簡單，是吧?通常，您應(yīng)該將標(biāo)簽的文本直接放在初始化器中，但是為了簡潔起見，它被分解為單獨(dú)的語句。

label參數(shù)只需是用于標(biāo)識目的的任何唯一值。雖然你可以簡單地使用一個UUID來保證唯一性，但是最好使用一個反向dns風(fēng)格的名稱，如上面所示(例如com.company.app)，因?yàn)闃?biāo)簽是你在調(diào)試時看到的，它有助于為它分配有意義的文本。

The main queue

當(dāng)應(yīng)用程序啟動時，會自動為您創(chuàng)建一個主分派隊(duì)列。它是一個負(fù)責(zé)UI的串行隊(duì)列。由于它被頻繁使用，Apple將它作為類變量提供，您可以通過DispatchQueue.main訪問它。除非它與實(shí)際的UI工作相關(guān)，否則絕不希望對主隊(duì)列同步執(zhí)行某些操作。否則，您將鎖定UI，這可能會降低應(yīng)用程序的性能。

如果您還記得上一章，有兩種分派隊(duì)列:串行或并發(fā)。如上面的代碼所示，默認(rèn)的初始化器將創(chuàng)建一個串行隊(duì)列，每個任務(wù)必須在其中完成，然后才能開始下一個任務(wù)。

為了創(chuàng)建一個并發(fā)隊(duì)列，只需傳入.concurrent屬性，如下所示:

let label = "com.raywenderlich.mycoolapp.networking"

let queue = DispatchQueue(label: label, attributes: .concurrent)

并發(fā)隊(duì)列非常普遍，蘋果公司根據(jù)隊(duì)列應(yīng)有的服務(wù)質(zhì)量(QoS)提供了6個不同的全局并發(fā)隊(duì)列。

Quality of service

當(dāng)使用一個并發(fā)分派隊(duì)列時，您需要告訴iOS發(fā)送到隊(duì)列的任務(wù)有多重要，以便它能夠正確地將需要完成的工作與所有其他需要資源的任務(wù)區(qū)分優(yōu)先級。記住，高優(yōu)先級的工作必須更快地執(zhí)行，可能會比低優(yōu)先級的工作需要更多的系統(tǒng)資源和更多的能量。

如果你只是需要一個并發(fā)隊(duì)列，但不想管理自己的，你可以使用DispatchQueue上的全局類方法來獲得一個預(yù)定義的全局隊(duì)列:

let queue = DispatchQueue.global(qos: .userInteractive)

如上所述，蘋果提供了六種服務(wù)質(zhì)量等級:

• .userInteractive QoS建議用于用戶直接交互的任務(wù)。UI更新計(jì)算、動畫或任何需要保持UI響應(yīng)和快速的東西。如果工作不迅速進(jìn)行，事情可能會凍結(jié)。提交到這個隊(duì)列的任務(wù)實(shí)際上應(yīng)該立即完成。
• .userInitiated 當(dāng)用戶從UI啟動需要立即執(zhí)行但可以異步完成的任務(wù)時，應(yīng)該使用. userinitiated隊(duì)列。例如，您可能需要打開文檔或從本地數(shù)據(jù)庫讀取。如果用戶單擊了一個按鈕，這可能就是您想要的隊(duì)列。在此隊(duì)列中執(zhí)行的任務(wù)應(yīng)該需要幾秒鐘或更短的時間才能完成。
• .utility對于通常包含進(jìn)度指示器的任務(wù)，比如長時間運(yùn)行的計(jì)算、I/O、網(wǎng)絡(luò)或連續(xù)的數(shù)據(jù)提要，您將需要使用.utility分派隊(duì)列。該系統(tǒng)試圖平衡響應(yīng)能力和性能與能源效率。任務(wù)在這個隊(duì)列中可能需要幾秒鐘到幾分鐘
• .background 對于用戶不能直接意識到的任務(wù)，您應(yīng)該使用.background隊(duì)列。它們不需要用戶交互，對時間也不敏感。預(yù)取、數(shù)據(jù)庫維護(hù)、同步遠(yuǎn)程服務(wù)器和執(zhí)行備份都是很好的示例。OS將關(guān)注能源效率而不是速度。您將希望將此隊(duì)列用于需要大量時間(按分鐘或更長的順序)的工作。
• .default and .unspecified 還有另外兩種可能的選擇，但是您不應(yīng)該顯式地使用。在.userinitiated和.utility之間有一個.default選項(xiàng)，它是qos參數(shù)的默認(rèn)值。它不打算讓您直接使用。第二個選項(xiàng)是.未指定的，它的存在是為了支持遺留api，這些api可能會選擇脫離服務(wù)質(zhì)量的線程。知道它們的存在是件好事，但是如果您正在使用它們，那么幾乎可以肯定您正在做一些錯誤的事情。

注意:全局隊(duì)列總是并發(fā)的，并且先入先出。

推斷QoS

如果你創(chuàng)建自己的并發(fā)調(diào)度隊(duì)列，你可以通過它的初始化器告訴系統(tǒng)QoS是什么:

let queue = DispatchQueue(label: label, 
                          qos: .userInitiated,
                          attributes: .concurrent)

然而，這就像你和你的配偶/孩子/狗/寵物石爭吵一樣:僅僅因?yàn)槟阏f了并不會導(dǎo)致結(jié)果!操作系統(tǒng)將關(guān)注提交到隊(duì)列的任務(wù)類型，并根據(jù)需要進(jìn)行更改。

如果您提交的任務(wù)具有比隊(duì)列更高的服務(wù)質(zhì)量，則隊(duì)列的級別將會增加。不僅如此，所有加入隊(duì)列的操作的優(yōu)先級也將提高。

如果當(dāng)前上下文是主線程，則推斷的QoS為.userinitiated。您可以自己指定QoS，但一旦您將添加具有更高QoS的任務(wù)，您的隊(duì)列的QoS服務(wù)將增加以匹配它。

向隊(duì)列中添加任務(wù)

分派隊(duì)列提供了同步和異步方法來將任務(wù)添加到隊(duì)列中。請記住，我所說的任務(wù)只是指“需要運(yùn)行的任何代碼塊”。例如，當(dāng)應(yīng)用程序啟動時，您可能需要聯(lián)系服務(wù)器來更新應(yīng)用程序的狀態(tài)。這不是用戶發(fā)起的，不需要立即發(fā)生，依賴于網(wǎng)絡(luò)I/O，所以你應(yīng)該把它發(fā)送到全局效用隊(duì)列:

DispatchQueue.global(qos: .utility).async { [weak self] in
  guard let self = self else { return }

  // Perform your work here
  // ...

  // Switch back to the main queue to
  // update your UI
  DispatchQueue.main.async {
    self.textLabel.text = "New articles available!"
  }
}

您應(yīng)該從上面的代碼示例中了解到兩個關(guān)鍵點(diǎn)。首先，取消閉包規(guī)則的DispatchQueue沒有什么特殊之處。如果您計(jì)劃使用閉包捕獲的變量(如self)，您仍然需要確保正確地處理它們。

在GCD異步閉包中強(qiáng)捕獲self不會導(dǎo)致一個引用循環(huán)(例如一個保留循環(huán))，因?yàn)橐坏┧瓿桑麄€閉包將被釋放，但它會延長self的生命周期。例如，如果你從一個視圖控制器發(fā)出一個網(wǎng)絡(luò)請求，而這個請求已經(jīng)被駁回，那么閉包仍然會被調(diào)用。如果你弱捕獲視圖控制器，它將是nil。然而，如果你強(qiáng)捕獲它，視圖控制器將保持活著，直到閉包完成它的工作。記住這一點(diǎn)，并根據(jù)自己的需要，或強(qiáng)或弱地獲取信息。

其次，注意UI的更新是如何被分派到后臺隊(duì)列分派中的主隊(duì)列的。在他人內(nèi)部嵌套異步類型調(diào)用不僅可以，而且很常見

注意:除了主隊(duì)列之外，永遠(yuǎn)不要在任何隊(duì)列上執(zhí)行UI更新。如果沒有記錄API回調(diào)使用的隊(duì)列，就將其分派到主隊(duì)列!

在同步地向分派隊(duì)列提交任務(wù)時要格外小心。如果您發(fā)現(xiàn)自己調(diào)用的是sync方法，而不是async方法，請考慮一兩次是否真的應(yīng)該這樣做。如果你同步提交一個任務(wù)到當(dāng)前隊(duì)列，它阻塞了當(dāng)前隊(duì)列，并且你的任務(wù)試圖訪問當(dāng)前隊(duì)列中的資源，那么你的應(yīng)用程序?qū)梨i，這將在第5章“并發(fā)問題”中詳細(xì)解釋。類似地，如果你從主隊(duì)列調(diào)用同步，你會阻塞更新UI的線程，你的應(yīng)用會凍結(jié)。

注意:永遠(yuǎn)不要從主線程調(diào)用同步，因?yàn)檫@會阻塞主線程，甚至可能導(dǎo)致死鎖

3.2 圖像加載示例

此時，您已經(jīng)被大量的理論概念淹沒了。現(xiàn)在來看一個實(shí)際的例子!
在本書可下載的資料中，您將找到本章的入門項(xiàng)目。打開Concurrency.xcodeproj項(xiàng)目。你會看到一些圖片慢慢地從網(wǎng)絡(luò)加載到UICollectionView。如果你試圖在圖片加載時滾動屏幕，要么什么也不會發(fā)生，要么滾動會非常緩慢和不平滑，這取決于你使用的設(shè)備的速度。

image.png

打開CollectionViewController.swift看看發(fā)生了什么。當(dāng)視圖加載時，它只抓取要顯示的圖像url的靜態(tài)列表。當(dāng)然，在生產(chǎn)應(yīng)用程序中，您可能會在此時進(jìn)行網(wǎng)絡(luò)調(diào)用來生成要顯示的項(xiàng)列表，但是對于本例來說，硬編碼圖像列表更容易。

方法collectionView(_:cellForItemAt:)是問題發(fā)生的地方。可以看到，當(dāng)單元格準(zhǔn)備顯示時，會通過Data的構(gòu)造函數(shù)之一調(diào)用來下載圖像，然后將圖像分配給單元格。代碼看起來非常簡單，這也是大多數(shù)iOS開發(fā)人員下載圖像時所做的事情，但是您看到了結(jié)果:不穩(wěn)定、性能差的UI體驗(yàn)!

除非您在前面幾頁的解釋中睡著了，否則您現(xiàn)在已經(jīng)知道下載映像的工作(這是一個網(wǎng)絡(luò)調(diào)用)需要在與UI分開的線程上完成。

小挑戰(zhàn):您認(rèn)為哪個隊(duì)列應(yīng)該處理映像下載?回顧幾頁，做出你的決定

你選的是 userinteractive還是。userinitiated ?這樣做很有誘惑力，因?yàn)樽罱K結(jié)果對用戶是直接可見的，但實(shí)際上，如果使用了這種邏輯，就永遠(yuǎn)不會使用任何其他隊(duì)列。這里正確的選擇是使用.utility隊(duì)列。你無法控制一個網(wǎng)絡(luò)通話需要多長時間來完成，你想要操作系統(tǒng)在速度和設(shè)備的電池壽命之間取得適當(dāng)?shù)钠胶狻?/p>

3.2.1 Using a global queue

在CollectionViewController中創(chuàng)建一個新方法，開始如下:

private func downloadWithGlobalQueue(at indexPath: IndexPath) {
  DispatchQueue.global(qos: .utility).async { [weak self] in
  }
}

你最終會從collectionView(_:cellForItemAt:)調(diào)用它來執(zhí)行實(shí)際的圖像處理。首先確定應(yīng)該加載哪個URL。由于url列表是self的一部分，因此需要處理正常的閉包捕獲語義。在async閉包中添加以下代碼:

guard let self = self else {
  return
}

let url = self.urls[indexPath.item]

一旦知道了要加載的URL，就可以使用前面使用的相同數(shù)據(jù)初始化器。盡管它是一個正在執(zhí)行的同步操作，但它是在單獨(dú)的線程上運(yùn)行的，因此UI不會受到影響。在閉包的末尾添加以下內(nèi)容:

guard let data = try? Data(contentsOf: url),
      let image = UIImage(data: data) else {
  return
}

現(xiàn)在你已經(jīng)成功下載了URL的內(nèi)容并將其轉(zhuǎn)換為UIImage，是時候?qū)⑵鋺?yīng)用到集合視圖的單元格了。記住，對UI的更新只能在主線程上發(fā)生!將這個異步調(diào)用添加到閉包的末尾:

DispatchQueue.main.async {
  if let cell = self.collectionView.cellForItem(at: indexPath) as? PhotoCell {
    cell.display(image: image)
  }
}

注意，最少量的代碼被發(fā)送回主線程。在分派到主隊(duì)列之前，盡可能完成所有工作，以便UI保持盡可能的響應(yīng)性。單元分配是否讓你感到困惑?為什么不直接將實(shí)際的PhotoCell傳遞給這個方法而不是IndexPath呢?

考慮一下你在這里所做的事情的性質(zhì)。您已經(jīng)將cell的配置轉(zhuǎn)移到異步進(jìn)程。當(dāng)網(wǎng)絡(luò)下載發(fā)生時，用戶很可能會對你的應(yīng)用做一些事情，對于UITableView或UICollectionView，這可能意味著他們在滾動。在網(wǎng)絡(luò)調(diào)用結(jié)束時，該單元可能已經(jīng)被另一個映像重用，或者它可能已經(jīng)被完全丟棄。通過調(diào)用cellForItem(at:)，您在準(zhǔn)備更新單元格時獲取它。如果它仍然存在，并且仍然在屏幕上，那么您將更新顯示。如果不是，則返回nil

如果你只是簡單地傳遞一個PhotoCell并直接與那個對象交互，你會發(fā)現(xiàn)隨機(jī)的圖像被放置在隨機(jī)的單元中，當(dāng)你滾動的時候你會看到相同的圖像重復(fù)多次。
現(xiàn)在你已經(jīng)有了一個正確的圖像下載和單元格配置方法，update collectionView(_:cellForItemAt:)來調(diào)用它。用以下兩行代碼替換創(chuàng)建和返回單元格之間的所有內(nèi)容:

cell.display(image: nil)
downloadWithGlobalQueue(at: indexPath)

再次構(gòu)建并運(yùn)行你的應(yīng)用。一旦你的應(yīng)用程序開始加載圖片，滾動表格視圖。注意，滾動是多么光滑!當(dāng)然，你可能會注意到一些問題:圖片彈出和消失，加載非常緩慢，當(dāng)你滾動時不斷重新加載。您需要一種方法來啟動和取消這些請求，并緩存它們的結(jié)果，以使體驗(yàn)完美。這些都是使用操作比使用中央調(diào)度要容易得多的事情，您將在后面的章節(jié)中介紹。所以繼續(xù)閱讀!:]

使用內(nèi)置的方法

你可以看到，上面的改變是多么簡單，極大地提高了你的應(yīng)用程序的性能。然而，并不是總是需要自己抓取調(diào)度隊(duì)列。許多標(biāo)準(zhǔn)的iOS庫可以為你處理這個問題。向CollectionViewController添加以下方法

private func downloadWithUrlSession(at indexPath: IndexPath) {
  URLSession.shared.dataTask(with: urls[indexPath.item]) {
    [weak self] data, response, error in

    guard let self = self,
          let data = data,
          let image = UIImage(data: data) else {
      return
    }

    DispatchQueue.main.async {
      if let cell = self.collectionView
        .cellForItem(at: indexPath) as? PhotoCell {
        cell.display(image: image)
      }
    }
  }.resume()
}

注意，這一次，您直接使用URLSession上的dataTask方法，而不是獲取調(diào)度隊(duì)列。代碼幾乎是相同的，但是它為您處理數(shù)據(jù)的下載，因此您不必自己完成，也不需要獲取分派隊(duì)列。當(dāng)系統(tǒng)提供的方法可用時，一定要使用系統(tǒng)提供的方法，因?yàn)檫@樣不僅可以使您的代碼更經(jīng)得起時間的檢驗(yàn)，而且更容易為其他開發(fā)人員閱讀。初級程序員可能不理解調(diào)度隊(duì)列是什么，但他們理解進(jìn)行網(wǎng)絡(luò)調(diào)用。

如果你在collectionView(_:cellForItemAt:)中調(diào)用downloadWithUrlSession(at:)而不是downloadWithGlobalQueue(at:)，你應(yīng)該在再次構(gòu)建和運(yùn)行你的應(yīng)用之后看到完全相同的結(jié)果。

3.3 DispatchWorkItem

除了傳遞匿名閉包之外，還有另一種向DispatchQueue提交工作的方法。DispatchWorkItem是一個類，它提供一個實(shí)際對象來保存希望提交到隊(duì)列的代碼。
例如，以下代碼:

let queue = DispatchQueue(label: "xyz")
queue.async {
  print("The block of code ran!")
}

就像這段代碼一樣:

let queue = DispatchQueue(label: "xyz")
let workItem = DispatchWorkItem {
  print("The block of code ran!")
}
queue.async(execute: workItem)

3.4 Canceling a work item

您可能希望使用顯式DispatchWorkItem的一個原因是，您需要在執(zhí)行之前或執(zhí)行期間取消任務(wù)。如果您在工作項(xiàng)上調(diào)用cancel()，將執(zhí)行兩個操作中的一個:

• 1: 如果任務(wù)還沒有在隊(duì)列上啟動，它將被刪除。
• 2: 如果任務(wù)當(dāng)前正在執(zhí)行，則isCancelled屬性將被設(shè)置為true。

您需要定期檢查代碼中的isCancelled屬性，并采取適當(dāng)?shù)牟僮鱽砣∠蝿?wù)(如果可能的話)。

Poor man's dependencies
DispatchWorkItem類還提供了一個notify(queue:execute:)方法，該方法可用于識別在當(dāng)前工作項(xiàng)完成后應(yīng)該執(zhí)行的另一個DispatchWorkItem

let queue = DispatchQueue(label: "xyz")
let backgroundWorkItem = DispatchWorkItem { }
let updateUIWorkItem = DispatchWorkItem { }

backgroundWorkItem.notify(queue: DispatchQueue.main,
                          execute: updateUIWorkItem)
queue.async(execute: backgroundWorkItem)

請注意，當(dāng)指定要執(zhí)行的后續(xù)工作項(xiàng)時，您必須顯式地指定工作項(xiàng)應(yīng)該針對哪個隊(duì)列執(zhí)行。
如果您發(fā)現(xiàn)自己需要取消任務(wù)或指定依賴項(xiàng)的能力，我強(qiáng)烈建議您參閱第9章“操作依賴項(xiàng)”和第10章“操作取消操作和第三章 Operations

3.6 Where to go from here?

至此，您應(yīng)該對調(diào)度隊(duì)列是什么、它們用于什么以及如何使用它們有了很好的理解。試試上面的代碼示例，確保您理解它們是如何工作的。
考慮將PhotoCell傳遞到下載方法中，而不是僅僅傳遞IndexPath來查看實(shí)際中常見的錯誤類型

當(dāng)然，這個示例應(yīng)用程序有些人為設(shè)計(jì)，以便輕松地展示DispatchQueue是如何工作的。示例應(yīng)用程序還有許多其他性能改進(jìn)，但這些都需要等到第7章“操作隊(duì)列”的時候。
現(xiàn)在您已經(jīng)看到了并發(fā)的好處，下一章將向您介紹在應(yīng)用程序中實(shí)現(xiàn)并發(fā)的危險。