對于iOS開發(fā)中的網(wǎng)絡(luò)請求模塊，AFNetworking的使用應(yīng)該是最熟悉不過了，但你是否把握了網(wǎng)絡(luò)請求正確的完成時機？什么是信號量？

1.先說什么是信號量。

信號量：就是一種可用來控制訪問資源的數(shù)量的標(biāo)識，設(shè)定了一個信號量，在線程訪問之前，加上信號量的處理，則可告知系統(tǒng)按照我們指定的信號量數(shù)量來執(zhí)行多個線程。其實，這有點類似鎖機制了，只不過信號量都是系統(tǒng)幫助我們處理了，我們只需要在執(zhí)行線程之前，設(shè)定一個信號量值，并且在使用時，加上信號量處理方法就行了。

信號量有3個函數(shù)，分別是：

創(chuàng)建信號量，參數(shù)：信號量的初值?

dispatch_semaphore_create（信號量值）

等待降低信號量 ?dispatch_semaphore_wait（信號量，等待時間）

提高信號量?dispatch_semaphore_signal(信號量)

2.在真實開發(fā)中，我們通常會遇到如下問題：

①一個界面存在多個請求，希望所有請求完成之后才去進(jìn)行下面的操作。

解決方案很容易想到通過線程組進(jìn)行實現(xiàn)。代碼如下：

打印結(jié)果如下：

打印結(jié)果觀察可能并沒有什么問題，但需要注意的是request1 request2 request3等在真實開發(fā)中通常對應(yīng)為某個網(wǎng)絡(luò)請求。而網(wǎng)絡(luò)請求通常為異步，那這時是否還會有同樣結(jié)果呢?

我們換成真是的網(wǎng)絡(luò)請求再看一下。

對于App請求數(shù)據(jù)大部分人都會選擇AFNetworking。使用AFN異步請求，請求的數(shù)據(jù)返回后，就刷新相關(guān)UI。如果某一個頁面有多個網(wǎng)絡(luò)請求，我們假設(shè)有三個請求，request1、request2、request3，而且UI里的數(shù)據(jù)必須等到request1、request2、request3全部完成后刷新后才顯示。

這里我們書寫一個網(wǎng)絡(luò)請求通用方法。使用我們最常用的AFNet請求，方法如下：

request2 request3分別請求對應(yīng)的下面的數(shù)據(jù)，就不重復(fù)寫了，文章末尾會把demo地址附上，感興趣的可以下載來看一下。

打印結(jié)果如下：

運行后馬上接收到了線程組完成的提示，之后數(shù)據(jù)才依次請求下來，很明顯三個單純的AFNetworking請求已經(jīng)不能滿足我們的需求了。線程組完成時并沒有在我們希望的時候給予通知。在真實開發(fā)中會造成的問題為多個請求均加載完成，但界面已在未得到數(shù)據(jù)前提前刷新導(dǎo)致界面空白。

這里我們就要借助GCD中的信號量dispatch_semaphore進(jìn)行實現(xiàn)，即營造線程同步情況。

dispatch_semaphore信號量為基于計數(shù)器的一種多線程同步機制。用于解決在多個線程訪問共有資源時候，會因為多線程的特性而引發(fā)數(shù)據(jù)出錯的問題。

如果semaphore計數(shù)大于等于1，計數(shù)-1，返回，程序繼續(xù)運行。如果計數(shù)為0，則等待。

dispatch_semaphore_signal(semaphore)為計數(shù)+1操作。dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER)為設(shè)置等待時間，這里設(shè)置的等待時間是一直等待。

把網(wǎng)絡(luò)請求進(jìn)行如下修改：

通過信號量dispatch_semaphore完美的解決了此問題，并且網(wǎng)絡(luò)請求仍為異步，不會堵塞當(dāng)前主線程。

實例地址：點擊去下載