Maximum (practical) Memory Use on iPod Touch 4G, iOS 5

3
votes

We have a memory-intensive 3D app which is primarily targeted at iPad 2 and iPhone 4S, but it works on iPod Touch 4G and iPhone 3GS as well. We have found that the smaller memory footprint on the iPod Touch 4G, combined with the retina display, makes this platform more susceptible to out-of-memory errors. iOS5 also seems to have lowered the available memory somewhat.

It's relatively easy for us to lower the resolution of 3D models, based on the platform we're using, but we have to set that resolution before loading, and thus we cannot effectively lower it dynamically based on memory pressure warnings from the O/S.

We've tuned the memory usage based on trial and error, but we've found that devices that haven't been rebooted in a long time (e.g., months) have a lot less useable memory than devices which have been rebooted recently. (Even if you kill off all the running apps.)

I'm wondering what other iOS app developers use as their practical memory limit for iPod Touch 4G apps?

3
iosmemory-managementios5ipod-touch
I am not sure there is a useful answer. It depends heavily on what a user does or uses on the device before or while using your app, it seems to me. Not sure how you'd generalize it. – onnoweb
Well, I'd rather that our app crash roughly never, and I figured other app developers with a lot more experience on the platform might have learned that this means "don't use more than X meg on an iPod touch". But I haven't been able to find that answer. (There was one SO question which hinted at 70Meg, but I think the commenter was just echoing back the question, not providing any real insight.) – Joshua Smith
I was just reminded of this old question by SO, and I thought it's worth giving a little update. Turns out that the key to solving our memory problems in all cases was to switch to using compressed textures. There is literally NO downside: they take less memory at run time, AND they render a lot faster. – Joshua Smith

3 Answers

3
votes

While keeping all the caveats that everyone is offering in mind, my personal general rule of thumb has been that in sensible weather you can expect to have around the following:

  • 512MB device -> 200MB usable (iPhone 4-4S, iPad 2)
  • 256MB device -> 100MB usable (iPhone 3GS, iPad, iPod Touch 3G-4G)
  • 128MB device -> 50MB usable (iPhone 3G, iPod Touch 1G-2G)

And if you want to rigorously withstand insensible weather without otherwise making a point of being flexibly responsive with memory usage, you can halve those numbers, or even third them. But it will be fairly difficult to guarantee sterling reliability if you can't throw anything overboard when conditions become dire. It's more like a sliding scale of how much performance you're willing to throw away for how much reliability at that point.

In environment predictability terms, iOS is a lot more like the PC than a dedicated machine, for better and worse, with the added bonus of a drill sergeant for an OS.

2
votes

Recently I found this awesome tool to find what is the maximum memory capacity of any iOS device. We can also find at which memory level we received the Low Memory warning.

here is the link: https://github.com/Split82/iOSMemoryBudgetTest

1
votes

It's hard to give an actual number because of all the external allocations the OS does on your behalf in UIKit and OpenGL. I try to keep my own allocations to around 30MB, with 50MB sort of my top end. I've pushed it as high as 90MB, but I got jettisoned a lot at that level so it's probably a bad idea unless the task using all that memory is very brief.

If you need to hack around your current problem you could just detect the problematic devices up front and turn down your graphics engine's resolution at startup. You can get exact device info or you could check for display scaling (retina) combined with number of processor cores and amount of RAM to determine what quality level to use.

I've had great success reducing my memory usage by using mapped files in place of loading data into RAM and you may want to give that a try if you have any large data allocations.

Also watch out for views/controls leaking from UIKit as they consume a lot of memory and can lead to being jettisoned at seemingly random times. I had some code which leaked child views from several view controllers. Eventually those leaks would chew up my app, though my app's memory usage didn't reflect the problem directly.