Swift 3學習指南：重新認識GCD應用

CPUs(中央處理器)問世以來，最棒的改革之一就是發展多核心技術，藉此可運行多個執行緒，這代表著，我們可以在同一時間執行多個任務。

依序執行任務(非並行)或是fake multitasking是多年前使用的運行模式，只要你的年紀稍長，應該可以記得過去的老舊電腦，若是你曾經使用過老舊的系統，應該可以輕易的了解到我在說什麼，但是，不管多少個核心的CPU可以帶來多厲害的效能表現，如果開發者不曉得如何使用這些技術，那都是沒有用的，本文就是要介紹多工與多執行緒的編程如何實作，開發者必須在任何裝置上善用CPU多工(multitasking)的優勢，將程式拆分為多個區塊分配在多個執行緒中平行運作。

使用多執行緒的好處很多，最重要的一點就是縮減執行任務所需時間，提供較佳的使用體驗，在運行時不會有停留在某個畫面的延遲感，請想想看，若是有一個應用程式，它將一大串的images都堆放在主執行緒處理，那UI必須等到全部下載任務完成才會有反應，使用者不會想嘗試使用這樣的應用程式。

在iOS當中，蘋果提供兩個方法來實作多工任務:包含Grand Central Dispatch (GCD)以及NSOperationQueue的frameworks，它們都可以幫助開發者達到多個任務分配給多個執行緒或不同queues(佇列)進行同步運行的需求，本文我們將會專注在GCD實作應用上。不管如何，這邊有一個規則必須要遵守:主執行緒必須總是維持在閒置狀態，用於應付使用者操作觸發的介面變化，任何耗時的任務應該跑在concurrent或是background的佇列，這對於新進開發者來說可能難以消化及應用，但它仍是應該去使用的方法。

GCD(Grand Central Dispatch)在iOS4才第一次被介紹出來，當我們嘗試去執行並發任務時，它提供很有彈性的應用，其實，直到Swift 3推出之前，我認為它有一個很大的缺點:就是很難記得GCD的相關語法，過去它的coding style比較像底層的C語言，與Swift甚至是Objective-C的其他coding style有顯著的差異，這也是為何在過去多數開發者盡可能使用NSOperationQueue，避免使用到GCD的原因，但是在最新的Swift版本中，GCD語法將可以給你很好的使用體驗，讀者可以在web簡單查詢看看。

在Swift 3推出後，它有了很顯著的改變，GCD使用起來不一樣了，完全是Swift風格的語法，GCD最新的語法可以讓開發者更容易使用，這樣的改變，也讓我迫不及待想寫這篇文章，與讀者分享GCD在Swift 3之中，所提供最基礎但也最重要的實作應用，如果你過去已經接觸過GCD舊的coding style(即使只有一點點)，接下來使用新的語法對你而言將是小事一樁，若是過去沒有碰觸過GCD，接下來就跟著本文一起學習程式的新篇章。

在我們進入本文的特定主題前，先來談一些具體觀念，首先，GCD裡面的關鍵詞彙為dispatch queue，不論是在主執行緒或是背景執行緒上，一個佇列實際上是一個可同步或非同步執行的代碼塊，當一個佇列被生成後，作業系統會將把它分配到CPU上的任一核心上，多個佇列同樣會被相對應管理，這部分的工作開發者不需要去處理，佇列會遵循FIFO的模式(先進先出)，代表一個佇列先被執行就會先完成工作(可以想像成在櫃檯前排隊等待的人，排在第一位的人就會先被服務，最後一位則會最後被服務)，等下我們會透過實例進行更清楚的解析。

再來，另外一個重點觀念是work item，它是與佇列創建時一起編寫的代碼塊，會被分配到佇列裡面且可以被多次使用，完全如你所想:它是dispatch queue將運行的程式碼，在執行時也遵守FIFO規則，可以選擇同步或非同步的執行方式，在同步模式中，應用程式運行時在任務執行結束前將不會離開這個item的代碼塊，另外一方面，若是佇列被安排為非同步運行，應用程式將會呼叫對應的work item代碼塊，並於工作完成後回傳，再次提醒，後面的篇幅將透過實例看到兩者的不同。

簡單介紹dispatch queues和work items之後，該是時候更深入介紹佇列，它可以設為serial或是concurrent，在第一個情境下，一個work item必須等待前一個結束後才會開始執行(除非它第一個被排入到佇列)，第二個情境則是可以讓各個work item同時運行。

