http://www.onevcat.com/2012/06/arc-hand-by-hand/#sthash.QDbi47Or.dpbs

stackflow上面的回答：

There is no downside. Use it. Do it today. It is faster than your old code. It is safer than your old code. It is easier than your old code. It is not garbage collection. It has no GC runtime cost. The compiler inserts retains and releases in all the places you should have anyway. But it's smarter than you and can optimize out the ones that aren't actually needed (just like it can unroll loops, eliminate temporary variables, inline functions, etc.)

OK, now I will tell you about the small downsides:

  • If you're a long-time ObjC developer, you will twitch for about a week when you see ARC code. You will very quickly get over this.

  • There is some (very) small complications in bridging to Core Foundation code. There are slightly more complications in dealing with anything that treats an id as a void*. Things like C-arrays ofid can take a little more thinking about to do correctly. Fancy handling of ObjC varargs can also cause trouble. Most things involving math on an ObjC pointer is trickier. You shouldn't have much of this in any case.

  • You cannot put an id in a struct. This is fairly rare, but sometimes it's used to pack data.

  • If you did not follow correct KVC naming, and you intermix ARC and non-ARC code, you will have memory problems. ARC uses KVC naming to make decisions about memory management. If it's all ARC code, then it doesn't matter because it will do it the same "wrong" on both sides. But if it's mixed ARC/non-ARC then there's a mismatch.

  • ARC will leak memory during ObjC exception throws. An ObjC exception should be very close in time to the termination of your program. If you're catching a significant number of ObjC exceptions, you're using them incorrectly. This is fixable using -fobjc-arc-exceptions, but it incurs the penalties discussed below:

  • ARC will not leak memory during ObjC or C++ exception throws in ObjC++ code, but this is at the cost of both time and space performance. This is yet another in a long list of reasons to minimize your use of ObjC++.

  • ARC will not work at all on iPhoneOS 3 or Mac OS X 10.5 or earlier. (This precludes me from using ARC in many projects.)

  • __weak pointers do not work correctly on iOS 4 or Mac OS X 10.6, which is a shame, but fairly easy to work around. __weak pointers are great, but they're not the #1 selling point of ARC.

For 95%+ of code out there, ARC is brilliant and there is no reason at all to avoid it (provided you can handle the OS version restrictions). For non-ARC code, you can pass -fno-objc-arc on a file-by-file basis. Xcode unfortunately makes this much harder than it should be to do in practice. You should probably move non-ARC code into a separate xcodeproj to simplify this.

In conclusion, switch to ARC as soon as you can and never look back.

EDIT

I've seen a couple of comments along the lines of "using ARC is no substitute for knowing the Cocoa memory management rules." This is mostly true, but it's important to understand why and why not. First, if all of your code uses ARC, and you violate the Three Magic Words all over the place, you'll still have no problems. Shocking to say, but there you go. ARC might retain some things that you didn't mean it to retain, but it'll release them as well, so it'll never matter. If I were teaching a new class in Cocoa today, I'd probably spend no more than five minutes on the actual memory management rules, and I'd probably only mention the memory management naming rules while discussing KVC naming. With ARC, I believe you could actually become a decent beginning programmer without learning the memory management rules at all.

But you couldn't become a decent intermediate programmer. You need to know the rules in order to bridge correctly with Core Foundation, and every intermediate programmer needs to deal with CF at some point. And you need to know the rules for mixed-ARC/MRC code. And you need to know the rules when you start messing around with void* pointers to id (which you continue to need to perform KVO correctly). And blocks... well, block memory management is just weird.

So my point is that the underlying memory management is still important, but where I used to spend significant time stating and restating the rules for new programmers, with ARC it is becoming a more advanced topic. I'd rather get new developers thinking in terms of object graphs rather than fill their heads with the underlying calls to objc_retain().

share|improve this answer
 
 
Thanks for taking the time to type all that out Rob - after reading everything people have written here I think the biggest hurdle will be my initial mistrust of letting the compiler worry about it, and possibly sore hands after slapping myself everytime I start typing ret-(tab) or rel-(tab)! – Simon Withington Jan 6 '12 at 16:23
2  
One thing to be very careful of (in non-ARC as well, but moreso in ARC because it's so invisible now) is retain cycles. My advice here is 1) if you find yourself storing an objc block as an instance variable, take a long hard look at it to see if it could capture the object it's an ivar of, even indirectly. 2) Actually design your object graph, rather than just letting it happen. You must know what owns what if you want to write good code. 3) Use heapshots: friday.com/bbum/2010/10/17/… – Catfish_Man Jan 6 '12 at 19:33
1  
@Catfish_Man All good points. Retain loops have always been a problem. Apple's new advice is exactly as you say in #2. We need to think about object graphs rather than retain and release. #1 is a serious problem with blocks, and one of several reasons I find blocks a mixed blessing that should be approached with caution. – Rob Napier Jan 6 '12 at 19:40
2  
There is one serious downside that wasn't mentioned: cross-compatibility. For us brave and foolish souls that face the wastelands known as cross-platform programming, ARC simply isn't an option, at least not until GNU expand upon their ObjC runtime and compiler features again (they say more is on the way). – RabbitJan 10 '12 at 2:53
2  
You can use ARC except that you need to support iOS 3.x devices. BTW, make sure to use of Xcode to do the transition (Edit > Refactor > Convert to Objective-C ARC). During the process Xcode would do a lot of validation to make sure your code would work and figure out any codes that violates those designing guidelines. – ZhangChn Jan 18 '12 at 8:37