views:

513

answers:

5

There are plenty of objects in each iPhone app witch will live forever till app dies. They are: application delegate, window, main view controller, may be navigation or tab controller, all the objects within them. Why on Earth should I release them just before quit spending precious CPU cycles? As far as I understand, apps process will be terminated, so it's heap, consistent or not will be gone too.

So why should I release them? Apple's dev manuals insist on it like in code sample following (from iPhone Development Guide). It's just first place I've found searching by word dealloc in library.

@implementation HelloWorldAppDelegate
@synthesize window;

- (void)applicationDidFinishLaunching:(UIApplication *)application { 

    // Override point for customization after app launch
    MyView *view = [[MyView alloc] initWithFrame:[window frame]];
    [window addSubview:view];
    [view release];
    [window makeKeyAndVisible];
}
- (void)dealloc {
    [window release];
    [super dealloc];
}
@end

From Discussions section on NHObject-dealloc method:

Note that when an application terminates, objects may not be sent a dealloc message since the process’s memory is automatically cleared on exit—it is more efficient simply to allow the operating system to clean up resources than to invoke all the memory management methods. For this and other reasons, you should not manage scarce resources in dealloc

But dealloc method in sample above is called in current implementation if your application is fast enough to react to applicationWillTerminate within 15 seconds.

So again. Should I avoid writing dealloc method above for app exit speed or are there any problems with such approach?

A: 

Because it is possible that a class that is released has a side effect such as saving state in it's dealloc method or one of it's super classes. The OS should not care, it should reclaim all resources no matter what.

zaph
Saving state in dealloc? Why?
Artem Tikhomirov
Saving state in the dealloc is a very bad idea, as dealloc is not guaranteed to execute. applicationWillTerminate is provided for saving state.
mmc
*If* you have a class that does that, yeah, you need to release it before termination. But Apple's docs say to avoid that as much as possible, because objects aren't generally meant to be released at termination.
Chuck
It might be possible that the dealloc does other work, but it SHOULD never do so. As others have said, dealloc is not guaranteed to ever be called.
Jacob
+2  A: 

The best reason is reuse. There's a chance you may move an object from one place to another or repurpose it. If you do that it's best to make sure all your i's are dotted and t's crossed.

It's also just good habit. If you remember to do it there, you'll do it everywhere.

mousebird
Yes, for me it's like using a turn signal while driving through a parking lot. It's not necessary, but it's good to get yourself in this habit.
Brad Larson
You are not automate - you are human been. Mechanically repeating same action over and over again without thinking about it may damage your brain.
Artem Tikhomirov
Reuse ability? Are you kitting me? How do you gonna to reuse application delegate? As a tooth stick?
Artem Tikhomirov
Nope, I wouldn't reuse an app delegate, but what I would do is realize that half of the functionality I put in there belongs elsewhere. So I'd make a copy of the app delegate, start renaming and cut down the dealloc. And it's then that putting everything in the right place helps.
mousebird
A good example of what stiiv is talking about is singletons. Sure, you only want one instance now, but you could always change your mind in the future. Would you rather spend 30 seconds writing `dealloc` now, or potentially hours tracking down a memory leak in the future? Seems like good insurance to me.
Alex
Two instances of app delegate? Why? Anyways I'm not for saving time to write damn dealloc. I'm for saving time executing it.
Artem Tikhomirov
A: 

The code sample you posted does not insist on releasing anything when the app terminates. If you're thinking of the dealloc method, it won't be called when the app terminates.

In several places in the documentation, Apple notes that not sending dealloc on quit is an intentional design choice because, as you said, it's much more efficient just to free the whole address space. See the discussion on the dealloc docs.

Chuck
But it's being called. I've checked it on actual device. And this particular dealloc forces all those objects to dealloc too.They say: ...when an application terminates, objects may not be sent a dealloc message... It means that if after 15 seconds your app still saving some thing it'll be terminated anyways skipping deallocation.
Artem Tikhomirov
It's only being called if you release the object that code is in. The runtime isn't deallocing it for you.
Chuck
+4  A: 

I guess the only answer that makes any sense to me is, "consistency". No, you may not always need to implement dealloc, but if you always do it, you won't forget to do it when it does matter. And besides, it's not like it costs you more than 30 seconds to write two lines of code that might not get called.

You're also very unlikely to waste your precious CPU cycles (which cycles, by the way, are not so precious that you would ever notice a difference. Those iPhone animations exist mainly to buy your app time to start up/shut down) because when the application terminates, it usually doesn't bother to dealloc objects because, as you say, that heap's memory allocating days are behind it.

So, yeah, dealloc is unlikely to ever be called on a UIApplicationDelegate, but does it cost you anything to do it anyway? Not really.

Alex
IMHO application exit experience is valuable. Of course I should measure that but I think deallocation could be quite expensive.
Artem Tikhomirov
Well, since you've already made up your mind, why did you even bother to ask?
Alex
I've asked about issues in such approach. It's hard to accept, that so large team as Apple's could teach to do unnecessary things. I'm sorry if I've irritated you.
Artem Tikhomirov
+2  A: 

Because you will know, Artem.

Let's play a little game called "what if".

What If, you develop a great app. A masterful app, really - and the public loves it! Your sales swell, birds sing your name awing in the sky!

But, you chose not to do anything in your AppDelegate dealloc. Just a few seconds of time, you decided not to bother with. What's the harm?

Oh at first you sleep easy atop the piles of money. But as sales grow and grow, a little twinge comes upon you. And then the dreams start.

Square shapes, indistinct at first. Days pass and they grow clearer, as you sleep less and less. Then finally, one day, you see.

They are blocks, Artem. Memory blocks. And what are they doing in your dreams? Well you see, not quite freed from existence before the application quits, they had to go somewhere. The app was gone, the phone had moved on.

So they moved into your HEAD. And every day, more arrive, leaving less room for YOURSELF.

I hope this has been informative... Artem.

Kendall Helmstetter Gelner
+n votes (for values of n close to 1).
jbrennan
That was awesome.
Jasarien