你在把任務配發到應用程式主佇列(main queue)時都必須很小心，它應該要總是維持在閒置可用的狀態，藉以應付使用者操作帶來介面變動需求，順帶一提，每個UI變更的動作都必須要在主執行緒執行，如果你曾經嘗試在背景執行緒(background thread)更新你的UI，會發現畫面更新的動作無法保證會在何時啟動，這將會讓你得到不愉快的體驗，然而，在UI創立或更新前必須先完成的工作，絕對要在背景進行作業，舉例來說，你可以在背景執行緒進行圖片下載工作，但是要將更新image view的工作放在主執行緒進行。

請記住，我們不總是需要去建立自己的佇列，系統會建立global dispatch queues供你指定的任務使用，至於佇列會在哪一個執行緒運行，iOS設有一個a pool of threads(執行緒池)，意指除主執行緒之外的執行緒集合，系統會挑選一個以上的執行緒來使用(依照你建立的佇列數量，以及建立方式)，哪一個執行緒會被使用並不是由開發者定義，操作系統會依據並發任務的數量，處理器上的負載等事項來決定，但是說實話，誰想處理上述所有工作呢？

我們的測試環境

本文中，接下來我們將會使用的幾個小範例來介紹GCD觀念，一般來說，我們只要使用Xcode Playground即可達到示範工作，不需要特別實作一個demo app，但是在使用GCD時無法如願，因為在Playgrounds裡面無法從不同的執行緒中呼叫函式，儘管我們的一些範例可以在這上面運行，但不是全部，所以本文仍將透過一個專案實作來克服潛藏的問題，你可以在這裡下載並且打開它。

這個專案幾乎是空的，除了下列兩個檔案以外:

1. 在ViewController.swift檔案中看將看到一串函式被定義，但是尚未被實作。每一個都會帶領我們認識GCD的新特性，你要做的事情就是在viewDidAppear(_:)裡面將註解符號拿掉，讓這些函式被喚醒。
2. 在Main.storyboard裡面的ViewController畫面中，你將發現一個image view被加入，而且對應的IBOutlet已經連結到ViewController類別中。
   晚一點我們將會需要那個image view供一個真實案例使用。

現在讓我們開始吧。

認識 Dispatch Queues

在Swift 3裡面,建立一個新的dispatch queue最簡單的方式如下：

let queue = DispatchQueue(label: "com.appcoda.myqueue")

你唯一要做的就是提供一個唯一的label給這個佇列，反向的DNS符號(com.appcoda.myqueue)很容易建立出獨一無二的labels，甚至連Apple也建議這樣的寫法，儘管如此，但它並不是強制性的，你可以使用任何你想要的字串，只是必須維持它的唯一性，除此之外，上述程式碼不只是佇列的初始化作業，你也可以提供更多參數在初始化動作中，我們將會在之後篇幅談論到它。

佇列一旦被建立後，我們就可以透過程式碼使用它，同步則使用sync函式，若非同步則呼叫async函式，當我們開始時，先提供一段code當做一個block(closure)，接著，我們將初始化它，並使用dispatch work items的物件 (DispatchWorkItem)去取代block(請注意，在佇列裡面block也被當作是一個work item)，我們將以同步的方式開始執行，要做的只是列出0~9的數字:

使用紅點可以讓我們在console內較容易識別，尤其是當我們添加更多的佇列或任務去執行時。

將上圖內的程式碼複製並貼在ViewController.swift檔案的simpleQueues()函式內，確認這個函式在viewDidAppear(_:)裡面沒有被註解掉，接者把這個專案跑起來，請看一下Xcode console，發現結果並無法讓我們對GCD的運作做出任何結論，所以請更新simpleQueues()函式內的程式碼，在佇列的closure後面加入另一個代碼塊，它用來呈現100~109數字(僅用於區別數字不同)。

for i in 100..<110 {
    print("Ⓜ️", i)
}

上述的forloop迴圈將會在主佇列被執行，第一個迴圈則將在背景運行，程式執行的動作會在佇列的block中停止，且直到佇列任務完成前，它將不會繼續主執行緒迴圈，無法呈現100到109的數字，這是因為我們使用同步執行，讀者可以在console中看到輸出結果:

但是如果我們使用async函式運行會發生什麼事情呢？請將佇列裡的程式塊以非同步方式執行，這個案例中，程式不會先等到佇列任務完成才進行下一步，它將立即返回到主執行緒，而第二個for loop迴圈也將與佇列迴圈同時執行，在我們看看會發生什麼事之前，先將佇列改為使用async執行。

