Automatic Reference Counting
Automatic Reference Counting (ARC) is a compiler-level feature that simplifies the process of managing the lifetimes of Objective-C objects. Instead of your having to remember when to retain or release an object, ARC evaluates the lifetime requirements of your objects and automatically synthesizes the appropriate method calls at compile time. It is not a new runtime memory model - and it is not a garbage collector. All the action takes place in the compiler.
ARC takes care of the process of retaining and releasing objects by obeying and enforcing naming conventions. It also relies on new object pointer ownership qualifiers (more on that later).
Lest you worry, ARC is actually much faster (has better performance) than doing memory management on your own.
Warning
ARC does not automate malloc() and free() and does not automate CoreFoundation (CF) or CoreGraphics (CG). You will be using some of those kinds of functions. To be able to manage memory for you, ARC imposes some restrictions - primarily enforcing some best practices and disallowing some other practices. You won't have to worry about most of this in an application that was created to use ARC. You may see some things in non-ARC samples, and this will explain how to work within the ARC restrictions.
In the following sections, the rules that you have to follow to use ARC in your application.
1: Do not call the retain, release, or autorelease methods
In addition, you cannot implement custom retain or release methods. If you are new to Objective-C programming, this rule won't mean anything to you because it is not something you will have been doing in your existing applications. You'll need to know about this rule only to understand what non ARC code is doing to manage memory. If you're an old hand, you will have been using these methods and you'll be happy to comply.
2: Do not store object pointers in C structures
Because the compiler must know when references come and go, you can't store object pointers in C structures. For most readers, that won't be a problem because you will be using objects.
3: Inform the compiler about ownership when using Core Foundation-style objects
In iOS applications, you use the Core Foundation framework.
Core Foundation objects are anything beginning with a CF - things like the address book functions. An example of using a Core Foundation object is:
AudioServicesCreateSystemSoundID ((__bridge CFURLRef)burnRubberURL, burnRubberSoundID);
ARC does not automatically manage the lifetimes of Core Foundation types, and there are Core Foundation memory management rules and functions you can use such as CFRetain and CFRelease (or the corresponding type-specific variants).
Most of the time, you don't have to worry about memory management (and as you explore Core Foundation, the memory management requirements are documented) because you usually will be casting an Objective-C object to a Core Foundation type object or vice versa and with no Core Foundation memory management in your code. But you have to let the compiler know about any memory management implications.
If you do have Core Foundation memory management, there are macros such as CFBridgingRetain or CFBridgingRelease that transfer ownership between ARC and Core Foundation.
4: Use the @autoreleasepool keyword to mark the start of an autorelease block
This is not something you'll be concerned about, or doing. But it is a rule.
Rule 5: Follow the naming conventions
The compiler knows whether to retain an object based on what something returns. Sometimes the object being returned by a method is retained, and sometimes it is auto released later. If the object is going to be auto released, the object needs to be retained. If it's already retained, you don't want the compiler to do anything.
The only way the compiler knows whether an object has been retained when it is returned is through certain naming conventions. Under ARC, these naming conventions are now are now part of the language, and you must follow them.
The compiler knows that a retained object has been returned when the first "word" in the first part of the selector is alloc, new, copy, mutableCopy, or init. These methods transfer ownership - with transferred ownership meaning that the object has been retained for you. An example is the NSString initWithFormat: method.
In addition, you cannot give a property a name that begins with new.
Just follow the rules
That's it - no retaining releasing or releasing. Just follow the rules and code to your heart's content without worrying about memory management.
Except, of course, there are some situations in which you'll need to explicitly tell the compiler what you want. In those cases, you'll have to tell the compiler explicitly about an object's lifetime. I explain how to do that in the next section.
In this tutorial:
- Runtime, Managing Memory, and Using Properties
- App Life Cycle
- Handling events while your application is executing
- Normal Processing of your Application is Interrupted
- Managed Memory Model Design Pattern
- Automatic Reference Counting
- Working with variable types according to ARC
- Low-Memory Warnings
- Framework Classes
- Understanding Declared Properties
- Hiding Instance Variables