前言：在Swift慢慢趨向于穩(wěn)定且高效的時候，OC也隨著時間一點點的消逝，曾經(jīng)的諸多OC框架也都投向了Swift的懷抱，而Swift對于框架的提升也逐漸的展露頭腳。
Alamofire作為AFNetworking的升級版，在網(wǎng)絡請求的框架中有著非常眾多的使用者，所以今天就來學習Alamofire框架中的response流程和常見的多表單上傳。
response流程
response在Alamofire中扮演了什么角色？
response直譯過來是反應、響應的。在普通網(wǎng)絡請求中，我們是通過閉包或者代理方法來獲得數(shù)據(jù)請求請求的，這里來看一段普通請求的代碼。
這是一段最簡單的請求，沒有頭文件的設置。在閉包中返回了data，response，error三個參數(shù)。那這里的response是什么呢？
這里通過打印可以看到NSHTTPURLResponse的類，其實主體就是兩個字典，而NSHTTPURLResponse是繼承自NSURLResponse的類，屬性是來自于NSURLResponse。
response在這里是作為保存Url、請求的狀態(tài)和請求的頭信息存在的，那Alamofire是否是同樣的作用呢？
追溯源碼開始
這里直接創(chuàng)建了response，是一個DataResponse，那這個DataResponse是不是在閉包中獲取到的呢，暫時還不得而知。這里先來看一下DataResponse是什么。
這是一個保存信息的結構體。什么方法也沒有，聲明了一堆的屬性。回頭看創(chuàng)建的response，此時是保存信息。
保存的是什么信息呢，這里self.request，self.response，self.data，self.metrics，以及result都是什么呢？這里的self 指向了DataRequest，同樣來到DataRequest中
DataRequest類中只有一個data，來自于mutableData，其他的屬性呢？看繼承的關系，只能去DataRequest的父類中去尋找。在Request類中找到了其他的的屬性。數(shù)據(jù)太多，這里就不截圖了?？梢钥吹揭稽c的是，不管是data還是其他的屬性都是在這里聲明的。
看到這里似乎有一點明白了，response是一個響應的存儲類，保存了我們的url，返回的data，以及error等屬性。
再接著向下走
-> self.eventMonitor?.request(self, didParseResponse: response)
肯定是看最后一個request的方法
這個時候肯定是需要了解清楚這個eventMonitor是什么
源碼中很清晰，這里是一個協(xié)議，定義了很多的方法。只需要找到是誰實現(xiàn)的這個協(xié)議就清楚了request方法究竟做了什么。
再次跳轉，可以看到這個eventMonitor? 被添加進入了一個monitors的數(shù)組中，這下就明白了，這個request的方法是監(jiān)控回調的。
這里很清楚的看到并沒有使用session的閉包請求，那么請求的回調一定是發(fā)生在代理中的。
最開始的ruqest方法已經(jīng)開始了請求，那么就需要在URLSessionDataDelegate實現(xiàn)的代理中找到回調的方法
在這里我們就將請求到的數(shù)據(jù)寫入了對應的response中去了。
當然在這里還沒有結束->??self.responseSerializerDidComplete 這一句就是將閉包追加到請求的狀態(tài)中。
當請求成功的時候將請求的狀態(tài)修改為isFinished，然后調用對應外界的回調閉包，將請求的數(shù)據(jù)及請求的狀態(tài)以及請求的參數(shù)打包整理好的response，通過閉包回調出去。
總結一下：Alamofire 采用了將請求和參數(shù)以及回調的閉包封裝為成為一個新的DataResponse，然后通過監(jiān)聽URLSessionDataDelegate代理中回調的方法，獲取到請求成功或失敗的數(shù)據(jù)，再將其添加到DataResponse中，最后通過保存的閉包將其返回，完成一個閉包返回所有數(shù)據(jù)的功能。
