IOS學習之十七：Grand Central Dispatch（GCD）編程基礎

有過編程經驗的人，基本都會接觸到多線程這塊。

在java中以及Android開發中，大量的後台運行，非同步訊息佇列，基本都是運用了多線程來實現。

同樣在，在ios移動開發和Android基本是很類似的一種模型。

但是很多時候,在應用開發中，我們會發現本身並沒有自己編碼去處理一些並發的事件，去開闢新的子線程等等。

（雖然一般的調用sdk發起一個網路請求，系統都是會預設給你新起一個線程去處理的）。

整個程式看上去基本就是在Main線程中執行。

確實也是這樣的一種現象，因為我們基本都是在操作控制項的布局，對控制項資料添加，對於UI對象的更新都是在主線程的進行。

即便等下我們看到我們開啟了一個新的子線程用來擷取處理資料，最後還是需要通過通知UI主線程來重新整理。

當然了，ios本身也是和大部分語言一樣，有NSThread線程類（我們都知道java中我們用到這個類）。

這些系統比較底層的api類，可以被我用來書寫自己的並發線程和操作隊列。

學過Android的我們都知道Handler，Looper這個概念，Looper說白了就是一個主線程的訊息迴圈隊列，handler一般理解就是用於子線程和UI主線程一些資料互動。

