views:

688

answers:

2

My iPhone application is running into problems when deployed to the device, principally because I haven't handled memory warnings thus far (no problem in the simulator, with 4GB of ram on my dev machine!). No problem there, I just need to handle these warnings more skilfully (less suckily...).

Question is, which memory does the runtime release... just the view and subviews? I suspect that it is just these, but want to be sure that the runtime will not dereference any of the objects or memory in my controller (ie. not in the view).

Subquestion: if it is just the view and subviews, do I need to do anything special in viewDidLoad to make sure that when the view is brought back into memory the view shows correct data, or is it all handled automatically via my IBOutlet-s?

+2  A: 

There are potentially many things that the view, or its subviews, may cache - such as image data. These are the sort of things that will be purged. Anything specific to your application that you can afford to flush you'll need to do yourself by handling that callback.

However, this may be more of an indication that you are either leaking memory or not being as efficient with it as you might be. It's certainly worth running the app in Instruments with the Leaks tool, as well as running with the CLANG compiler's static code analyser. Also, examine your code to see if you are holding on to blocks of memory you don't really need - whether you can compress images more etc.

Remember, before the 3GS or the latest iPod touch, system memory was 128Mb but you should only count on having about 25-30Mb available to your application

Phil Nash
I think a key thing to remember is that the runtime does not release anything for you. Classes of things you can purge are any data you could load again (without a huge hit), images etc not currently on display etc but it's up to you to decide in the context of your appAlso worth remembering is that notification is a warning to your app to clean up, and you are responsible for getting rid of any memory you do not currently need. The 'warning' if unheeded will cause the OS to terminate your app.
Kevin
Don't you mean 128MB, and 25-30MB?
mahboudz
Makes sense that the runtime doesn't release anything behind the scenes, that my app is simply being warned... but the runtime/memory manager IS unloading the view. Doesn't this save some memory?Also, my app is receiving these warnings, on and off, after consuming 7-8MB of memory. The leaks tool is showing one leak, but only 32 bytes so presume not a serious problem (as much as it irks me!).
mblackwell8
@mahboudz - oops yes - thanks for spotting that. I must have had the C64 emulator on my mind ;-) I'll update my post to correct it (so if anyone is wondering what we're talking about I originally said 128k and 25-30k respectively)
Phil Nash
@mblackwell8 - yes the runtime does purge things that are under its control that it can do transparently. Certain objects such as UIImageViews are able to purge their data and reload on demand. This has an impact on performance but does not affect the logical consistency of the application. What it won't do, which I think Kevin was alluding to, is actually release any objects on your behalf that you have retained.
Phil Nash
A: 

Neither viewDidUnload nor didRecieveMemoryWarning automatically release anything. You need to override both of these methods.

Generally, viewDidUnload should release anything in the view that wasn't created in IB, and that you can reasonably deal with reloading when the view is loaded up again.

And didRecieveMemoryWarning is a message that is sent to your app when the system is running low on memory. When your app receives this message, you should release anything and everything that you don't immediately need, or risk the system forcibly shutting down your app.

Shawn Craver