iPhone內存管理didReceiveMemoryWarning

Question

好吧......

我實現在iPhone上簡單的OpenGL ES應用程序，我最近在捏媒體分析補充。這樣做有助於發現內存管理問題，我不完全知道如何處理它。

在一個完美的世界，我的應用程序 - 它加載和PNG圖像文件的.caf在didFinishLoading將啓動，加載所有它的資源，並運行就好了。然而，如果我的程序發生崩潰（發生在我整合捏媒體庫時發生），或者如果我運行Safari並打開一堆頁面然後啓動我的遊戲，遊戲將會回到菜單，因爲它是內存不足。

此問題將持續存在，直到我做了系統的硬重置。

默認的回答，你那種上網是實現didReceiveMemoryWarning方法如下....

- (void)didReceiveMemoryWarning 
{ 
    // default behavior is to release the view if it doesn't have a superview. 

    // remember to clean up anything outside of this view's scope, such as 
    // data cached in the class instance and other global data. 
    [super didReceiveMemoryWarning]; 
} 

但是，這並不能真正幫助，因爲它是被保存到存儲器上的其他程序不是我的。我不想釋放我自己的看法嗎？有沒有很好的描述如何處理這種情況和/或didReceiveMemoryWarning事件發生了什麼？

Answer 1

如果你只有一個單一的視圖，那麼你可以做真正的唯一的事情是釋放你不使用任何數據，後來延遲加載它們。

如果您有一個觀點越多，那麼他們可能會，如果他們是不可見的釋放。如果發生這種情況，相應的控制器將發送setView:與nil。我通過立即釋放所有IBOutlet變量來處理這種情況，以便在再次從其xib加載視圖時正確設置它們。

這是我在一個普通的非OpenGL ES應用程序中採用的方法，該應用程序具有> 6個​​視圖，並且即使在導航視圖中處於4級深度並且所有先前的控制器將視圖設置爲nil時，當我向後導航時不會發生崩潰，但視圖重新加載時會有延遲。

如果你還沒有發現它已經在模擬器有模擬內存警告，這是不是強制的條件在真實的設備更容易出現一個菜單項。也就是說，它不會取代在真實設備中測試相同的場景 - 只是讓測試更容易。

Answer 2

歡迎沒有VM共享內存池....還有的不是很多，你可以在這裏做的，但也有幾件事情（並有可能它實際上是你的錯，你可以完全解決這個問題）。由於這個原因，遊戲開發人員經常會推薦他們的客戶重新啓動，因此，如果您確實需要大量內存才能生效，那麼您可能需要坐在同一條船上。

當然，你應該儘量減少你自己的內存佔用。但是你也應該儘量避免過多的內存碎片。有時問題不在於沒有記憶;沒有足夠大的塊。有時最好使用Mutable並繼續修改它，而不是生成新的不可變對象。這對於大型NSStrings來說尤其如此，因爲它可能會造成內存浪費。

請記住，UIImage +imageNamed:會在您釋放圖片後保留圖片，因此如果您不再需要圖片，則需要將其清除。在釋放它之前將其名稱設置爲零，以停止緩存。

確保在Instruments下運行您的應用程序。你可能吃的東西比你想像的要多。

不要忘記autorelease池。如果您在單個事件循環中生成大量自動釋放對象，則可能需要定期排空游泳池，以避免內存過多。內存尖峯可能會導致一個內存需求適度的程序突然死亡。

Answer 3

您可以嘗試使用壓縮的PVRTC代替使用PNG，以節省一些空間（以可能的性能成本）。

有一個漂亮的小教程在這裏：

http://iphonedevelopment.blogspot.com/2008/12/preparations-for-porting-nehe-lesson-06.html

而且記住你必須重寫一些你的OpenGL調用來處理這種不同的壓縮紋理。

[聲明：我不是OpenGL ES優化大師。不是由looooong拍攝。]