Dealing with Memory Warnings « cocos2d for iPhone

cocos2d for iPhone » Programming » Programming - Everything else

Dealing with Memory Warnings

(11 posts) (5 voices)

Started 8 months ago by TimK
Latest reply from TimK

Tags:

TimK
Member

Hi,
we are having a few problem problems with out our app crashing on older ipads and ipods. We had already tested these devices extensively in before release however now that its in userland we are getting quite a few crashes in the same place(ie when they press play!) on the older devices. I've managed to establish this is a memory issue that only occurs on devices with 256MB or less memory with lots of apps running in the background.

There are no memory leaks in the app and it isn't particularly resource heavy but does have a largish memory footprint for older devices (~60 Mb). During the initialisation there is a memory spike, if the app can get over this then the memory returns to normal and there are no problems from then on.

So, finally to my question. How to handle a situation when memory is low due to other unclosed apps? Our current thought is to halt the director and animation then pop an alert with memory warning suggesting the user exit and close other apps before restarting.

I know that really there isn't much we can do about this and through our support channel we've found many of our users don't really know about background apps and how to close them(these are the same user who experience the crash). But its better than having the app just bail from memory exhaustion.

I guess our other alternative is to suggest users with older devices don't use the game, although this seem drastic given it works on these devices given the correct conditions.

Any thoughts welcome.

Regards

Tim

Posted 8 months ago #
clarus
Member

So, finally to my question. How to handle a situation when memory is low due to other unclosed apps? Our current thought is to halt the director and animation then pop an alert with memory warning suggesting the user exit and close other apps before restarting.

I think Apple will reject your app if you do this. I know it was in the review guidelines at one point.

There's no way to reduce your footprint? You need all 60MB in memory all the time? Reducing that watermark is what I would target.

I thought that background apps were quit if the system needed their resources (ie. memory). I might be wrong about that, but most users don't quit bg apps, so I find it hard to believe that that would be the problem. If you think about it, so many apps would be crashing if that were the case. It would get to the point where you couldn't run anything.

Posted 8 months ago #
TimK
Member

There's no way to reduce your footprint? You need all 60MB in memory all the time? Reducing that watermark is what I would target.

The 60MB footprint is the instruments reported and this seems common for modern games. In fact I run these games to reproduce the error(it took a week or two to get it to happen on any of our test devices).

I thought that background apps were quit if the system needed their resources (ie. memory). I might be wrong about that, but most users don't quit bg apps, so I find it hard to believe that that would be the problem. If you think about it, so many apps would be crashing if that were the case. It would get to the point where you couldn't run anything.

Yeah I thought this was the case too but it doesn't seem to be the case always. This issue only occurs in around %2-4 of our users however they understandably give bad reviews when the app crashes, this is problematic in the first few weeks of an apps lifetime. Those that contact support and we ask them to close apps restart etc report that the problem goes away.

Believe me I have thought about it quite a lot, and during testing I have noticed other games do the same(ie crash) while the device is in this state.

While I am continuing to explore ways of reducing the spike I need a way to deal with memory warnings effectively and politely.

I think Apple will reject your app if you do this. I know it was in the review guidelines at one point.

Do you have any reference to this? I've scoured the Appstore guidelines and can't find any direct reference to this.
I also know there are games that deal with memory warnings this way(particularly on the iPad).

Regards

Tim

Posted 8 months ago #
clarus
Member

FYI, I found the earlier reference to quitting apps:

Although Mac OS X supports a backing store, iOS does not. In iPhone applications, read-only data that is already on the disk (such as code pages) is simply removed from memory and reloaded from disk as needed. Writable data is never removed from memory by the operating system. Instead, if the amount of free memory drops below a certain threshold, the system asks the running applications to free up memory voluntarily to make room for new data. Applications that fail to free up enough memory are terminated.

It just sounds like something else is going on here. I've written apps that are incredible memory intensive (scrolling views of large zoomable images on an iPad that take 10MB a pop expanded) and had to purge and reload things as necessary if asked, and write some creative code to keep the high water mark down. Are you sure the crashes aren't occurring because an unloadView happens as the result of a memory warning (or cocos2d's caches are purged) and then some code that didn't expect that to happen is crashing? That's pretty common. I don't doubt that a memory warning triggers this but you should be able to recover from that.

Also, if you can return your memory use to "normal" after the "spike" at the start, why can't you take that spike in smaller stages so that you don't have to hit the high limit you're hitting now (presumably over 60MB) during initialization? This is only a problem during initialization, right?

Do you have any reference to this?

This is the clause I was referring to. It's not quite the same, but close enough that I think it could be an issue. Basically, you're making Apple's OS or devices look bad, and that alone is a reason to get rejected.

3.11

Apps which recommend that users restart their iOS device prior to installation or launch may be rejected

Posted 8 months ago #
Scryb
Member

Before you go looking around too much: What version of cocos2d are you using? In versions prior to 1.0 (or maybe 0.99.5) there was a bug in the low memory warning handling that made batchnodes crash. I had a bunch of 1 star reviews thanks to that little gem ;)

Posted 8 months ago #
TimK
Member

