The Language of Apple Platforms : Memory Management

One of the biggies, unfortunately, is the amount of memory that your programs have available to them. Because of this, you must be extremely judicious in how you manage memory.

The iPhone doesn’t clean up memory for you. Instead, you must manually keep track of your memory usage. This is such an important notion, in fact, that ‘it’s broken out into its own section here.

Releasing Objects

Each time you allocate memory for an object, you’re using up memory on the iPhone. If you allocate too many objects, you run out of memory, and your application crashes or is forced to quit. To avoid a memory problem, you should keep objects around long enough to use them only, and then get rid of them. When you have finished using an object, you can send the release message (or “call the release method” if you prefer that semantic), like this:

[ release];

Consider the earlier example of allocating an instance of NSURL:

Code View: Scroll / Show All

NSURL *iPhoneURL;
iPhoneURL=[[NSURL alloc] initWithString:@"http://www.teachyourselfiphone/"];

					  

Suppose that after you allocate and initialize the URL, you use it to load a web page. After the page loads, there’s no sense in having the URL sitting around taking up memory. To tell Xcode that you no longer have a need for it, you can use the following:

[iPhoneURL release];

Using the autorelease Method

In some instances, you may allocate an object and then have to pass that object off to another method to use as it pleases. In a case like this, you can’t directly release the object because you are no longer in control of it. If you find yourself in a position where an object is “out of your hands,” so to speak, you can still indicate that you are done with it and absolve yourself of the responsibility of releasing it. To do this, use the autorelease method:

[ autorelease];

By the Way

The autorelease method shouldn’t be used unless release can’t be. Objects that are autoreleased are added to a pool of objects that are occasionally automatically released by the system. This isn’t nearly as efficient as taking care of it yourself.

Retaining Objects

On some occasions, you may not be directly responsible for creating an object. (It may be returned from another method, for example.) Depending on the situation, you might actually need to be worried about it being released before you’re done using it. To tell the system that an object is still needed, you can use its retain method:

[ retain];

Again, ’you want to release the object when you’ve completed using it.

By the Way: Retain and Release, Behind the Scenes Behind the scenes, the iOS maintains a “retain” count to determine when it can get rid of an object. For example, when an object is first allocated, the “retain” count is incremented. Any use of the retain message on the object also increases the count. The release message, on the other hand, decrements the count. As long as the retain count remains above zero, the object will not be removed from memory. When the count reaches zero, the object is considered unused and is removed.

Releasing Instance Methods in dealloc

Instance variables are unique in that they usually stick around for as long as an object exists—so, when do they get released? To release instance variables, you add the appropriate release lines to a method called dealloc that will exist in each of your classes. By default, this method has a single line that calls its parent class’s dealloc method. You should add your release messages prior to this. An implementation of dealloc that releases an instance variable called myLabel would read as follows:

- (void)dealloc {
  [myLabel release];
  [super dealloc];
}

Because managing memory is such a critical piece of creating an efficient and usable iPhone application, I make a point of indicating when you should release objects throughout the text—both for variables you use in your methods and instance variables that are defined for your classes.

Rules for Releasing

If you find yourself looking at your code wondering what you should release and what you shouldn’t, here are a few simple rules that can help:

• Variables that hold primitive data types do not need to be released.

• If you allocate an object, you are responsible for releasing it.

• If you use retain to keep an object around, you need to send a release when you’re done with it.

• If you use a method that allocates and returns an object on its own, you are not responsible for releasing it.

• You are not responsible for releasing strings that are created with the @"text string" syntax.

As with everything, practice makes perfect and you’ll have plenty of opportunities for applying what you’ve learned in the book’s tutorials.

Keep in mind that a typical book would spend multiple chapters on these topics, so our goal has been to give you a starting point that future hours will build on, not to define everything you’ll ever need to know about Objective-C and OOP.