看了下ios的GCD特性，發現他們之間頗有幾分相似。

 1.下面來看下如何使用gcd編程的非同步

        dispatch_async(dispatch_get_global_queue(0, 0), ^{        // 處理耗時操作的代碼塊...                //通知主線程重新整理        dispatch_async(dispatch_get_main_queue(), ^{            //回調或者說是通知主線程重新整理，        });            });

dispatch_async開啟一個非同步作業，第一個參數是指定一個gcd隊列，第二個參數是分配一個處理事物的程式塊到該隊列。

dispatch_get_global_queue(0, 0)，指用了全域隊列。

一般來說系統本身會有3個隊列。

global_queue，current_queue,以及main_queue.

擷取一個全域隊列是接受兩個參數，第一個是我分配的事物處理常式塊隊列優先順序。分高低和預設，0為預設2為高，-2為低

#defineDISPATCH_QUEUE_PRIORITY_HIGH  2#defineDISPATCH_QUEUE_PRIORITY_DEFAULT  0#defineDISPATCH_QUEUE_PRIORITY_LOW (-2)

處理完事物後，需要將結果返回給或者是重新整理UI主線程，同樣，和上面一樣，抓取主線程，程式塊操作。

//天啊，手賤不小心點到了home間，會退後發現沒儲存~~~寫的並發一塊內容都沒了！！！

二：GCD之並發概念

其實對於編程中，我們一直提及到的幾個概念，同步，非同步，並發，鎖等。

有時覺得一下子還真說不清。

下面我們以上面提到的圖片載入來看下這3個概念我的理解

1同步：

   for (int i = 0 ; i < 10; i++) {               UIImage *img = [self getImgeWith:[urlArr objectForIndex:i]];          [myImgV[i] setImage:img];            }

假設我要載入10個圖片，我現在擁有這些圖片的資源地址，儲存在一個數組中。

我們先以擷取第一張圖片來舉例：

同步執行的概念就是，我擷取完第一張圖片的，

執行了for迴圈第一句返回了img後，我才能執行第二句，UI介面的重新整理。

如果第一句返回的時間需要10秒，那我程式的響應就彷彿一直卡在這裡一樣，我無法進行其他動作。必須等它返回！！

因此，同步的一個很好理解的感念就是，一步走到黑。

2.非同步

  for (int i = 0 ; i < 10; i++) {        dispatch_async(dispatch_get_global_queue(0, 0), ^{        // 處理耗時操作的代碼塊...         UIImage *img = [self getImgeWith:[urlArr objectForIndex:i]];        //通知主線程重新整理        dispatch_async(dispatch_get_main_queue(), ^{            //回調或者說是通知主線程重新整理，              [myImgV[i] setImage:img];        });            });

看了這代碼，我們會說，非同步作業那個假設還是要10秒啊，總體看來，執行一張圖片的時間載入還是要在10秒左右啊，

貌似非同步沒什麼鳥用麼。但是，別忽略了其中一點，也黑絲核心的一點，此時我們圖片擷取操作放在裡一個線程隊列裡，

此刻，雖然我們看著圖片的載入還是需要10秒才會出來，但是，在這10秒期間，我們的UI主線程是可以操作的，比如介面上有個按鈕，你是可以按的

而不是如上面的同步，在10面期間，我是只能乾等著，什麼都做不了。

非同步核心概念就是一個新線程，一個訊息回調通知。

3.並行

我們還是以上代碼為例。前面我強調了，我們只看一張圖片的載入，現在，回到我們第一眼看到代碼的思維上去，

一個for迴圈。其實上面代碼過後，我是建立了10個非同步線程。

好吧，到此，我們應該明白這三個概念了。

同步，其實我前面的例子舉得有些局限，就是這個例子本身就說明不需要同步執行，然後給大家大感覺是

同步是編程中一個忌諱點一樣，其實不然，很多時候。我們真是需要同步來做一些限制（比如線程中提出的同步鎖？聽著就感覺有用麼

雖然可能並不如我們想的那樣的運用同步，但是至少說明這個概念同樣是有用的）

我還是以剛才那個載入圖片為例子，來個簡單的說明如何運用同步的好處。

當然，我只是類比一個同步的情況。

假設我們現在圖片的載入是這樣的，圖片本身為在載入前是一個預設的圖片，上面寫著，點擊我載入，點擊後會調用網路載入方法，然後圖片顯示載入中，

然後我們雙擊圖片時（當然，理論上是在載入完後）讀取圖片網狀圖片放大，好吧，到這裡應該能想到要表達的情況了。

整個流程應該是點擊圖片->載入->雙擊查看。那如果成了點擊->載入中(以返回了圖片的作者和資訊)-》雙擊圖片(通過前面請求返回的大圖連結顯示大圖)-》

完全載入返回（返回了大圖連結）。此時我們看不到映像的大圖了。因為我們操作在返回前了，也就是說，

很多時候，我們下一個動作的操作必須需要用到前面一個操作的資料時，我們會給他做認為的同步編程，比如加個按鈕鎖。

這是我們又會疑惑道，下一個執行需要用到前一個執行的，那第一個例子中的for迴圈的第二句不是要用到麼，這麼說

他們必須要同步啊，如果你這麼想了，好巧，我們想到一塊去了~

但是，注意，前面我們到的非同步是為瞭解決我點擊其他按鈕的操作，而不是說更新UI操作。下載和更新UI操作在我們看來必須是同步的

這是對的，但是那種做導致了系統本身一些監聽事件監聽到點擊處理在那個請求之後了，這邊的載入圖片其實要看成一次事件執行，

因為對於事件的這一抽象單元，其實是一種可人為定義的寬廣度。

也就是說，一次資料擷取和映像填充，其實算是一個映像擷取載入事件，事件可以說包含兩個單元，載入和填充。

而整個這個事件對於我們點擊其他按鈕並無關係，那麼也就說明了無需同步。

有道理啊，但是若果我們要點擊這個圖片呢，也就是回到剛才那個可以雙擊的假設。

此處也許我麼又忽略了一點為什麼載入中我們能點擊雙擊呢，也就這樣的假設是擷取圖片已經做了非同步，但是我們下一步操作又是需要同步的

因此做了人為的同步鎖定。

好了，說的太多了，當時至少我們明白兩點

非同步可能是為了反正耗時操作造成的主線程堵塞，

同步是為瞭解決一些不必要錯誤和麻煩。也許到這裡，我們腦中會聯想到的所謂的執行緒安全性。

其實同步以及同步鎖，卻是應該是考慮到這樣的不必要和不安全因素。

最後在簡單闡述下非同步和並發關係。

其實看了上面說的，非同步只是提供了一種多執行緒的概念，

並發是更像是非同步一種大規模實現。

就好比說，非同步提出了可以用小弟去收保護費，收完了告訴並交給自己，而我在期間做其他要做的事。

並發突然想到，非同步這個很有道理啊，那我有4個地方要收，一個小弟去收，雖然我還是可以閑著做其他的事，

但是小弟跑四個地方，我拿到錢所需要的時間還是和我自己去收一樣的，只不過我不用那麼費勁了，還能做其他事了。

因此，並發覺得應該派四個小弟去，因為每個場地的保護費各不相干的。（剛看了個紐約黑幫~）。

因此說，非同步解決了線程堵塞，而並發則是在非同步基礎上，提高了符合特性事件的處理時間效率。

當然，如果10個圖片本身相互間是沒什麼聯絡，但是，最後一個事件需要處理計算這10個圖片的總容量值。

那麼可以用 dispatch_group_async。

具體就看文檔吧。

總體來說，看了iosGCD這塊，一是讓我熟悉了block編程特性，還有是熟悉如何使用ios提供的GCD特性

來完成多線程編程。