這可能或可能不會幫助您的確切情況,但這通常會通過密切關注您的autorelease堆棧增長而減少。你應該能夠通過在自動釋放池塊中包裝那些重創造者(來自url的數據,包含數據的圖像)來減少這個問題。
@autoreleasepool { work with large NSObjects here }
,或者根據不同的系統,你必須部署:
NSAutoreleasePool * pool = [NSAutoreleasePool new];
work with large NSObjects here
[pool release];
如果你可以使用@autoreleasepool
,這樣做。它稍微好一點,因爲它直接與底層的autorelease棧進行交互。如果您需要向後兼容,請使用NSAutoreleasePool
。在更高層次上,他們真正起到相同的作用,因爲您應該能夠在程序中交換其實現,而不會引入新問題。因此,在決定使用哪個操作系統時,它確實歸結爲您所定位的最小操作系統以及您爲項目指定的構建設置。
你應該換你的處理和大(或多個)分配的創作自動釋放塊,因爲自動釋放的對象發送釋放消息「在將來的某個時候」。通過顯式創建和銷燬autorelease池(並且通過使用autorelease的頻率較低),可以讓許多這些對象快速銷燬。
至於爲什麼除了在您的程序中不使用autorelease之外,爲什麼這樣做還不錯:客戶端和系統庫最終會將大/多個圖像/ NSData
添加到autorelease池。自動釋放池是像(線程局部)堆棧 - 當你摧毀當地的游泳池,而做你的游泳池是在上面所有的自動釋放的消息將會實現,而自動釋放對象將收到釋放消息。
或者是不好的做法,通過不同的線程之間分配的內存?
請記住,您應該從主線程向您的UIKit和AppKit對象發送消息。在Cocoa中,許多庫可能會指定它們的線程模型。 NSData遵循Foundation的線程模型。目的並不明確線程安全的,但他們是安全的,如果你讀和/或在任何給定的時間從沒有超過一個線程寫的(即使用,使用鎖時,你需要在MT上下文中使用它,或者通過複製)。傳遞和共享數據/對象並不是一個壞習慣,有時它是必需的(或邏輯解決方案)。有一個小問題說它「不錯」:很多人不太瞭解多線程和共享資源(這對於許多人來說並不是一項微不足道的技能)。
顯式聲明NSAutoreleasePool和只使用變量autoreleasepool之間的區別? – REALFREE
@REALFREE評論/響應擴大並移到更新的答案。 – justin