我正在開發一個應用程序，它將本機聯繫人上傳到服務器，然後獲取響應（JSON，一個已安裝該應用程序的聯繫人列表）。當本地聯繫人數量足夠大時，服務器響應速度會很慢並且不穩定。用戶不能做其他事情。所以我把網絡請求放入後臺線程。每次我將上傳100個聯繫人，完成一些任務，然後再接下100個聯繫人，直到完成循環。爲什麼我的後臺工作線程阻塞UI線程？
但是在運行中，結果並不如預期。後臺線程正在運行，它保持請求服務器。 UI線程被阻塞，我仍然無能爲力。
這是在後臺線程中導致長循環嗎？雖然我有2個線程，但他們會競爭CPU資源（測試設備是iPod，1個核心，而我認爲這可能與核心數量無關）？
任何人都可以告訴我如何處理這種情況的提示？提前致謝！
更新：
我找到了根本原因。 App委託中的全局變量被設置爲錯誤值，因此UI行爲很奇怪。我通過評論所有網絡請求方法發現了這個。所以這個問題與多線程無關。對不起，麻煩了。
我認爲需要澄清一下您如何執行網絡操作。
1，NSOperatiomQueue處理NSOperations，所以你可能將你的網絡代碼包裝在一個NSOperation子類中。
第二，你是否在爲你的網絡代碼使用NSURLConnections？
3，NSURLConnection的阻塞部分還是NSURLConnection的委託回調？
需要注意的一點是，普通ol'NSURLConnections是在多線程引擎下實現的。該對象默認放置在主線程的運行循環中（當從主線程運行時），但該對象只是一個包裝器，它處理從另一個線程上發生的來自底層網絡代碼（BSD套接字）的委託的回調。
你真的不應該能夠在主線程上用NSURLConnections阻止你的用戶界面，除非A）你在委託回調方法中用昂貴的代碼阻塞線程，或者B）太多的運行循環壓倒你同時URL連接（這是NSOperationQueue的setMaxConcurrentOperationsCount：進場的地方）
Thx。我的回答：第一，是的，我正在使用NSInvocationOperation來包裝網絡請求方法。第二/第三，不，我使用SDK方法來請求服務器，它是同步調用。 – LetBulletFlies
我只是想知道是否可以在多個線程中訪問Appdelegate。服務器請求方法在應用程序委託中，並將在後臺線程中調用。我會嘗試將它移到其他地方。 – LetBulletFlies
您使用的是GCD嗎？ – CodaFi
@CodaFi 不，我在應用程序委託中使用NSOperationQueue。 100個聯繫人的每個請求都會被放入隊列中。 – LetBulletFlies
我想更好的問題是：你可以使用GCD嗎？或者你需要瞄準iOS 3.x？ – CodaFi