IPhone Memory Management didReceiveMemoryWarning

iphonememory-management

Ok……

I'm implementing a simple OpenGL ES application on the iPhone and I recently added in Pinch Media Analytics. Doing this helped uncover a memory management problem, and I'm not entirely sure how to deal with it.

In a perfect world, my application – which loads PNGs and .CAF files in didFinishLoading will launch, load all of it's resources, and run just fine.

HOWEVER, if my program gets a crash (which happened as I was integrating the Pinch Media libraries) or if I run Safari and open a bunch of pages and then launch my game, the game will crash back to the menu because it is out of memory.

This problem will persist until I do a hard reset of the system.

The default answer that you sort of get online is to implement the didReceiveMemoryWarning method as listed below….

- (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];
}

But this doesn't really help as it's the other programs that are holding onto memory not mine. I don't want to release my own view do I? Is there a good description of how to handle this situation and / or what happens in the didReceiveMemoryWarning event?

Best Answer

Welcome to the shared memory pool with no VM.... There's not a lot you can do here, but there are a few things (and it's possible it's actually your fault and you can completely fix it). Game developers often recommend their customers reboot before running them for this reason, so you may need to be in the same boat if you really need a lot of memory to be effective.

Of course you should try to minimize your own memory footprint. But you should also try to avoid excessive memory fragmentation. Sometimes the problem isn't that there's no memory; there's just no blocks large enough. Sometimes it's better to use a Mutable and keep modifying it rather than generating a new immutable object. This is particularly true of large NSStrings, which can really trash memory.

Keep in mind that UIImage +imageNamed: will keep the image around after you release it, so if you don't need them any more, you need to clear those out. Set its name to nil before releasing it to stop it caching.

Make sure to run your app under Instruments. You may be eating more memory than you think you are.

Don't forget the autorelease pool. If you generate a lot of autoreleased objects in a single event loop, you may need to drain your pool periodically so your don't spike memory. Memory spikes can lead to a program with modest memory requirements suddenly getting killed.

Related Solutions

Ios – How to develop for iPhone using a Windows development machine

It's certainly possible to develop on a Windows machine, in fact, my first application was exclusively developed on the old Dell Precision I had at the time :)

There are three routes;

Install OSx86 (aka iATKOS / Kalyway) on a second partition/disk and dual boot.
Run Mac OS X Server under VMWare (Mac OS X 10.7 (Lion) onwards, read the update below).
Use Delphi XE4 and the macincloud service. This is a commercial toolset, but the component and lib support is growing.

The first route requires modifying (or using a pre-modified) image of Leopard that can be installed on a regular PC. This is not as hard as you would think, although your success/effort ratio will depend upon how closely the hardware in your PC matches that in Mac hardware - e.g. if you're running a Core 2 Duo on an Intel Motherboard, with an NVidia graphics card you are laughing. If you're running an AMD machine or something without SSE3 it gets a little more involved.

If you purchase (or already own) a version of Leopard then this is a gray area since the Leopard EULA states you may only run it on an "Apple Labeled" machine. As many point out if you stick an Apple sticker on your PC you're probably covered.

The second option is more costly. The EULA for the workstation version of Leopard prevents it from being run under emulation and as a result, there's no support in VMWare for this. Leopard server, however, CAN be run under emulation and can be used for desktop purposes. Leopard server and VMWare are expensive, however.

If you're interested in option 1) I would suggest starting at Insanelymac and reading the OSx86 sections.

I do think you should consider whether the time you will invest is going to be worth the money you will save though. It was for me because I enjoy tinkering with this type of stuff and I started during the early iPhone betas, months before their App Store became available.

Alternatively, you could pick up a low-spec Mac Mini from eBay. You don't need much horsepower to run the SDK and you can always sell it on later if you decide to stop development or buy a better Mac.

Update: You cannot create a Mac OS X Client virtual machine for OS X 10.6 and earlier. Apple does not allow these Client OSes to be virtualized. With Mac OS X 10.7 (Lion) onwards, Apple has changed its licensing agreement in regards to virtualization. Source: VMWare KnowledgeBase

R – iPhone Memory Management

NSString *language = [[NSLocale preferredLanguages] objectAtIndex:0];

Here, language does not need to be released because objectAtIndex: autoreleases it for you. By convention, you own an object if you've alloced, newed, or copyed it, otherwise you don't.

self.view.backgroundColor = [[UIColor alloc] initWithPatternImage:[UIImage imageNamed:backgroundImageName]];

Here, the UIColor object does need to be released (because you alloced it).

NSString *backgroundImageName = [[NSString alloc] init];
backgroundImageName = [NSString stringWithFormat:@"background-%@.png",language];

Here the string returned by [[NSString alloc] init] does need to be released (because you've alloced it). However, the next line changes backgroundImageName to point to that a new autoreleased string, losing the last reference to the original string without releasing it (a memory leak). backgroundImageName should not be released because it is already autoreleased.

You can avoid the leaks by releasing the UIColor and eliminating the unused string. For example:

NSString *backgroundImageName = [NSString stringWithFormat:@"background-%@.png",language];

... and ...

UIColor* backgroundColor = [[UIColor alloc] initWithPatternImage:[UIImage imageNamed:backgroundImageName]];
self.view.backgroundColor = backgroundColor;
[backgroundColor release];

Best Answer

Related Solutions

Ios – How to develop for iPhone using a Windows development machine

R – iPhone Memory Management

Related Topic