WIJL: IOS Memory Management Part 2

A few months ago, I posted an entry about some lessons learned in IOS Memory Management. In that entry (WIJL: IOS Memory Management), I covered a bunch of little objective-c memory management gotchas that helped us squash a few major memory leak bugs in TumbleOn.

In the past few months, we’ve done some more work on TumbleOn, and we’ve learned a few more tricks of the trade, including some not-so-obvious problems, and some obvious bits that are worthwhile additions to any memory-leak-hunter’s checklist.

First, the not so obvious bits:

Not So Obvious Memory Problem #1: UIWebView Antics

It appears UIWebView is a bit quirky when it comes to memory management. Some theories maintain that the UIWebView will release properly if you load empty content into the UIWebView before deallocation, while other theories amount to voodoo magic tricks that seem to work for us.

I’ve rolled up an easy-to use objective-c category class which provides a simple cleanBeforeDealloc extension to UIWebView. Pay special attention to the class’ many comments, as none of the tricks encapsulated in the class are my own, and some tricks are merely documented there and will require additional work in your UIWebViewDelegate class and/or UIWebView allocation methods.

In this scenerio, the reference count at the end of someMethod is 2 for both the Parent and the Child objects. There are a number of ways to fix this problem, depending on your control of the Parent/Child code.

First, if you have complete control, simply change the Child’s property to (assign) from (retain):

//later autorelease will see parent has ref count of 1, and clean it up, causing parent to clean up child in dealloc..

}

If you don’t have control of the child code, such as when you have some UIView subclass w/ a delegate pointing to yourself, be careful to clean up that delegate reference:

–(void) unloadMyTable

{

self.tableView.delegate =nil;

[self.tableView removeFromSuperview];

self.tableView =nil;

}

Many of the stock objective c cocoa library delegate properties are (assign) rather than (retain), but some delegate class references such as UIWebViewDelegate explicitly warn you to set the .delegate to nil before deallocating a view, which may imply that view has a retain hold on your delegate implementation.

Not So Obvious Memory Problem #3: UIView children

Be careful with the UIView objects you add as children to another UIView:

If you consistently add new views as children to another view that won’t go away anytime soon, those child views will stack up. It is not enough to hold a property to one of the child views and nil it out, you must remember to also call removeFromSuperview on old child views you intend to deallocate.

Obvious Memory Management Issues: Dealloc

Now, the obvious stuff. Make sure you have a dealloc that sets anything you hold onto with a (retain) property to nil:

–(void)dealloc

{

self.label =nil;

self.viewButton =nil;

[super dealloc];

}

Also be careful to call [super dealloc]; at the end of all of your dealloc methods. Failing to do so will prevent the super class (such as UIView) from cleaning up it’s various child objects that it retains.

Memory management in objective-c isn’t always easy, or straight forward. Hopefully some of these tips will help you in your coding adventures.

About

Jason Baker is a software engineer. He works on enterprise infrastructure for big companies. He also enjoys creating smaller scale software products and scripts in his spare time.