2012-09-02 170 views
5

添加在NSOperationQueue中創建同步NSURLConnection請求的操作(或來自線程(不是主線程)的同步請求)和從主線程發出異步請求?來自線程與異步請求的NSURLConnection同步請求

這兩個都不會阻塞主線程,所以UI將保持響應,但有沒有比其他優勢更好的優勢?我知道在以後的方法,我可以跟蹤請求進展等,但認爲進展和其他HTTP的東西在這裏並不重要。

回答

2

將異步請求安排在運行循環中,並設置爲運行循環源,僅當從網絡接收到數據(如任何套接字源)時自動觸發代碼。

NSThread上運行的同步請求獨佔一個線程來監視傳入的數據,這通常是相當有害的。

即使使用cancel方法異步執行,也可以取消NSURLConnection

我敢打賭,使用新的API,允許發送上NSOperationQueue+sendAsynchronousRequest:queue:completionHandler:)異步請求使用GCD引擎蓋和dispatch_source_create,或類似的東西在,所以它的行爲方式時NSURLConnection被安排在爲同運行循環,避免使用額外的線程(觀看WWDC'12視頻,它解釋了爲什麼線程是邪惡的,它們的使用應該最小化),區別僅在於它允許您在完成時使用塊而不是使用委託機制。

幾年前,我創建了一個嵌入NSURLConnection異步調用和委託管理到一個很好的塊API(請參閱我的github上的OHURLLoader),使它更易於使用(隨意看一看)的類。我敢打賭,使用NSOperationQueue的新API使用相同的原則,仍然在runloop上執行異步請求,但允許您使用塊而不必實施委託。

2

歷史地位是,在異步請求中,電源消耗和電池壽命都有優勢 - 大概包括舊的代理方法和新的基於塊的方法。

+0

謝謝,你有一個觀點:) – msk

+0

這是有道理的。什麼*是*新的基於塊的方法,具體請問?不尋找代碼,只是要問谷歌,所以我可以挖掘一些文檔。 – Madbreaks

+2

@Madbreaks它是'NSURLConnection + sendAsynchronousRequest:queue:completionHandler:'。 – Tommy

5

它們非常相似。同步請求最大的問題是不能輕易取消。根據您的應用程序,這可能是一個問題。想象一下,你正在下載一個大文件,用戶移動到另一個屏幕,所以你不再需要這些信息。在我們的例子中,我確實選擇了在輔助NSThread上執行異步NSURLConnections,這對於某些應用程序來說可能是過度的。它比較複雜,但它使我們既可以取消請求,也可以解碼輔助線程上的JSON/XML /圖像數據,從而不影響主線程用戶交互。

+0

感謝您的回答,這很有道理 – msk