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.
Read more, and download the category class here: Code – UIWebView Memory Leak Prevention.
Not So Obvious Memory Problem #2: Careful with those returns
This one keeps biting us over and over again:
-
– (void) someMethod
-
{
-
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
-
NSObject * autoReleaseObject = [[[NSObject alloc] init] autorelease];
-
NSObject * nonAutoReleaseObject = [[NSObject alloc] init];
-
-
if (/* something bad happened */)
-
{
-
//bug: should release non auto release objs here, and drain our pool
-
return;
-
}
-
-
/* do stuff with objects */
-
-
[nonAutoReleaseObject release];
-
[pool drain];
-
}
We keep leaking objects by not releasing them when we return (line 10 above) for some error case. Make sure you drain your pools and release objects before return, like this:
-
– (void) someMethod
-
{
-
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
-
NSObject * autoReleaseObject = [[[NSObject alloc] init] autorelease];
-
NSObject * nonAutoReleaseObject = [[NSObject alloc] init];
-
-
if (/* something bad happened */)
-
{
-
[nonAutoReleaseObject release];
-
[pool drain];
-
return;
-
}
-
-
/* do stuff with objects */
-
-
[nonAutoReleaseObject release];
-
[pool drain];
-
}
Not So Obvious Memory Problem #3: Circular References
This one is fairly simple. Consider the following scenario, where we have a Parent and Child object, each pointing to each other with (retain) properties:
-
-
//a parent with a child property
-
@interface Parent : NSObject
-
{
-
NSObject * child;
-
}
-
-
@property (retain) NSObject * child;
-
-
@end
-
-
//a child with a parent property
-
@interface Child : NSObject
-
{
-
NSObject * parent;
-
}
-
-
@property (retain) NSObject * parent;
-
-
@end
-
-
– (void) someMethod
-
{
-
self.parent = [[[Parent alloc] init] autorelease]; //parent reference count 2 (init, and 'self' retain property assignment..)
-
Child * child = [[[Child alloc] init] autorelease]; //child reference count 1
-
parent.child = child; //child reference count 2
-
child.parent = parent; //parent reference count 3
-
-
self.parent = nil; //parent reference count 2
-
//bug: circular reference prevents parent & child from deallocating
-
}
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):
-
-
/* same parent class as before goes here.. */
-
-
//a child with a parent property
-
@interface Child : NSObject
-
{
-
NSObject * parent;
-
}
-
-
@property (assign) NSObject * parent;
-
-
@end
-
-
– (void) someMethod
-
{
-
self.parent = [[[Parent alloc] init] autorelease]; //parent reference count 2 (init, and 'self' retain property assignment..)
-
Child * child = [[[Child alloc] init] autorelease]; //child reference count 1
-
parent.child = child; //child reference count 2
-
child.parent = parent; //parent reference count still 2
-
-
self.parent = nil; //parent reference count 1
-
//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:
-
– (void) loadMoreImages
-
{
-
//be careful to get rid of old view before creating new one
-
[self.child removeFromSuperview];
-
self.child = nil;
-
-
//make new child view
-
self.child = [[UIView alloc] initWithFrame:CGRectMake(0,0,0,0)] autorelease]];
-
[self addSubview:self.child];
-
}
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.