ASI和AFN以及底層框架的關系?

對比	ASI	AFN
更新狀態(tài)	2012年10月份，已經(jīng)停止更新	持續(xù)更新中，目前已更新至2.0版
介紹	ASI的直接操作對象ASIHTTPRequest，是一個實現(xiàn)了了NSCopying協(xié)議的NSOperation子類。 在initialize和initWithURL:方法中初始化相關屬性并配置一系列請求相關參數(shù)默認值。此外，ASIHTTPRequest還提供了一系列的實例方法用來配置請求對象。	AFN的直接操作對象AFHTTPClient，是一個實現(xiàn)了NSCoding和NSCopying協(xié)議的NSObject子類。AFHTTPClient是一個封裝了一系列操作方法的“工具類”，處理請求的操作類是一系列單獨的，基于NSOperation封裝的，AFURLConnectionOperation的子類。
線程處理模式	每一個請求都由構造方法初始化一個（共享）實例，通過這個實例配置參數(shù)并發(fā)起請求。ASI最初使用delegate模式回調，在iOS SDK支持Block之后也提供了注冊Block的實例方法。 ASI采取的是CFHTTP請求完成，直接回調ASIHTTPRequest的實例方法，通過儲存的實例對象記錄的信息完成Delegate模式或Block模式的回調。 在異步請求的處理上，ASIHTTPRequest對象初始化結束后，在startAsynchronous方法中把對象加入共享操作隊列。此后，包括創(chuàng)建CFHTTPMessageRef，也就是處理網(wǎng)絡請求的主要對象（事實上是一個指向__CFHTTPMessage結構的指針），在內的所有操作都在ASIHTTPRequest對象所屬的子線程中完成。	AFN的示例代碼中通過一個靜態(tài)方法，使用dispatch_once()的方式創(chuàng)建AFHTTPClient的共享實例，這也是官方建議的使用方法。在創(chuàng)建AFHTTPClient的初始化方法中，創(chuàng)建了OperationQueue并設置一系列參數(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并開啟連結。
數(shù)據(jù)處理模式	ASI在這方面顯得更原始，沒有針對任何數(shù)據(jù)類型做特別封裝，只是預留了各種接口和工具供開發(fā)者自行擴展。	AFN針對JSON、XML、PList和Image四種數(shù)據(jù)結構封裝了各自處理器，開發(fā)者可以把處理器注冊到操作隊列中，直接在回調方法中獲得格式化以后的數(shù)據(jù)。
同步請求	ASI則是直接通過調用一個startSynchronous方法。	AFN默認沒有封裝同步請求，如果開發(fā)者需要使用同步請求，則需要重寫getPath:parameters:success:failure方法，對AFHTTPRequestOperation進行同步處理
異步回調的處理	【使用AFNetworking進行網(wǎng)絡異步請求時，block:(void(^)代碼塊實際返回到UI主線程中。即使在子線程中使用AFNetWorking進行網(wǎng)絡的異步請求，block:(void(^)代碼塊仍然返回到UI主線程中（AF框架，它里面已經(jīng)create了異步線程?）。因此無論當前處在主線程還是子線程，異步返回均返回到UI主線程中。】	為一系列相關的請求定義一個HTTPClient，共用一個BaseURL。每次請求把URL中除BaseURL的Path部分做為參數(shù)傳給HTTPClient的靜態(tài)方法，并注冊一個Block用于回調。 AFN則直接使用了NSOperation的completionBlock屬性。
基于的底層開發(fā)框架	CFNetwork框架 使用CFnetwork而不是Cocoa框架NSURL有幾點好處。CFNetwork更加專注于網(wǎng)絡協(xié)議，而NSURL更加專注于數(shù)據(jù)訪問，比如通過HTTP或者FTP傳輸數(shù)據(jù)。盡管NSURL的確也提供了一些可配置功能，可是CFNetwork提供的要多的多。另外NSURL還需要你使用Objective_c。如果做不到這點的話，還是應該使用CFNetwork	NSURL 【使用iOS5.0 SDK NSURLConnection： 1、進行網(wǎng)絡同步請求（sendSynchronousRequest）時，調用該請求接口的操作在哪個線程，同步返回的網(wǎng)絡結果就處于哪個線程，因此通常進行網(wǎng)絡同步請求時，為了避免阻塞UI主線程，需要在子線程中進行網(wǎng)絡請求； 2、進行網(wǎng)絡異步請求（sendAsynchronousRequest）時，block:(void(^)代碼塊實際返回到子線程中。因此，此時如需要向UI線程發(fā)送通知，則需要跳轉到主線程中發(fā)送通知dispatch_async(dispatch_get_main_queue(), ^{}）；】
底層開發(fā)礦建介紹	CFNetwork是基于Core Foundation中CFStream的一個底層高性能網(wǎng)絡框架，它由提供基礎服務的CFSocketStream，支持HTTP協(xié)議的CFHTTP，基于CFHTTP用于身份認證的CFHTTPAuthentication和支持FTP協(xié)議的CFFTP組成。 Core Foundation框架中的CFSocket就是基于BSD Socket開發(fā)的。它幾乎涵蓋了BSD Socket的全部功能，更重要的是把Socket整合到事件的處理循環(huán)中。Core Founda-tion中較高層的CFStream是基于CFSocket開發(fā)的讀寫流支持。	如圖所示，ASI是基于CFHTTP開發(fā)的一個組件；而AFN的基礎——NSURL，也是基于CFNetwork開發(fā)的，也就是說ASI相比AFN更加底層。
性能對比	AFN請求優(yōu)于ASI
總結	ASI更適合已經(jīng)發(fā)展了一段時間的應用，或者開發(fā)資源相對豐富的團隊，因為往往這些團隊（或他們的應用）已經(jīng)積累了一定的經(jīng)驗，無論是產品上還是技術上的。需求復雜度就是在這種時候高起來，而且底層訂制的需求也越來越多，此時AFN就很難滿足需求，需要犧牲一定的易用性，使用ASI作為網(wǎng)絡底層控件。	AFN適合邏輯簡單的應用，或者更適合開發(fā)資源尚不豐富的團隊，因為AFN的易用性要比ASI好很多，而這樣的應用（或團隊）對底層網(wǎng)絡控件的定制化要求也非常低。

以上分析與對比是根據(jù)本人查資料以及測試所得，若有不正確的地方還請大家指出，謝謝！
另附：iOS開發(fā):AFNetworking、MKNetworkKit和ASIHTTPRequest比較【下圖為查找的資料，尚未驗證】

?原文地址:http://blog.sina.com.cn/s/blog_a0f3ea980101c0yo.html

轉載于:https://www.cnblogs.com/chengfang/p/4158041.html

總結

以上是生活随笔為你收集整理的AFNetworking和ASIHTTPRequest的比较的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。