ARC中的新规则

为了ARC能顺利工作，特增加如下规则，这些规则可能是为了更健壮的内存管理，也有可能为了更好的使用体验，也有可能是简化代码的编写，不论如何，请不要违反下面的规则，如果违反，将会得到一个编译期错误。

• 下面的这些函数：dealloc，retain, release, retainCount, autorelease。禁止任何形式调用和实现（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.

自动释放池

使用ARC，你不能使用NSAutoReleasePool类来管理自动释放池了，作为替代，ARC使用一个新的语法结构：

@autoreleasepool {

// Code, such as a loop that creates a large number of temporary objects.

}

编译器根据工程是否使用ARC，来决定这个语法结构最终呈现方式，这个语法结构使用了一种比NSAutoReleasePool更高效的方式。

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 be weak. 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.

其他的新功能

使用ARC技术，可以使得在栈上分配的指针隐式的初始化为nil，比如

- (void)myMethod {

NSString *name;

NSLog(@"name: %@", name);

}

上面的代码会Log出来一个null，不会象不使用ARC技术的时候使得程序崩溃。

 

ARC工作原理是在编译程序的时候由xCode将内存操作的代码(如:retain，release 和 autorelease)自动添加到需要的位置。

ARC 只能在iOS4 和iOS5上使用，weak refrences 只能在iOS5上使用，并且只能是工程在ARC管理内存的时候才能用。

老版本的工程是可以转换成使用ARC的工程,转换规则包括：

        1.去掉所有的retain，release，autorelease

        2.把NSAutoRelease替换成@autoreleasepool{}块

        3.把assign的属性变为weak

使用ARC的一些强制规定

        1.不能直接调用dealloc方法，不能调用retain，release，autorelease，reraubCount方法，包括@selector(retain)的方式也不行

        2.截图租户事故宣布dealloc方法来管理一些资源，但不能用来释放实例变量，也不能在dealloc方法里面去掉[super dealloc]方法，在ARC下父类的dealloc同样由编译器来自动完成

        3.Core Foundation类型的对象任然可以用CFRetain，CFRelease这些方法

        4.不能在使用NSAllocateObject和NSDeallocateObject对象

        5.不能在c结构体中使用对象指针，如果有类似功能可以创建一个Objective-c类来管理这些对象

        6.在id和void *之间没有简便的转换方法，同样在Objective-c和core Foundation类型之间的转换都需要使用编译器制定的转换函数

        7.不能再使用NSAutoreleasePool对象，ARC提供了@autoreleasepool块来代替它，这样更加有效率

        8.不能使用内存存储区（不能再使用NSZone）

        9.不能以new为开头给一个属性命名

        10.声明outlet时一般应当使用weak，除了对StoryBoard 这样nib中间的顶层对象要用strong

        11.weak 相当于老版本的assign，strong相当于retain

对工程中的单个文件制定不使用ARC的方法：在targets的build phases选项下Compile Sources下选择要不使用arc编译的文件，双击它，输入-fno-objc-arc即可