28 篇文章 0 订阅

# ARC（Automatic Reference Counting ）技术概述

Automatic Reference Counting (ARC) 是一个编译期的技术，利用此技术可以简化Objective-C编程在内存管理方面的工作量。

ARC技术是随着XCode4.2一起发布的，在缺省工程模板中，你可以指定你的工程是否支持ARC技术，如果你不指定工程支持ARC技术，在代码中你必须使用管理内存的代码来管理内存。

## 概述

ARC在编译期间为每个Objective-C指针变量添加合适的retain, release, autorelease等函数，保存每个变量的生存周期控制在合理的范围内，以期实现代码上的自动内存管理。

In order for the compiler to generate correct code, ARC imposes some restrictions on the methods you can use, and on how you use toll-free bridging (see “Toll-Free Bridged Types”); ARC also introduces new lifetime qualifiers for object references and declared properties.

### ARC提供自动内存管理的功能

ARC使得你不需要再思考何时使用retain,release,autorelease这样的函数来管理内存，它提供了自动评估内存生存期的功能，并且在编译期间自动加入合适的管理内存的方法。编译器也会自动生成dealloc函数。一般情况下，通过ARC技术，你可以不顾传统方式的内存管理方式，但是深入了解传统的内存管理是十分有必要的。

 @interface Person : NSObject @property (nonatomic, strong) NSString *firstName; @property (nonatomic, strong) NSString *lastName; @property (nonatomic, strong) NSNumber *yearOfBirth; @property (nonatomic, strong) Person *spouse; @end   @implementation Person @synthesize firstName, lastName, yearOfBirth, spouse; @end

(有关strong的帮助，请参考 “ARC Introduces New Lifetime Qualifiers.”)

 - (void)contrived {  Person *aPerson = [[Person alloc] init];  [aPerson setFirstName:@"William"];  [aPerson setLastName:@"Dudney"];  [aPerson:setYearOfBirth:[[NSNumber alloc] initWithInteger:2011]];  NSLog(@"aPerson: %@", aPerson); }

ARC管理内存，所以这里你不用担心aPerson和NSNumber的临时变量会造成内存泄漏。

 - (void)takeLastNameFrom:(Person *)person {  NSString *oldLastname = [self lastName];  [self setLastName:[person lastName]];  NSLog(@"Lastname changed from %@ to %@", oldLastname, [self lastName]); }

ARC可以保证在NSLog调用的时候，oldLastname还存在于内存中。

### ARC中的新规则

• 下面的这些函数：dealloc，retainreleaseretainCountautorelease。禁止任何形式调用和实现（dealloc可能会被实现），包括使用@selector(retain)@selector(release)等的隐含调用。

你可能会实现一个和内存管理没有关系的dealloc,譬如只是为了调用[systemClassInstance setDelegate:nil] ,但是请不要调用[super dealloc] ,因为编译器会自动处理这些事情。

• 你不可以使用NSAllocateObject或者NSDeallocateObject.

使用alloc申请一块内存后，其他的都可以交给运行期的自动管理了。

• 不能在C语言中的结构中使用Objective－c中的类的指针。

请使用类类管理数据。

• 不能使用NSAutoreleasePool.

作为替代，@autoreleasepool被引入，你可以使用这个效率更高的关键词。

• 不能使用memory zones.

NSZone不再需要—本来这个类已经被现代Objective-c废弃。

ARC在函数和便利变量命名上也有一些新的规定

• 禁止以new开头的属性变量命名。

### ARC Introduces New Lifetime Qualifiers

ARC introduces several new lifetime qualifiers for objects, and zeroing weak references. A weak reference does not extend the lifetime of the object it points to. A zeroing weak reference automatically becomes nil if the object it points to is deallocated.

You should take advantage of these qualifiers to manage the object graphs in your program. In particular, ARC does not guard against strong reference cycles (previously known as retain cycles—see “Practical Memory Management”). Judicious use of weak relationships will help to ensure you don’t create cycles.

#### 属性变量修饰符

weak和strong两个修饰符是新引进的，使用例子如下：

 // 下面的作用和: @property(retain) MyClass *myObject;相同 @property(strong) MyClass *myObject;   // 下面的作用和"@property(assign) MyClass *myObject;"相识 // 不同的地方在于，如果MyClass的实例析构后，这个属性变量的值变成nil,而不是一个野指针,   @property(weak) MyClass *myObject;

#### Variable Qualifiers

You use the following lifetime qualifiers for variables just like you would, say, const.

 __strong __weak __unsafe_unretained __autoreleasing

__strong is the default. __weak specifies a zeroing weak reference to an object. __unsafe_unretained specifies weak reference to an object that is not zeroing—if the object it references is deallocated, the pointer is left dangling. You use__autoreleasing to denote arguments that are passed by reference (id *) and are autoreleased on return.

Take care when using __weak variables on the stack. Consider the following example:

 NSString __weak *string = [[NSString alloc] initWithFormat:@"First Name: %@", [self firstName]]; NSLog(@"string: %@", string);

Although string is used after the initial assignment, there is no other strong reference to the string object at the time of assignment; it is therefore immediately deallocated. The log statement shows that string has a null value.

