Cocoa Objects 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 it retains 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 DE allocated (destroyed).
- An object can hardly be an element of a collection if that object can go out of existence at any time; so when you add an element to a collection, the collection asserts ownership of the object by retaining it.
- Thereafter, the collection acts as a well-behaved owner.
- If this is a mutable collection, then if an element is removed from it, the collection releases that element.
- If the collection object goes out of existence, it releases all its elements.
- Removing an object from a mutable collection constituted a potential trap.
Memory management can be achieved following three concepts:
- Sending autorelease to an object marks the object for later release, which is useful when you want the released object to persist beyond the current scope.
- Autoreleasing an object puts it in an autorelease pool (an instance of NSAutoreleasePool), which created for an arbitrary program scope.
- When program execution exits that scope, the objects in the pool released.
- When objects retain count drops to zero, the runtime calls the dealloc method of the object’s class just before it destroys the object.
- A class implements this method to free any resources the object holds, including objects pointed to by its instance variables.
- Many framework classes define class methods that, as a convenience, create objects of the class for you.
- These returned objects not guaranteed to be valid beyond the receiving method’s scope.
Example for Cocoa Objects Memory Management
- Consider the following Objective-C code:
id obj = myMutableArray; // an NSMutableArray
[myMutableArray removeObjectAtIndex: 0]; bad idea in non-ARC code!
// … could crash here by referring to obj …
- When you remove an object from a mutable collection, the collection releases it.
- So, the second line of that code involves an implicit release of the object that used to be element 0 of myMutableArray.
- If this reduces the object’s retain count to zero, it will destroy.
- The pointer obj will then be a dangling pointer, and a crash may be in our future when we try to use it as if it were a real object.
- With ARC, however, that sort of danger doesn’t exist. Assigning a reference type object to a variable retains it!
- But we did assign this object to a variable, obj, before we removed it from the collection. Thus that code is perfectly safe, and so is its Swift equivalent:
let obj = myMutableArray myMutableArray.removeObject(at:0)
// … safe to refer to obj …
- The first line retains the object. The second line releases the object, but that release balances retain that placed on the object when the object placed in the collection originally.
- Thus the object’s retain count is still more than zero, and it continues to exist for the duration of this code.