To write and compile source code for ARC, you have to take care of a few things. Just by following the rules in the list below, you can write source code for an ARC-enabled environment with confidence. 

 

  •   Forget about using retain, release, retainCount, and autorelease.

  •  Forget about using NSAllocateObject and NSDeallocateObject.

  •  Follow the naming rule for methods related to object creation.

  •  Forget about calling dealloc explicitly.

  •  Use @autoreleasepool instead of NSAutoreleasePool.

  •  Forget about using Zone (NSZone).

  •  Object type variables can’t be members of struct or union in C language.

  •  ‘id’ and ‘void*’ have to be cast explicitly. 

As described previously, the compiler doesn’t manage variables with the __unsafe_unretained ownership qualifier. You have to take care of ownership yourself to avoid a memory leak or the application will crash. 

 

Conversely, __bridge_transfer cast will release the object just after the assignment is 

 

􏰃 1. Nil is assigned to any variables qualified with __weak when referencing object is discarded.

􏰃 2. When an object is accessed through a __weak qualified variable, the object is added to the autorelease pool. 

 

This means that an object assigned to a variable with __weak, is added to the autorelease pool so that the variable can be used safely until @autoreleasepool block is left. 

If you use __weak qualified variables too often, too many objects will be stored in autorelease pool. 

 

This is the implementation and it lets us know how nil is assigned to any variables qualified with __weak when the referencing object is discarded. Also, it tells us that if too many __weak ownership qualified variables are used, it consumes CPU resources at some level. So, __weak ownership qualified variables should be used only to avoid circular references. 

 

一些比较黑客的API

There is the other case where you can’t use the __weak ownership qualifier. When an NSObject instance method allowsWeakReference or retainWeakReference returns NO, the object can’t be assigned to a variable qualified with __weak. These methods are not documented in the NSObject protocol. The declaration is as follows.

- (BOOL)allowsWeakReference; - (BOOL)retainWeakReference;

When an object is assigned to a variable qualified with __weak, allowsWeakReference is called. If it returns NO, your application will be aborted: 

 

To follow the memory management rules, when you do not obtain an object by the alloc/new/copy/mutableCopy method group, the object has to be passed without ownership. By the __autoreleasing ownership qualifier, the rule is fulfilled. 

 

 

 

A code block between the creation and disposal of the NSAutoreleasePool object is equivalent to the variable scope in C. When an NSAutoreleasePool object is disposed of, the release method is automatically called for all the autoreleased objects. Some example source code is as follows. 

 

  1. “id obj” does not have a qualifier. So it is qualified with __strong. When the “return” sentence is executed, the variable scope is left and the strong reference disappears. Therefore the object will be released automatically. Before that, if the compiler detects that the object will be passed to the caller, the object is registered in autoreleasepool. 

　　1. When a variable with a __weak qualifier is used, the object is always registered in autoreleasepool. 

 

 

Any pointers to ‘id’ or object types are qualified with __autoreleasing as default. 

 

 

struct. If you still want to put an object to C struct, you can do it by casting the object to “void *” (see next section) or by using an __unsafe_unretained ownership qualifier (see “Ownership qualifiers” section).

struct Data {

NSMutableArray __unsafe_unretained *array; };

As described previously, the compiler doesn’t manage variables with the __unsafe_unretained ownership qualifier. You have to take care of ownership yourself to avoid a memory leak or the application will crash.