• What is Memory management in iOS?

Memory management is the programming discipline of managing the life cycles of objects and freeing them when they are no longer needed. Managing object memory is a matter of performance; if an application doesn’t free unneeded objects, its memory footprint grows and performance suffers. Memory management in a Cocoa application that doesn’t use garbage collection is based on a reference counting model. When you create or copy an object, its retain count is 1. Thereafter other objects may express an ownership interest in your object, which increments its retain count. The owners of an object may also relinquish their ownership interest in it, which decrements the retain count. When the retain count becomes zero, the object is deallocated (destroyed).

  •  Object Life cycle

An object’s life cycle—that is, its runtime life from its creation to its destruction—is marked or determined by various messages it receives. An object comes into being when a program explicitly allocates and initializes it or when it makes a copy of another object. An object can also begin its runtime life during unarchiving, when it is asked to decode itself from the archive byte stream. If an object was unarchived from a nib file, it receives an awakeFromNib message after all objects in the nib file have been loaded into memory

Object life cycle

After the creation and initialization phase, an object remains in memory as long as its retain count is greater than zero. Other objects in the program may express an ownership interest in an object by sending it retain or by copying it, and then later relinquish that ownership interest by sending release to the object. While the object is viable, a program may begin the archiving process, in which the object encodes its state in the archive byte stream. When the object receives its final release message, its retain count drops to zero. Consequently, the object’s dealloc method is called, which frees any objects or other memory it has allocated, and the object is destroyed.

  • How do i know my class has the ownership of an object?

Answer :

You own an object if you create it using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for example, alloc, newObject, or mutableCopy), or if you send it a retainmessage.

 

Many classes provide methods of the form +className... that you can use to obtain a new instance of the class. Often referred to as “convenience constructors”, these methods create a new instance of the class, initialize it, and return it for you to use. You do not own objects returned from convenience constructors, or from other accessor methods.


  • What’s the correct way to release a retained property, or any kind of object owned by a class?!

Answer:

Once you have finished with an object that you own, you should relinquish ownership using release or autorelease.

Typically you should use release rather than autorelease. You use autorelease only when immediate deallocation of the object would be inappropriate, for example you are returning an object from a method. (Note: this does not imply that release necessarily results in deallocation of an object—it will only do so if the retain count drops to 0 as a result—but it might do, and sometimes you need to guard against that: see “Returning Objects from Methodsfor an example.)

  • You need to Implement a dealloc method to release the instance variables you own.
  • You should never invoke dealloc directly (other than when you invoke super’s implementation in a custom dealloc method).

 

 

Assuming that you have a retained property such as object.retainedValue and you declared an ivar retainedValue in your class header.

You can release this value by using

[retainedValue release];

retainedValue = nil;

 

Create a mcaro which does this job every time when you release an object. 

RELEASE_SAFELY (object) [object release], object=nil

No need for nil check before release invoke, as Apple made the nil object to be a valid object.

Please refer to Obj-C language for more information.

 

  • What’s the correct way to release outlets? Why my outlets are not released in low-memory situation while views can be released automatically by iOS in low-memory situation as Apple said?

Answer:

Make sure you release outlets in UIViewController:viewDidUnloadanddealloc methods.

  • viewDidUnload is called ONLY in the case iOS tries to unload hidden views when the device getting low-memory situation, thus don’t depend on this event to free all your retained objects.
  • dealloc is called when an object is going to be DE-allocated.

 

 

  • Are there any cases that the UIViewController never gets released or not being released immediately after the UIView is dismissed?

Answer:

Yes, this is often happened with multi-threaded implementations. And in your UIViewController, you create background processes using performSelectorInBackground or threadByDetachSelector, or blocks, the UIViewController will be released once background processes are completed (there is no way in iOS to TERMINATE a running thread as in Windows).


  • How to properly handle IBOutlet within a ViewController

You can do it by implementing property/synthesize pattern

(Example A) FooController.h: @interfaceFooController : UIViewController {     UILabel *fooLabel; } @property (nonatomic, retain) IBOutletUILabel *fooLabel; @end FooController.m: @implementationFooController @synthesize fooLabel; @end
But you can also use direct instance variable (notice: no property and no synthesize):
(Example B) FooController.h: @interfaceFooController : UIViewController {     IBOutletUILabel *fooLabel; } @end FooController.m: @implementationFooController @end
 

 

 Refer the apple documentation on memory management .