iOS memory management tools

Question

I have a few questions about memory management. I'm using ARC, xcode 4.2.1, deploying to ios 5.0+

1) How do you know when your app is managing memory efficiently and correctly? If it's not leaking memory, as you measure in the instruments leaks tool, then is your app completely healthy?

2) Should I be using other tools other than Leaks to determine if my app is managing memory well?

3) My live bytes keeps growing as I continue to run my app. My app has a UITableView displaying some data. When a user clicks a row, I take them to a more detailed page. If this is all my app is doing, why do my live bytes continue to grow? Shouldn't all the objects be released, bringing down my live bytes to what it was when I first launched the app?

4) What exactly is a malloc?

I'm close to completing the application, and I just want to know how to measure that the app is releasable, and how to identify any problems.

Thanks!

Answer 1

How do you know when your app is managing memory efficiently and correctly?

• Does it seem to be operating in a reasonable amount of memory given whatever data it's operating on, or does it use a lot more memory than you'd expect?

• When the program isn't doing anything, is its memory usage reasonable and stable?

• If you exercise the program thoroughly, does memory usage stabilize or does it seem to grow without bound?

• Does your program respond appropriately to memory warnings from the OS?

• Does it tolerate low memory conditions gracefully?

Should I be using other tools other than Leaks to determine if my app is managing memory well?

The various tools in Instruments should be sufficient to help you look at how your app uses memory. One thing you might want to consider doing is saving the results from your Instruments sessions along with some notes so that you can see how your app's memory use changes over time.

My live bytes keeps growing as I continue to run my app.

That may or may not be a problem; it'd help to know what's in the blocks that keep getting added. If there's memory available on the device, there's nothing wrong with using it, especially if it means that your app performs better, can avoid downloading similar data from some source, etc. But if your app keeps allocating a new view controller and views without releasing the old ones, that's probably a leak.

What exactly is a malloc?

malloc() is one of the memory allocation functions in the C standard library. I have a feeling that you're asking because you see lines like Malloc 16 bytes in the Category column for the Allocations instrument:

Those lines represent a category of blocks of memory that were allocated by malloc(). As you can see, in my case I have 3318 16-byte blocks from malloc() currently in use in my program. The exact number isn't so important -- the thing you care about is how that number changes over time. If you find that some number of malloc() blocks are used and never released every time you perform some action, you'll have a clue about where to look in your program for memory problems. (The same is true of any other kind of block, of course.)

Answer 2

1. How do you know when your app is managing memory efficiently and correctly? You know it when you don't have leaks and your memory size doesn't grow unless there's a reason. Apple has released a number of informative videos, such as WWDC 2012 “iOS App Performance: Memory” and WWDC 2010 “Advanced Memory Analysis with Instruments”.

2. Leaks will help you find memory that is unreachable: your program has no way to get to it anymore. It won't help you find memory that is reachable but useless: a cache that's growing without bound, or a view that keeps acquiring new subviews that hide old subviews. You can use the Allocations instrument to look at what's allocating memory as time goes on. The basic technique is to click “Mark Heap”, perform some actions (in your app) that you think should result in a net zero change in allocations, then mark the heap again and see what's new that should have been freed. Again, Apple has videos that explain this in more detail.

3. See #2.

4. There are already answers on stackoverflow that address this, such as these:

How is malloc() implemented internally?
How do malloc() and free() work?
How do free and malloc work in C?

and web pages, such as these:

http://en.wikipedia.org/wiki/C_dynamic_memory_allocation
http://web.eecs.utk.edu/~huangj/cs360/360/notes/Malloc1/lecture.html

Answer 3

1) This depends on what your application does. If you are running a simple application that performs simple tasks, efficient memory usage isn't so much a big deal. You focus more on writing a bare and memory-sipping application. However, if your project requires muscle, or performs intense calculations, then memory optimizations focuses entirely on trimming the fat around the edges.

2) Of course. Zombies, Allocations, and even the Time Profiler exist to help you manage object life-cycles.

3) Your application should in fact be using an increasing amount of memory from what you describe. You seem to expect that navigation stacks release view controllers higher up on the stack, which is the complete opposite of why navigation stacks exist. As you push more view controllers onto the stack, memory usage grows because now there's a new view controller to manage. If your app were deleting large portions of memory, that would be the thing to worry about, because then you would have major problems with zombie objects.

4) malloc is the C version of alloc. The only difference being that alloc performs a bit of runtime magic and sets the class' isa pointer and tweaks some minor per-object values before eventually calling malloc. Malloc allocates a block of memory, and returns a pointer to the object. That's why you only alloc objects, and not primitives (note that primitives can be pointed to, and then do require malloc), because you need a valid pointer, which itself is literally a block of memory.