現在，將專案行起來，並且看看Xcode的console輸出結果:

相較於同步執行，這個範例看起來有趣多了，你可以看到程式碼在主佇列(第二個for loop迴圈)以及dispatch queue裡面的程式碼是同時運行的，這個自行定義佇列實際上花費較多運行時間，但這就是優先處理事項的排列關係(接下來將會看到)，這裡主要想強調的是，當我們另一個任務在背景執行時，主佇列是閒置隨時準備使用的狀態，這個運作模式不會出現在同步執行的佇列。

即使上述的範例相當簡單，但已經很清楚的展示了一個程式的佇列在同步以及非同步情況下的運作方式，我們將在接下來的範例繼續保持富有色彩的console輸出效果，請記住，特定顏色代表特定的佇列內部程式碼運行結果，不同顏色就代表不同的佇列。

Quality Of Service (QoS) and Priorities

在使用GCD與dispatch queues時，我們經常會需要告訴系統，你的應用程式中哪個任務比較重要，需要優先去執行，當然，由於主佇列都是用來處理UI接收到的指令，所以跑在主執行緒的任務是最優先執行的，在任何情況下，都必須根據自身需求提供佇列執行的優先順序以及其他需要的資訊(例如在CPU上的執行時間)給系統，雖然所有的任務最終都將完成。然而，區別在於哪些任務會更快完成，哪些任務會較晚完成。

關於任務的重要性及優先順序的資訊在GCD稱為Quality of Service (QoS)，QoS是一個包含特定情境的enum，根據你想要的優先順序，提供一個適當的QoS值在佇列初始化作業，如果沒有特別定義，佇列則預設為 default priority，可使用的相關選項介紹可參考這裡, 下列則整理QoS可選擇的項目，它們被稱做QoS classes，第一個class代表最高順位，最後一個則代表最低順位。

• userInteractive
• userInitiated
• default
• utility
• background
• unspecified

現在回到專案中，我們將使用queuesWithQoS()進行作業，先宣告並初始化下列兩個新的dispatch queues:>

let queue1 = DispatchQueue(label: "com.appcoda.queue1", qos: DispatchQoS.userInitiated)
let queue2 = DispatchQueue(label: "com.appcoda.queue2", qos: DispatchQoS.userInitiated)

注意，這邊對它們設定相同的QoS class，所以在執行時的優先順序是相同的，就像我之前做的，第一個佇列將包含一個for loop 迴圈，用來呈現0~9的數字(外加一個紅點)，而在第二個佇列我們將執行另一個for loop迴圈，展示100~109數字(附加一個藍點)。

看到執行結果可以知道它們佇列被設定相同的優先順序(QoS class相同)-不要忘記在viewDidAppear(_:)裡將queuesWithQos()的註解取消(uncomment):

很輕易的可以看到上面截圖的任務被"均勻" 的執行，這就是我們預期的結果，現在，將queue2的QoS class改為utility(較低的順序)，如下圖所示:

let queue2 = DispatchQueue(label: "com.appcoda.queue2", qos: DispatchQoS.utility)

看看現在發生了什麼事:

不要懷疑，由於被賦予更高的優先權，第一個dispatch queue(queue1)較第二個更快被執行，即使queue2在第一個佇列開始運行後隨即得到執行的機會，但由於第一個佇列被標記為較重要的任務，所以系統將資源主要提供給它，當它完成後，系統才會去關心第二個佇列。

讓我們進行另一個練習，是時候將第一個佇列的QoS class更改為background:

let queue1 = DispatchQueue(label: "com.appcoda.queue1", qos: DispatchQoS.background)

它被賦予的優先權幾乎是最低的，所以讓我們看一下程式碼運行時發生了什麼事情:

由於QoS class設定為utility比background擁有更高的優先權，因此，這次第二個佇列比較快跑完。

上述的範例讓我們清楚了解QoS classes如何運作，但是如果我們將任務跑在主佇列會發生什麼事情呢？請將下列的程式碼加入到我們的函式尾端:

for i in 1000..<1010 {
    print("Ⓜ️", i)
}

同時，也將第一個佇列的QoS class做更改，將優先順序設定為更高層級:

let queue1 = DispatchQueue(label: "com.appcoda.queue1", qos: DispatchQoS.userInitiated)

下圖為輸出結果:

