NSOperationQueue許多線程

在我們的iPhone應用程序中，我們有幾個選項卡，並選擇每個選項卡觸發網絡連接。在過去，我們只是爲每個連接分離新線程。幾個非常快速的標籤開關應用程序變得沒有反應。現在我們決定使用應該控制線程數的操作隊列，並且不應該讓應用程序變得沒有響應。但是現在即使使用較少的快速開關，該應用程序也無響應（儘管現在它可以更快地從無響應中恢復）。我從xcode在設備上運行應用程序，並在幾次快速切換後暫停它以查看線程數。而我發現的是，有幾個線程與以下堆棧：NSOperationQueue許多線程

0 __workq_kernreturn 
    2 _init_cpu_capabilities

任何想法這些線程和如何擺脫它們？

來源

2011-05-31 Mikayel Aghasyan

使用NSOperationQueue的一大好處是你可以忘記線程並讓系統爲你擔心。這聽起來像是你的問題的根源在於你有多個同時運行的操作不再需要。不要擔心特定的線程，請考慮讓這些操作終止，以便它們不再使用計算資源。

對於它的價值，我的猜測是這些線程正在由Grand Central Dispatch管理。 GCD將創建工作線程來處理塊（和操作），並且它會盡可能高效。

來源

2011-05-31 07:08:56 Caleb

這就是爲什麼我們決定切換到NSOperationQueue（忘記線程並讓系統擔心）。實際上，我的操作並沒有使用太多的CPU，他們只是做了一個NSURLConnection（同步）並在主線程上執行回調。 – 2011-05-31 07:35:18

問題的重要部分不太可能在於工作線程的內部/私有實現。一個好的實現可能會使用線程池，因爲每個操作創建一個線程會花費很多。操作可以重用並保留空閒的線程。

重要的部分（可能）在於您使用您選擇的實現的公共apis。

這種情況下支持的一個明顯的實現是操作取消：-[NSOperation cancel]。當有人從有未決/未完成請求的視圖導航時，只需取消它（除非需要緩存數據）。

許多實現也可以通過減少請求次數來獲益。例如：如果您的服務器結果只是每小時更新一次，那麼請求「每分鐘一次」都沒有意義。

最後一點：連接可以使用工作線程本身 - 檢查您使用的apis是否可以在出現問題時減少此問題。

來源

2011-05-31 07:10:51 justin

實際上，不是取消先前的請求，而是跟蹤正在進行的請求，並且在正在進行時不會爲同一請求添加操作。我想我提到的線程是池線程（如你所注意到的），也許限制maxConcurrentOperationCount是合理的。 – 2011-05-31 07:32:43

沒錯 - 如果他們一定不能取消並且以後可以使用，那麼可以封頂 - 壞消息是，如果你不取消，那麼你正在等待的重要操作將不會盡快完成。當在類似的場景中下載一堆圖像時，我發現大約4個url連接在屏幕上獲得了最快的速度（但是該模型也支持取消）。 – justin 2011-05-31 19:40:37

我認爲取消已經運行的操作不是一種選擇，因爲操作所做的主要事情是發出同步HTTP請求。而HTTP請求正在處理中取消不會阻止它。收到回覆後，取消它是不合理的。所以，我唯一檢查取消的地方是在發出HTTP請求之前。 – 2011-06-01 20:45:52

NSOperationQueue許多線程

回答

相關問題