//聯(lián)系人:石虎QQ: 1224614774昵稱:嗡嘛呢叭咪哄
ASI和AFN有什么區(qū)別
1.性能(重點)
* ASI基于底層的CFNetwork框架
* AFN基于NSURLConnection
* 運行性能: ASI > AFN
2.處理服務(wù)器數(shù)據(jù)
1> AFN : 根據(jù)服務(wù)器返回數(shù)據(jù)的數(shù)據(jù), 進行自動解析
* 服務(wù)器返回的是JSON數(shù)據(jù), 自動轉(zhuǎn)換為NSDictionary或者NSArray
* 服務(wù)器返回的是XML數(shù)據(jù), 自動轉(zhuǎn)換為NSXMLParser
2> ASI : 并沒有對服務(wù)器的數(shù)據(jù)進行解析, 直接返回NSData二進制數(shù)據(jù)
3.處理請求的過程
1> AFN : success和failure兩個block
2> ASI : 有3種方式處理請求過程(代理方法\SEL\block)
3.ASI的特色(重點)
1> 緩存
2> 下載和上傳
* 輕松監(jiān)聽請求進度
* 輕松實現(xiàn)斷點下載(ASI沒有斷點上傳功能, 斷點上傳得使用socket技術(shù))
3> 提供了很多擴展接口(比如做數(shù)據(jù)壓縮)
* ASIDataCompressor.h
* ASIDataDecompressor.h
4> ASIHttpRequest繼承自NSOperation
* 能用隊列統(tǒng)一管理所有請求
* 請求之間能依賴
5> ASINetworkQueue
* 統(tǒng)一管理所有請求
* 5個下載\上傳請求 --> ASINetworkQueue : 監(jiān)聽5個請求的總進度
* 監(jiān)聽所有請求的開始\失敗\完畢
* shouldCancelAllRequestsOnFailure
YES : 隊列中某個請求失敗了, 其他所有請求都取消
NO : 隊列中的某個請求失敗了, 其他請求不受影響, 繼續(xù)請求
4.AFN的特色
1> 使用簡單
2> 自帶了網(wǎng)絡(luò)監(jiān)控功能
ASI和AFN以及底層框架的關(guān)系
對比ASIAFN
更新狀態(tài)2012年10月份，已經(jīng)停止更新持續(xù)更新中，目前已更新至2.0版
介紹ASI的直接操作對象ASIHTTPRequest，是一個實現(xiàn)了了NSCopying協(xié)議的NSOperation子類。
在initialize和initWithURL:方法中初始化相關(guān)屬性并配置一系列請求相關(guān)參數(shù)默認值。此外，ASIHTTPRequest還提供了一系列的實例方法用來配置請求對象。AFN的直接操作對象AFHTTPClient，是一個實現(xiàn)了NSCoding和NSCopying協(xié)議的NSObject子類。AFHTTPClient是一個封裝了一系列操作方法的“工具類”，處理請求的操作類是一系列單獨的，基于NSOperation封裝的，AFURLConnectionOperation的子類。
線程處理模式每一個請求都由構(gòu)造方法初始化一個（共享）實例，通過這個實例配置參數(shù)并發(fā)起請求。ASI最初使用delegate模式回調(diào)，在iOSSDK支持Block之后也提供了注冊Block的實例方法。
ASI采取的是CFHTTP請求完成，直接回調(diào)ASIHTTPRequest的實例方法，通過儲存的實例對象記錄的信息完成Delegate模式或Block模式的回調(diào)。
在異步請求的處理上，ASIHTTPRequest對象初始化結(jié)束后，在startAsynchronous方法中把對象加入共享操作隊列。此后，包括創(chuàng)建CFHTTPMessageRef，也就是處理網(wǎng)絡(luò)請求的主要對象（事實上是一個指向__CFHTTPMessage結(jié)構(gòu)的指針），在內(nèi)的所有操作都在ASIHTTPRequest對象所屬的子線程中完成。AFN的示例代碼中通過一個靜態(tài)方法，使用dispatch_once()的方式創(chuàng)建AFHTTPClient的共享實例，這也是官方建議的使用方法。在創(chuàng)建AFHTTPClient的初始化方法中，創(chuàng)建了OperationQueue并設(shè)置一系列參數(shù)默認值。在getPath:parameters:success:failure方法中創(chuàng)建NSURLRequest，以NSURLRequest對象實例作為參數(shù)，創(chuàng)建一個NSOperation，并加入在初始化發(fā)方中創(chuàng)建的NSOperationQueue。
以上操作都是在主線程中完成的。在NSOperation的start方法中，以此前創(chuàng)建的NSURLRequest對象為參數(shù)創(chuàng)建NSURLConnection并開啟連結(jié)。
數(shù)據(jù)處理模式ASI在這方面顯得更原始，沒有針對任何數(shù)據(jù)類型做特別封裝，只是預留了各種接口和工具供開發(fā)者自行擴展。AFN針對JSON、XML、PList和Image四種數(shù)據(jù)結(jié)構(gòu)封裝了各自處理器，開發(fā)者可以把處理器注冊到操作隊列中，直接在回調(diào)方法中獲得格式化以后的數(shù)據(jù)。
同步請求ASI則是直接通過調(diào)用一個startSynchronous方法。
AFN默認沒有封裝同步請求，如果開發(fā)者需要使用同步請求，則需要重寫getPath:parameters:success:failure方法，對AFHTTPRequestOperation進行同步處理
異步回調(diào)的處理【使用AFNetworking進行網(wǎng)絡(luò)異步請求時，block:(void(^)代碼塊實際返回到UI主線程中。即使在子線程中使用AFNetWorking進行網(wǎng)絡(luò)的異步請求，block:(void(^)代碼塊仍然返回到UI主線程中（AF框架，它里面已經(jīng)create了異步線程）。因此無論當前處在主線程還是子線程，異步返回均返回到UI主線程中?！繛橐幌盗邢嚓P(guān)的請求定義一個HTTPClient，共用一個BaseURL。每次請求把URL中除BaseURL的Path部分做為參數(shù)傳給HTTPClient的靜態(tài)方法，并注冊一個Block用于回調(diào)。
AFN則直接使用了NSOperation的completionBlock屬性。
基于的底層開發(fā)框架
CFNetwork框架
使用CFnetwork而不是Cocoa框架NSURL有幾點好處。CFNetwork更加專注于網(wǎng)絡(luò)協(xié)議，而NSURL更加專注于數(shù)據(jù)訪問，比如通過HTTP或者FTP傳輸數(shù)據(jù)。盡管NSURL的確也提供了一些可配置功能，可是CFNetwork提供的要多的多。另外NSURL還需要你使用Objective_c。如果做不到這點的話，還是應該使用CFNetworkNSURL
【使用iOS5.0 SDK NSURLConnection：
1、進行網(wǎng)絡(luò)同步請求（sendSynchronousRequest）時，調(diào)用該請求接口的操作在哪個線程，同步返回的網(wǎng)絡(luò)結(jié)果就處于哪個線程，因此通常進行網(wǎng)絡(luò)同步請求時，為了避免阻塞UI主線程，需要在子線程中進行網(wǎng)絡(luò)請求；
2、進行網(wǎng)絡(luò)異步請求（sendAsynchronousRequest）時，block:(void(^)代碼塊實際返回到子線程中。因此，此時如需要向UI線程發(fā)送通知，則需要跳轉(zhuǎn)到主線程中發(fā)送通知dispatch_async(dispatch_get_main_queue(),^{}）；】
底層開發(fā)礦建介紹CFNetwork是基于CoreFoundation中CFStream的一個底層高性能網(wǎng)絡(luò)框架，它由提供基礎(chǔ)服務(wù)的CFSocketStream，支持HTTP協(xié)議的CFHTTP，基于CFHTTP用于身份認證的CFHTTPAuthentication和支持FTP協(xié)議的CFFTP組成。
Core Foundation框架中的CFSocket就是基于BSDSocket開發(fā)的。它幾乎涵蓋了BSD Socket的全部功能，更重要的是把Socket整合到事件的處理循環(huán)中。CoreFounda-tion中較高層的CFStream是基于CFSocket開發(fā)的讀寫流支持。如圖所示，ASI是基于CFHTTP開發(fā)的一個組件；而AFN的基礎(chǔ)——NSURL，也是基于CFNetwork開發(fā)的，也就是說ASI相比AFN更加底層。
性能對比AFN請求優(yōu)于ASI
總結(jié)ASI更適合已經(jīng)發(fā)展了一段時間的應用，或者開發(fā)資源相對豐富的團隊，因為往往這些團隊（或他們的應用）已經(jīng)積累了一定的經(jīng)驗，無論是產(chǎn)品上還是技術(shù)上的。需求復雜度就是在這種時候高起來，而且底層訂制的需求也越來越多，此時AFN就很難滿足需求，需要犧牲一定的易用性，使用ASI作為網(wǎng)絡(luò)底層控件。AFN適合邏輯簡單的應用，或者更適合開發(fā)資源尚不豐富的團隊，因為AFN的易用性要比ASI好很多，而這樣的應用（或團隊）對底層網(wǎng)絡(luò)控件的定制化要求也非常低。
謝謝!!!
