網(wǎng)上AFN代碼解讀和剖析的文章多如牛毛，煩不勝舉，但是真正對于一個(gè)框架系統(tǒng)全面的認(rèn)知卻是少之又少，這里寫一篇關(guān)于源碼解釋及剖析的文章，希望對你有所幫助。

源代碼架構(gòu)

項(xiàng)目結(jié)構(gòu)

這里我們只需要知道，Session封裝的是網(wǎng)絡(luò)請求會(huì)話，Serialization封裝的是請求及響應(yīng)的序列化，Security封裝的是安全策略，Reachability封裝的是網(wǎng)絡(luò)監(jiān)測工具類。

這個(gè)類中基本每一行代碼我都添加了注釋，方便大家理解。
如下面的代碼注釋

/**
 創(chuàng)建的請求緩存策略，默認(rèn)是‘NSURLRequestUseProtocolCachePolicy’

 @see NSMutableURLRequest -setCachePolicy:
 */
@property (nonatomic, assign) NSURLRequestCachePolicy cachePolicy;

/**
 創(chuàng)建請求是否使用默認(rèn)的cookie handing,默認(rèn)為YES.
 如果單個(gè)請求想不帶cookie可以設(shè)置NSMutableURLRequest的HTTPShouldHandleCookies為NO。

 @see NSMutableURLRequest -setHTTPShouldHandleCookies:
 */
@property (nonatomic, assign) BOOL HTTPShouldHandleCookies;

/**
 在收到來自較早傳輸?shù)捻憫?yīng)之前，創(chuàng)建的請求是否可以繼續(xù)傳輸數(shù)據(jù)。 默認(rèn)為“NO” 。
 通常默認(rèn)情況下請求和響應(yīng)是順序的, 也就是說請求–>得到響應(yīng)后,再請求.
 如果將HTTPShouldUsePipelining設(shè)置為YES, 則允許不必等到response, 就可以再次請求. 這個(gè)會(huì)很大的提高網(wǎng)絡(luò)請求的效率,但是也可能會(huì)出問題.
 因?yàn)榭蛻舳藷o法正確的匹配請求與響應(yīng), 所以這依賴于服務(wù)器必須保證,響應(yīng)的順序與客戶端請求的順序一致.如果服務(wù)器不能保證這一點(diǎn), 那可能導(dǎo)致響應(yīng)和請求混亂.

 @see NSMutableURLRequest -setHTTPShouldUsePipelining:
 */
@property (nonatomic, assign) BOOL HTTPShouldUsePipelining;

/**
 創(chuàng)建請求的網(wǎng)絡(luò)服務(wù)類型。默認(rèn)為‘NSURLNetworkServiceTypeDefault’
 @see NSMutableURLRequest -setNetworkServiceType:
 */
@property (nonatomic, assign) NSURLRequestNetworkServiceType networkServiceType;

項(xiàng)目地址為 AFNCodeRead

希望大家一起進(jìn)步，共同學(xué)習(xí)。