when is the dealloc method called?

When exactly is the dealloc method called? I've found that (in a lot of examples) much of the NS variables are released in the method it's instantiated in, but when syn开发者_如何学Gothesizing a component they place the release in the dealloc method.

---

The Apple reference document clearly states Subsequent messages to the receiver may generate an error indicating that a message was sent to a deallocated object (provided the deallocated memory hasn’t been reused yet).

You never send a dealloc message directly. Instead, an object’s dealloc method is invoked indirectly through the release NSObject protocol method (if the release message results in the receiver's retain count becoming 0). See Memory Management Programming Guide for more details on the use of these methods.

Subclasses must implement their own versions of dealloc to allow the release of any additional memory consumed by the object—such as dynamically allocated storage for data or object instance variables owned by the deallocated object. After performing the class-specific deallocation, the subclass method should incorporate superclass versions of dealloc through a message to super:

Important: 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

Another SO question iPhone - when is dealloc for a viewcontroller called?

---

When you load the nib file, there's got to be an owner which is an object that exists in the application. If you open the nib file in interface builder you will see a proxy icon that represents the owner of the nib file. You can make connections to it but the connections are not established UNTIL the nib file is loaded and you specify who the onwer really is.

Anyways, you can have an outlet (e.g. an i-var) connected to the top level UI object in the nib file, usually the window. When you load the nib file and specify the owner that i-var will now point to the UI object. Let's say it is a window. Eventually when you decide to get rid of the UI objects you simply release the owner and if it reaches a retain count of zero the dealloc method will get called. Then the dealloc method in the owner should release it's i-vars (instance variables). So let's say the i-var that you connected to the window is called window. Then you should have something like this:

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

That should then cause the window to reach a count of zero. Then the window's dealloc should get called and it will subsequently release all the retains on the subviews, and the subviews will reach a retain count of zero and they will subsequently release all the retains on their subviews, and so on until everything is dealloced.

It's been a while since I did AppKit (Cocoa) programming but I think this is still true.

There's an application from Omni called OmniObjectAlloc or something like that which should be very helpful in looking at your app and figuring out if everything is getting dealloced. I used ObjectAlloc from NeXT/Apple but I don't know if they still provide it. Look for it, I would imagine it's still there.

---

Its based on the scope of the object that you actually create or retain. Whenever the retaincount is brought back to 1, dealloc method will be called by its own. This is only applicable for MRC, not in ARC.

One good note is keep track of the objects that you create, let it not leak in your implementations.