Clever Geek Handbook

Reduce iPhone App Memory Usage

We're in the process of making an iPhone game. We finished development and are trying to optimize the game now for memory. We notice that when we load a specific MVC into the game, close it and not all of the allocated memory is freed (~ 4-5 MB is added). This dramatically increases the memory usage of the game if you keep playing it for 15-20 minutes and the game finally crashes after the low memory warning.

This is what I linked
1. Run the in-game static analyzer and fix all memory leaks and warnings.
2. Manually checks whether the dealloc call of all classes has been called. Everything seems to be in order. 3. Also tried running the Allocations tool in Xcode, but most of the entries in it are CFStrings, mallocs and CFNumbers etc, but don't know which of my classes they come from. Is there a better way to use the distribution tool?

I also have a few memory related questions.
1. We use autoadvertising objects in many places in the game without using the autoresist pool. My understanding is that auto-implemented objects should be deallocated in the next startup cycle and shouldn't pose such a huge problem?
2. Also, if I load images via xib files, they are cached by iOS. Will they clog the memory too?

How do I solve memory usage problems. Any help would be greatly appreciated. Thank!

+3


source to share


3 answers


A few thoughts:



  • Are you using the Core Foundation classes? Make sure that for every object for which you have a Core Foundation call with Create

    or Copy

    in the name you call CFRelease

    (or transfer ownership and then release

    or autorelease

    Objective-C object).

  • Have you used the Leaks tool in Tools? I believe so, but you didn't say that. See Finding leaks in the appendix in the User's Guide.

  • Do you upload images via imageNamed

    ? This caches images and doesn't release them very well. It is safer to use imageWithContentsOfFile

    and manage the cache manually.

  • I am assuming that your view controller dealloc

    gets called and that you are freeing all objects associated with the / ivars class properties?

  • Do you have zombies? This is great for diagnostic purposes, but you won't free up memory until you disable the zombies.

+4


source


If you are doing something "in the process" you should use ARC (Automatic Reference Counting) . Once you've all turned into ARC, you no longer need these abstract objects, and the compiler will release the objects at the appropriate times. If you find that you have a situation where the object pool is still out of control, you can create your own autoresource pool using @autoreleasepool

declarative.

I think moving to ARC will help you and make your future development much easier. Profile your application again in Tools after converting to ARC and narrow down on any offending code that creates large object pools.



If you decide not to convert to ARC, based on your explanations, it looks like you might have a save loop with the view you are referring to. Make sure the view is actually freed by keeping track of all the space it saves.

+2


source


What Rob and Chris said, do this:

Use the Allocations tool configured only to track active allocations and to record reference counts.

Use your app for a bit and Allocations collects data and then pauses your app.

While pause, sorting by Live Bytes and #Living are your most useful views. For a data-oriented application that uses the Foundation collection classes, it is likely that some combinations of * String, * Dictionary, and * Array are most common.

This is normal. If you go into the details of any of these, you get a long list of all the instances currently in memory. You could see po <addr>

any of them what they are. And you can also scroll through the list to see which functions are most often responsible for distribution. Alternatively, you can go to any instance to find out where it was allocated and / or why it might still be around.

Alternatively, you can start with an overview table, sort it by #Living, and scroll down to the first instance of one of your classes. If those class roots are - held onto - a lot of data, then fixing or optimizing is a great start.

And, of course, don't forget heapshot analysis as an extremely powerful tool for analyzing memory generations.

+2


source






More articles:


All Articles