0

Currently, I'm building my first app for the app store therefore I have read here, that an app should use less than 30 MB of RAM (iPhone 3G, iPhone 4). I have read that, at some point in time, iOS will start hunting for the resources by randomly killing and freeing sounds, images and other resources from the background apps. Currently, my app uses ~5MB of live bytes that are showed in instruments but I feel some paranoia about memory :) Am I safe when app uses less that 10MB when targeting iPhone3G and iPhone4?

The question is if an app goes to background then how much of resources iOS can free of it until finally killing it? If my app goes to background and then 100 or more others apps will be launched then what happens to my app? I do not believe that RAM memory piece is static for my app because the memory in each device is limited. IMHO, if you start looping with opening a new app, sending it to the background, opening another one - then device RAM will be totally used at some point in time. Then, theoretically, if you try to open a new app then some very first opened apps should be killed by iOS...

Currently, I'm building small game with pure UIKit, therefore I use a lot of UIView and UIViewImage objects and I'm not sure how to deal with this theoretical situation. During entering the background, my app might gave loaded a lot of in game UIViewImages, pointer to menu MVC and etc. Do I have to code some reloadALL method for reloading every peace of the game? Everything would be OK if iOS would kill my whole app if device memory is totally used. But it would be unacceptable if iOS would release some of my UIViewImage in game or menu objects. In that case, I don't know what kind of "zombie" (how many legs, arms and etc my app could have after a "resurrection") my app could be. Please share your experience and thoughts :)

Community
  • 1
  • 1
Centurion
  • 14,106
  • 31
  • 105
  • 197

3 Answers3

1

Once an app has entered background and the system needs more memory, it just kills the backgrounded app and your app will not get any message before this happens. So its all or nothing.

Nevertheless the memory management of iOS supports e.g. deallocation of view objects and lazy recreation in case of memory warnings (while your app is still active, check UIViewController docs didRecieveMemoryWarning how the system itself copes with memory warnings)

Now when your app enters background you could try to implement similar behavior - also free some memory (e.g. your own caches or elements which can be lazily recreated) so the memory footprint of your app gets reduced. Doing so might help to have your app live a litte longer in the background before it gets killed.

When iOS starts to kill apps, it might use its own algorithm, which is not neccessarily killing the oldest app - it might also go for the largest app in terms of memory to have a larger effect...

marcus
  • 2,521
  • 1
  • 23
  • 32
0

iOS will cull UIKit data (such as your image views) and any in-memory NSCaches when necessary when backgrounded. You do not need to worry about restoring this though.

However, you should still manage your own objects and stuff; dealing with culling and restoring data when you receive appropriate events such as memory warnings.

Benjamin Mayo
  • 6,649
  • 2
  • 26
  • 25
  • Thanks. Currently, I know only one way for dealing with memory warnings: the method "applicationDidReceiveMemoryWarning:" in main app delegate class. What do you mean by saying "dealing with culling"? What are the others ways for handling memory warnings? – Centurion Jul 30 '11 at 09:02
  • Culling is just a way of saying "remove from memory". I'd handle memory warnings in the app delegate, view controllers (`didRecieveMemoryWarning`) and in `applicationDidResignActive`. If you are looking for a design pattern to make this easy, look at lazy instantiation. – Benjamin Mayo Jul 30 '11 at 09:30
0

We should not be really concerned about the total images used in the app. The memory is used for only those images in active screen.

Kumaran
  • 687
  • 6
  • 14