You also need to take care with objects passed by reference. The following code will work:

 NSError *error = nil; BOOL OK = [myObject performOperationWithError:&error]; if (!OK) {  // Report the error.  // ...

However, the error declaration is implicitly:

 NSError * __strong e = nil;

and the method declaration would typically be:

 -(BOOL)performOperationWithError:(NSError * __autoreleasing *)error;

The compiler therefore rewrites the code:

 NSError __strong *error = nil; NSError __autoreleasing *tmp = error; BOOL OK = [myObject performOperationWithError:&tmp]; error = tmp; if (!OK) {  // Report the error.  // ...

The mismatch between the local variable declaration (__strong) and the parameter (__autoreleasing) causes the compiler to create the temporary variable. You can get the original pointer by declaring the parameter id __strong * when you take the address of a __strong variable. Alternatively you can declare the variable as __autoreleasing.

#### Use Lifetime Qualifiers to Avoid Strong Reference Cycles

You can use lifetime qualifiers to avoid strong reference cycles. For example, typically if you have a graph of objects arranged in a parent-child hierarchy and parents need to refer to their children and vice versa, then you make the parent-to-child relationship strong and the child-to-parent relationship weak. Other situations may be more subtle, particularly when they involve block objects.

In manual reference counting mode, __block id x; has the effect of not retaining x. In ARC mode, __block id x; defaults to retaining x (just like all other values). To get the manual reference counting mode behavior under ARC, you could use__unsafe_unretained __block id x;. As the name __unsafe_unretained implies, however, having a non-retained variable is dangerous (because it can dangle) and is therefore discouraged. Two better options are to either use __weak (if you don’t need to support iOS 4 or OS X v10.6), or set the __block value to nil to break the retain cycle.

The following code fragment illustrates this issue using a pattern that is sometimes used in manual reference counting.

 MyViewController *myController = [[MyViewController alloc] init…]; // ... myController.completionHandler = ^(NSInteger result) {  [myController dismissViewControllerAnimated:YES completion:nil]; }; [self presentViewController:myController animated:YES completion:^{  [myController release]; }];

As described, instead, you can use a __block qualifier and set the myController variable to nil in the completion handler:

 __block MyViewController *myController = [[MyViewController alloc] init…]; // ... myController.completionHandler = ^(NSInteger result) {  [myController dismissViewControllerAnimated:YES completion:nil];  myController = nil; };

Alternatively, you can use a temporary __weak variable. The following example illustrates a simple implementation:

 MyViewController *myController = [[MyViewController alloc] init…]; // ... __weak MyViewController *weakMyViewController = myController; myController.completionHandler = ^(NSInteger result) {  [weakMyViewController dismissViewControllerAnimated:YES completion:nil]; };

For non-trivial cycles, however, you should use:

 MyViewController *myController = [[MyViewController alloc] init…]; // ... __weak MyViewController *weakMyController = myController; myController.completionHandler = ^(NSInteger result) {  MyViewController *strongMyController = weakMyController;  if (strongMyController) {  // ...  [strongMyController dismissViewControllerAnimated:YES completion:nil];  // ...  }  else {  // Probably nothing...  } };

In some cases you can use __unsafe_unretained if the class isn’t __weak compatible. This can, however, become impractical for nontrivial cycles because it can be hard or impossible to validate that the __unsafe_unretained pointer is still valid and still points to the same object in question.

### 自动释放池

 @autoreleasepool {  // Code, such as a loop that creates a large number of temporary objects. }

### Outlets

The patterns for declaring outlets in iOS and OS X change with ARC and become consistent across both platforms. The pattern you should typically adopt is: outlets should be weak, except for those from File’s Owner to top-level objects in a nib file (or a storyboard scene) which should be strong.

Outlets that you create should will therefore generally be weak by default:

• Outlets that you create to, for example, subviews of a view controller’s view or a window controller’s window, are arbitrary references between objects that do not imply ownership.

• The strong outlets are frequently specified by framework classes (for example, UIViewController’s view outlet, or NSWindowController’s window outlet).

For example:

 @interface MyFilesOwnerClass : SuperClass   @property (weak) IBOutlet MyView *viewContainerSubview; @property (strong) IBOutlet MyOtherClass *topLevelObject; @end

In cases where you cannot create a weak reference to an instance of a particular class (such as NSTextView), you should use assign rather than weak:

 @property (assign) IBOutlet NSTextView *textView;

This pattern extends to references from a container view to its subviews where you have to consider the internal consistency of your object graph. For example, in the case of a table view cell, outlets to specific subviews should again typically beweak. If a table view contains an image view and a text view, then these remain valid so long as they are subviews of the table view cell itself.

Outlets should be changed to strong when the outlet should be considered to own the referenced object:

• As indicated previously, this often the case with File’s Owner: top level objects in a nib file are frequently considered to be owned by the File’s Owner.

• You may in some situations need an object from a nib file to exist outside of its original container. For example, you might have an outlet for a view that can be temporarily removed from its initial view hierarchy and must therefore be maintained independently.

### 其他的新功能

 - (void)myMethod {  NSString *name;  NSLog(@"name: %@", name); }

07-01 2291
11-29 4566
11-16 485
08-27 131
06-06 657
08-05 672
11-24 753
08-28 2949

• 非常没帮助
• 没帮助
• 一般
• 有帮助
• 非常有帮助