When application enters in background running state, how much dirty memory usages is good to go. In apple video it\'s mentioned that the dirty memory should be reduced as mu
You might still have your UIViewControllers still retained if dealloc isn't being called.
Perhaps are you setting delegates or other classes in these UIViewControllers that retained and referenced back up the tree (circular references).
A way you can debug this is to overload retain and release in your UIViewController and set a break point and log the retainCount.
Here is a magic snippet I leave running around that helps me a ton when I can't figure out why I'm still retaining something.
- (id)retain
{
NSLog(@"retain \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]);
return [super retain];
}
- (void)release
{
NSLog(@"release \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]);
[super release];
}
- (id)autorelease
{
NSLog(@"autorelease \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]);
return [super autorelease];
}
__PRETTY_FUNCTION__
is a special hidden macro in CLang that gives a pretty Objective-C function name as a char array.
UINavigationController
to deal with your back button. I think the problem here is that if dealloc
is not called on a pop or dismiss, you have a memory leakAlmost all view controllers have data that is effectively cached and can be regenerated when the app returns to the foreground. Think of the data that you release when you get a memory warning when the app is running. (You are responding to memory warnings, right?) It's that stuff that should be released when you go into the background.