我們再一次看到主佇列預設有較高的優先權，queue1的dispatch queue與主要的佇列並發執行，queue2則是最後完成，而且當另外兩個佇列內的任務正在執行時，它沒有太多機會可以被執行到，這就是因為被設定成較低的執行順序。

Concurrent Queues

在目前為止，我們分別看到了dispatch queues同步與非同步的作業情況，以及系統設定的Quality of Service class如何影響執行的優先順序，先前的範例都是將我們的佇列設為serial，這表示如果我們賦予一個以上的任務給任何的佇列，這些任務將是依序被執行，而非一起被執行，接下來，我們將看到如何在同一時間運行多個工作任務(work items)，換句話說，下面我們將會實作concurrent queue。

在這個專案中，我們將使用concurrentQueues()函式(請在viewDidAppear(_:)將對應的程式碼取消註解)，在這個新的函式將會建立一個新的佇列:

let anotherQueue = DispatchQueue(label: "com.appcoda.anotherQueue", qos: .utility)

現在，將下列的任務(或是稱為work items)丟給這個佇列:

當程式碼運行時，這些任務將依序被執行，下面截圖可以看得更清楚:

接下來，請修改anotherQueue的初始化方法:

let anotherQueue = DispatchQueue(label: "com.appcoda.anotherQueue", qos: .utility, attributes: .concurrent)

上面的初始化動作有添加一個新的參數: attributes。這個參數我們帶入concurrent，所以全部的任務在這個佇列上會同時被執行，如果你不使用這個參數，佇列會被設定為serial，事實上，QoS參數也並不是必須的，若是在初始化作業中，我們將這些參數拿掉也是沒有任何問題的。

再一次運行這個app，我們可以注意到，任務都被並發執行了:

注意，改變任務執行的QoS class也會被影響，儘管如此，只要在初始化時將佇列設定為concurrent，這些任務將會以並發方式執行，它們會擁有各自的運行時間。

attributes參數也可以接受另外一個稱為initiallyInactive的值，如果使用這個值，這些任務不會被自動執行，開發者必須去觸發這個執行動作，我們接下來將會說明，但需要先做一些修改。首先，聲明一個名為inactiveQueue </ code>的類別屬性，如下圖所示:

var inactiveQueue: DispatchQueue!

let anotherQueue = DispatchQueue(label: "com.appcoda.anotherQueue", qos: .utility, attributes: .initiallyInactive)
inactiveQueue = anotherQueue

if let queue = inactiveQueue {
    queue.activate()
}

let anotherQueue = DispatchQueue(label: "com.appcoda.anotherQueue", qos: .userInitiated, attributes: [.concurrent, .initiallyInactive])

let delayQueue = DispatchQueue(label: "com.appcoda.delayqueue", qos: .userInitiated)

print(Date())

let additionalTime: DispatchTimeInterval = .seconds(2)

delayQueue.asyncAfter(deadline: .now() + additionalTime) {
    print(Date())
}

delayQueue.asyncAfter(deadline: .now() + 0.75) {
    print(Date())
}

let globalQueue = DispatchQueue.global()

let globalQueue = DispatchQueue.global(qos: .userInitiated)

DispatchQueue.main.async {
    // Do something
}

func fetchImage() {
    let imageURL: URL = URL(string: "http://www.appcoda.com.tw/wp-content/uploads/2015/12/blog-logo-dark-400.png")!

    (URLSession(configuration: URLSessionConfiguration.default)).dataTask(with: imageURL, completionHandler: { (imageData, response, error) in

        if let data = imageData {
            print("Did download image data")
            self.imageView.image = UIImage(data: data)
        }
    }).resume()
}

if let data = imageData {
    print("Did download image data")

    DispatchQueue.main.async {
        self.imageView.image = UIImage(data: data)
    }
}

let workItem = DispatchWorkItem {
    // Do something
}

func useWorkItem() {
    var value = 10

    let workItem = DispatchWorkItem {
        value += 5
    }
}

workItem.perform()

let queue = DispatchQueue.global()
queue.async {
    workItem.perform()
}

queue.async(execute: workItem)

workItem.notify(queue: DispatchQueue.main) {
    print("value = ", value)
}

func useWorkItem() {
    var value = 10

    let workItem = DispatchWorkItem {
        value += 5
    }

    workItem.perform()

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

    queue.async(execute: workItem)

    workItem.notify(queue: DispatchQueue.main) {
        print("value = ", value)
    }
}