iOS Development

Course No. 10-152-139

Chapter 23 — Preventing Memory Leaks


  • We’re going to add a collection to the Parent class. Parents should probably have pointers to their children. In the Parent.h file we’ll add an array that will hold Child objects. Here’s what it looks like.

  • And here’s the code. First Parent.h.
  • We have to add a @class directive.
  • Here’s the array property.
  • And we’ll need a method to add Child objects.
  • On to the Parent.m file.
  • The addChildObject: first checks if the array exists and creates it if it doesn’t.
  • Then addChildObject: adds the new child object to the Parent object and sets the parent into the Child object.
    • This is a better place to do both than in the main function. It’s more Object-Oriented.
  • The description method now shows the array of Child objects.
  • The Child class has not changed.

The new classes in use.

  • Here’s how we try out the changes. We’ll create a container of parents that each have a couple of children.
  • Create the objects and give them some names.
  • Now we connect the objects. This adds pointers to the Parent into the Child objects and also add the Child objects to the array in the Parent. (Take another look at the graphic above.)

Nil the Objects!

  • We can now eliminate the pointers to the Child objects in the variables we created. Why can we do this?
    • OK, I’ll tell you, there are still pointers to the Child objects in the array of children in the Parent object. The Parent now owns the Child objects. Make sense? Notice that the dealloc methods did not run.
  • Now display the Parent object which will also show the array of Child objects.
  • Now the finale. We’re going to nil out all the Parent objects by nilling the parents array. It should then cause all objects to be deallocated, right?
    • Oops, none of the dealloc methods ran. That’s a problem. What happened?

Retain or Strong reference Cycles

  • Let’s look at the graphic again.

  • The Child objects own the Parent and the Parent owns the Child objects.
  • Remember the rule?

If an object is owned by another then it won’t be destroyed.

  • Our objects all own each other and nothing can be destroyed. This is true even though we don’t have direct pointers to them in our app anymore. Those objects will stay in RAM for as long as the app runs. That’s called a Memory Leak.

Introducing Instruments

  • Let’s see this in action. First we have to get our app to stay running for a bit so we can see what’s going on inside it. That’s what this code does.
    • The app will sleep for 100 seconds and let us look at its RAM.
  • With our app paused we can launch a great program that comes with Xcode, Instruments. The book has screen shots that we won’t reproduce here. Once the app is paused open Instruments with the Product→Profile menu item.
  • Off to Instruments!

Plugging Memory Leaks

  • Now that we’ve seen the problem how do we resolve this? With a weak pointer, also called a weak reference. However, in order to have a weak reference we also need strong references.
  • Let’s create a strong reference first. Here’s the adjusted Parent.h file.
  • This makes these properties strong which means they will own the objects.
  • Now for a weak reference. Here’s the new Child.h file.
  • This makes a pointer a weak reference which gives us access to the object but the Child object will not own their Parent anymore.
  • A new look.

  • Here’s the new output when we run the app.
  • Yes! The dealloc methods all ran. The objects are gone.
  • This is good ™