最近重讀了AFNetworking 3.x的源碼，算是溫故而知新吧。也梳理了一些優秀的代碼細節和麵試考點，羅列下來，發現這個庫小而精緻，簡直初學者的寶藏庫。 開源庫怎麼看？ 先說個題外話，閱讀優質的開源代碼庫，絕對是程式員們快速提升自我的有效途徑，而怎樣高效率的去閱讀源碼同樣也是一個問題，不知道有沒 ...
最近重讀了AFNetworking 3.x的源碼，算是溫故而知新吧。也梳理了一些優秀的代碼細節和麵試考點，羅列下來，發現這個庫小而精緻，簡直初學者的寶藏庫。
開源庫怎麼看？
先說個題外話，閱讀優質的開源代碼庫，絕對是程式員們快速提升自我的有效途徑，而怎樣高效率的去閱讀源碼同樣也是一個問題，不知道有沒有人和我之前一樣，碰到過讀倒是讀了，但總感覺收穫不大的情況。
這裡分享一下我的一些讀碼經驗：
-
多思考，多拋出問題，比如說
- 整體的代碼結構是怎樣的？類與類之間的關係是怎樣的？為什麼要這麼設計？
- 代碼有沒有涉及到多線程，其線程模型是怎樣的？哪類問題可以適用這種多線程的方案？
- 代碼中使用了哪些設計模式？具體是怎麼實現的？
-
也可以關註代碼細節，遇到不熟悉的用法不要放過，多刨根究底才能夯實基礎
關於
AFNetworking的一些優秀代碼細節，我這裡也整理了一部分，可以查閱後文 -
一定要記筆記和總結，能分享更好。
參考費曼學習法，我認為這一點是最好的加深理解和強化記憶的手段。隨著年齡的增大，記憶力會有所衰退，有個筆記能夠回顧，能節約大把再次記憶的時間。此外，多與人分享還能夠提升自己的影響力，與人交流驗證，也能夠為自己查缺補漏。
AFNetworking 3.x的代碼結構
還是說回到AFNetworking這裡，AF的代碼結構大部分人應該都瞭解，這裡我簡單介紹下。AFNetworking 3.x的代碼結構比2.x要簡單許多，主要也得益於蘋果優化了網路相關的api，整體代碼有這麼幾部分：
-
AFURLSessionManager/AFHTTPSessionManager
這裡就是AF代碼的核心了，主要負責網路請求的發起，回調處理，是在系統網路相關API上的一層封裝。大部分邏輯是在
AFURLSessionManager裡面處理的，AFHTTPSessionManager則是專為HTTP請求提供了一些便利方法。如果需要擴展其他協議的功能（比如FTP協議），可以考慮從AFURLSessionManager創建一個子類。 -
AFURLRequestSerialization/AFURLResponseSerialization
這兩兄弟主要處理一些參數序列化相關的工作。
AFURLRequestSerialization是將傳入的參數構造成NSURLRequest，比如自定義的header，一些post或者get參數等等。AFURLResponseSerialization主要是將系統返回的NSURLResponse處理成我們需要的responseObject，比如json、xml、image等等 -
AFSecurityPolicy
處理https相關的公鑰和驗證邏輯。目前由於蘋果ATS的開啟，基本HTTPS已經成為標配。雖然通常直接使用CA來驗證伺服器公鑰的情況下，不需要我們額外做什麼配置。但是從這裡出發，順便考察一下HTTPS相關的知識點，感覺也比較常見，具體面試題可看下文
-
AFNetworkReachabilityManager
這個其實是比較獨立的一個模塊了，提供獲取當前網路狀態的功能。
-
UIKit+AFNetworking
這裡主要是通過Category來提供了一下UIkit的便利方法
AF的一些優質代碼細節
仔細瞅瞅代碼之後，發現常見的OC基礎知識在AF裡面都有具體應用，挺多還是面試題考點，這裡也是做個記錄和梳理。
- 單例的創建方法
+ (instancetype)defaultInstance { static AFImageDownloader *sharedInstance = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ sharedInstance = [[self alloc] init]; }); return sharedInstance; }
必知必會，通過dispatch_once來保證多線程調用時，只有一個實例被創建。
- dispatch_sync與dispatch_barrier_sync配合解決並行讀串列寫問題
// 註意是並行隊列 self.requestHeaderModificationQueue = dispatch_queue_create("requestHeaderModificationQueue", DISPATCH_QUEUE_CONCURRENT); // 串列寫，註意barrier block的具體執行時機 dispatch_barrier_sync(self.requestHeaderModificationQueue, ^{ [self.mutableHTTPRequestHeaders setValue:value forKey:field]; }); // 並行讀，註意和上面寫操作同時執行時的執行順序 NSDictionary __block *value; dispatch_sync(self.requestHeaderModificationQueue, ^{ value = [NSDictionary dictionaryWithDictionary:self.mutableHTTPRequestHeaders]; });
必知必會，GCD使用barrier來處理並行讀串列寫問題的具體用法
- weakSelf與strongSelf的用法
__weak __typeof(self)weakSelf = self; AFNetworkReachabilityStatusCallback callback = ^(AFNetworkReachabilityStatus status) { __strong __typeof(weakSelf)strongSelf = weakSelf; strongSelf.networkReachabilityStatus = status; if (strongSelf.networkReachabilityStatusBlock) { strongSelf.networkReachabilityStatusBlock(status); } return strongSelf; };
必知必會，weakSelf避免迴圈引用，strongSelf保證block內部執行過程中self不會被釋放
-
其他用法
NSSecureCoding、kvo、swizzle、NSStream、NSProgress、代碼註釋、pragma mark等等
AFNetworking的可能面試考點
前面提到閱讀開源庫時，要多思考多提問題，這裡也結合一些面試考題來梳理下
AFNetworking 2.x怎麼開啟常駐子線程？為何需要常駐子線程？
這個知識點應該是AF2.x版本面試官比較喜歡問的了，AF2.x版本有個細節，通過runloop開啟了一個常駐子線程，具體代碼是這樣的：
+ (void)networkRequestThreadEntryPoint:(id)__unused object { @autoreleasepool { [[NSThread currentThread] setName:@"AFNetworking"]; NSRunLoop *runLoop = [NSRunLoop currentRunLoop]; [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode]; [runLoop run]; } } + (NSThread *)networkRequestThread { static NSThread *_networkRequestThread = nil; static dispatch_once_t oncePredicate; dispatch_once(&oncePredicate, ^{ _networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil]; [_networkRequestThread start]; }); return _networkRequestThread; }
首先，我們要瞭解為何要開啟常駐子線程？
NSURLConnection的介面是非同步的，然後會在發起的線程回調。而一個子線程，在同步代碼執行完成之後，一般情況下，線程就退出了。那麼想要接收到NSURLConnection的回調，就必須讓子線程至少存活到回調的時機。而AF讓線程常駐的原因是，當發起多個http請求的時候，會統一在這個子線程進行回調的處理，所以乾脆就讓其一直存活下來。
上面說的一般情況，子線程執行完任務就會退出，那麼什麼情況下，子線程能夠繼續存活呢？這就涉及到第二個問題了，AF是如何開啟常駐線程的，這裡實際上考察的是runloop的基礎知識。
關於runloop，推薦看下《iOS底層原理總結 - RunLoop》，個人覺得講得非常詳盡。這裡簡單來說，當runloop發現還有source/timer/observer的時候，runloop就不會退出。所以AF這裡就通過給當前runloop添加一個NSMachPort，這個port實際上相對於添加了一個source事件源，這樣子線程的runloop就會一直處於迴圈狀態，等待別的線程向這個port發送消息，而實際上AF這裡是沒有消息發送到這個port的。
除了AF的這種處理方式，實際上蘋果也提供了回調線程的解決方案：
// NSURLConnection - (void)setDelegateQueue:(nullable NSOperationQueue*) queue // NSURLSession + (NSURLSession *)sessionWithConfiguration:(NSURLSessionConfiguration *)configuration delegate:(nullable id <NSURLSessionDelegate>)delegate delegateQueue:(nullable NSOperationQueue *)queue;
蘋果提供了介面，可以讓你制定一個operationQueue供回調執行。所以AF3.x的時候，就直接創建了一個併發度為1的隊列，來處理回調。
擴展問題：
既然提到了runloop，可以考慮一下runloop的擴展問題：
- 子線程預設有runloop嗎？runloop創建和銷毀的時機又是什麼時候呢？
- runloop有哪些mode呢？滑動時發現定時器沒有回調，是因為什麼原因呢？
- 除了上面這種addPort來保活線程的方法，有無其他方法呢？
AFURLSessionManager與NSURLSession的關係，每次都需要新建mananger嗎？
我們如果仔細查看代碼，應該就能得出這樣的結論：manager與session是1對1的關係，AF會在manager初始化的時候創建對應的NSURLSession。同樣，AF也在註釋中寫明瞭可以提供一個配置好的manager單例來全局復用。
那麼復用manager實際上就是復用了session，而復用session可以帶來什麼好處呢？
其實iOS9之後，session就開始支持http2.0。而http2.0的一個特點就是多路復用（可參考《Http系列(二) Http2中的多路復用》）。所以這裡復用session其實就是在利用http2.0的多路復用特點，減少訪問同一個伺服器時，重新建立tcp連接的耗時和資源。
官方文檔也推薦在不同的功能場景下，使用不同的session。比如：一個session處理普通的請求，一個session處理background請求；1個session處理瀏覽器公開的請求，一個session專門處理隱私請求等等場景。
AFSecurityPolicy如何避免中間人攻擊？
現在，由於蘋果ATS的策略，基本都切到HTTPS了，HTTPS的基本原理還是需要瞭解一下的，這裡不做介紹，需要的可以google查閱一下相關文章。
通常，首先我們要瞭解中間人攻擊，大體就是黑客通過截獲伺服器返回的證書，並偽造成自己的證書，通常我們使用的Charles/Fiddler等工具實際上就可以看成中間人攻擊。
解決方案其實也很簡單，就是SSL Pinning。AFSecurityPolicy的AFSSLPinningMode就是相關設置項。
SSL Pinning的原理就是需要將伺服器的公鑰打包到客戶端中，tls驗證時，會將伺服器的證書和本地的證書做一個對比，一致的話才允許驗證通過。
typedef NS_ENUM(NSUInteger, AFSSLPinningMode) { AFSSLPinningModeNone, AFSSLPinningModePublicKey, // 只驗證證書中的公鑰 AFSSLPinningModeCertificate, // 驗證證書所有欄位，包括有效期之內 };
由於數字證書存在有效期，內置到客戶端後就存在失效後導致驗證失敗的問題，所以可以考慮設置為AFSSLPinningModePublicKey的模式，這樣的話，只要保證證書續期後，證書中的公鑰不變，就能夠通過驗證了。
擴展：
用了SSL Pinning就安全了嗎?