Thanks Clarus your first point makes sense. I've noticed since that after numerous warnings the other app start being shutdown or at least being put into a state where they restart/init when they become active.

Yeah as I mentioned this only really occurs in specific cirumstances and as you mention if I can reduce the spike it should alleviate the issue, I'm working on that now but I have some complex startup which is difficult. One really good optimisation is to do a straight replace scene rather than transition(fade) to the game scene, it just makes the game look a little less polished. I think if I manage the shutdown before the new scene this may mitigate the issue somewhat.

Are you sure the crashes aren't occurring because an unloadView happens as the result of a memory warning (or cocos2d's caches are purged) and then some code that didn't expect that to happen is crashing? That's pretty common. I don't doubt that a memory warning triggers this but you should be able to recover from that.

Yeah, the crash reports are suggesting exhausted memory. Have tried stopping the purge on the memory warning just in case and it doesn't have an effect. I don't think the memory warning is causing the crash, its just a precursor to the system shutting down my app. I've read the OS will shutdown apps if they spike when memory is low. When running in Instruments I'll get an urgent memory low warning pretty much everytime before the shutdown. Also I get the dreaded
"Data Formatters temporarily unavailable" when in the debugger.

3.11

Apps which recommend that users restart their iOS device prior to installation or launch may be rejected

Ahh yeah, I think this is different. I have found a few apps which warn memory is low, but as we know that doesn't mean Apple wont reject this app.

Posted 8 months ago #
TimK
Member

Before you go looking around too much: What version of cocos2d are you using? In versions prior to 1.0 (or maybe 0.99.5) there was a bug in the low memory warning handling that made batchnodes crash. I had a bunch of 1 star reviews thanks to that little gem ;)

Yeah I noticed that today, and yes this app is running on 0.99.5. Have disabled the purge and the problem seems to persist. Will probably patch anyway.

Posted 8 months ago #
Normal Force
Member

I know when an app receives a didReceiveMemoryWarning message that CCDirector purges the cached data. But beyond that, is there anything else that we are supposed to do? I just can't see a single thing to do that wouldn't impact the game. Not that I'm hurting for memory -- I keep my sprite use to a minimum and release objects when I no longer need them -- but every time I come across these threads about freeing memory it just feels like I'm the only without some type of creative solution for freeing up just a little more memory.

Posted 8 months ago #
Blue Ether
Member

iOS will automatically start shutting down other apps that are in memory once memory is low. So, the idea of suggesting to the user to do something that the operating system does automatically seems a bit silly to me.

Also, I'm not sure that replace scene will solve your memory spiking. I'm pretty sure you will still get memory overlap. In past projects, I made a special scene which gave the appearance of being a different part of the game, but in fact all I had loaded was a background image. The transition scene itself took almost no memory and only loaded the destination scene after the previous scene had been completely removed from memory. Basically, a one frame delay after onEnterTransitionDidComplete. In that way, I was able to assure that the two bulky scenes were never both loaded into memory at the same time, which will frequently be the place that your app runs out of memory!

Posted 8 months ago #
clarus
Member

@Normal Force, you should respond to the memory warnings by freeing up any objects you can. That might be data you've cached for speed but can read in again when you notice it's not available, that might be objects associated with a view that's being unloaded.

Basically:

In any UIViewControllers:

didReceiveMemoryWarning: Purge cached data, unload anything else you can. [super didReceiveMemoryWarning] will unload any views that don't have a superview.

viewDidUnload: Clear any retained instance vars. When the views are unloaded above, viewDidUnload is sent. Ideally, you should get back to the state you were in before viewDidLoad was initially sent.

viewDidLoad: Called next time the view is needed. Set up your instance vars again.

In the application delegate:
applicationDidReceiveMemoryWarning: Free up whatever you can.

Posted 8 months ago #
TimK
Member

iOS will automatically start shutting down other apps that are in memory once memory is low. So, the idea of suggesting to the user to do something that the operating system does automatically seems a bit silly to me.

The problem is that the system starts shutting down after the spike has occurred and by then its is too late. The alert method is not really there to solve the issue its to stop the system bumping the app during the spike and alerting the user that memory is too tight to run the app. It really is just a cosmetic fix until I sort the spike out. As mentioned before we are really trying to mitigate bad reviews on app store as the game is already on sale. The people using the older hardware seem to be the first to complain when things don't work :-)

Also, I'm not sure that replace scene will solve your memory spiking. I'm pretty sure you will still get memory overlap. In past projects, I made a special scene which gave the appearance of being a different part of the game, but in fact all I had loaded was a background image. The transition scene itself took almost no memory and only loaded the destination scene after the previous scene had been completely removed from memory. Basically, a one frame delay after onEnterTransitionDidComplete. In that way, I was able to assure that the two bulky scenes were never both loaded into memory at the same time, which will frequently be the place that your app runs out of memory!

The replace scene reduces the spike but doesn't remove it. I think I have a good solution which is similar to your suggestion. I already show a loading screen, so if I cleanup the current scene before beginning the transition then I should be able to sort this out. Your suggestion is probably better in that I don't have to manage the clean up.

Posted 8 months ago #

RSS feed for this topic

Reply

You must log in to post.