ARC 还是不 ARC?优缺点都有什么? [英] To ARC or not to ARC? What are the pros and cons?

问题描述

我还没有使用 ARC，因为我目前正在处理的项目中的大部分代码都是在 iOS 5.0 之前编写的.

I've yet to use ARC, since the majority of the code in the project I'm working on at the moment was written pre-iOS 5.0.

我只是想知道，不手动保留/释放(以及由此产生的可能更可靠的代码?)的便利性是否超过了使用 ARC 的任何成本"?您对 ARC 有何体验，您会推荐它吗?

I was just wondering, does the convenience of not retaining/releasing manually (and presumably more reliable code that comes as a result?) outweigh any 'cost' of using ARC? What are your experiences of ARC, and would you recommend it?

所以:

• ARC 能为项目带来多少好处?
• ARC 是否有与 Java 中的垃圾收集类似的成本?
• 您是否一直在使用 ARC，如果使用过，到目前为止您是如何找到它的?

推荐答案

没有缺点.用它.今天就去做.它比您的旧代码更快.它比你的旧代码更安全.它比您的旧代码更容易.这不是垃圾收集.它没有 GC 运行时开销.编译器在您应该拥有的所有位置插入保留和释放.但它比你更聪明，可以优化掉那些实际上不需要的(就像它可以展开循环、消除临时变量、内联函数等)

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 overhead. 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:

• 如果您是一名长期的 ObjC 开发人员，当您看到 ARC 代码时，您会抽搐大约一周.你很快就会克服这个问题.

• 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.

在桥接到 Core Foundation 代码时有一些(非常)小的复杂性.处理任何将 id 视为 void* 的东西，会稍微复杂一些.诸如 id 的 C 数组之类的事情可能需要更多思考才能正确执行.ObjC va_args 的花哨处理也会导致麻烦.大多数涉及 ObjC 指针数学的事情都比较棘手.无论如何，你不应该有太多这样的东西.

There are 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 of id can take a little more thinking about to do correctly. Fancy handling of ObjC va_args can also cause trouble. Most things involving math on an ObjC pointer is trickier. You shouldn't have much of this in any case.

您不能将 id 放在 struct 中.这种情况很少见，但有时用于打包数据.

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

如果您没有遵循正确的 KVC 命名，并且您混合使用 ARC 和非 ARC 代码，则会出现内存问题.ARC 使用 KVC 命名来决定内存管理.如果都是 ARC 代码，那么没关系，因为它会在双方都做同样的错误".但如果它混合了 ARC/非 ARC，那么就会出现不匹配.

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 会在 ObjC 异常抛出期间泄漏内存.ObjC 异常应该非常接近程序终止的时间.如果您捕获了大量 ObjC 异常，则说明您使用它们的方式不正确.这可以使用 -fobjc-arc-exceptions 解决，但会招致下面讨论的惩罚:

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 不会在 ObjC++ 代码中的 ObjC 或 C++ 异常抛出期间泄漏内存，但这是以时间和空间性能为代价的.这是尽量减少 ObjC++ 使用的众多原因中的另一个.

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 在 iPhoneOS 3 或 Mac OS X 10.5 或更早版本上根本不起作用.(这使我无法在许多项目中使用 ARC.)

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 指针在 iOS 4 或 Mac OS X 10.6 上无法正常工作，这很遗憾，但很容易解决.__weak 指针很棒，但它们不是 ARC 的第一卖点.

__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.

对于 95% 以上的代码，ARC 非常出色，完全没有理由避免它(前提是您可以处理操作系统版本限制).对于非 ARC 代码，您可以逐个文件地传递 -fno-objc-arc.不幸的是，Xcode 使这变得比在实践中应该做的要困难得多.您可能应该将非 ARC 代码移动到单独的 xcodeproj 中以简化此操作.

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.

总而言之，尽快切换到 ARC，永远不要回头.

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

编辑

我已经看到一些评论使用 ARC 不能替代了解 Cocoa 内存管理规则".这在很大程度上是正确的，但重要的是要了解原因和原因.首先，如果您的所有代码都使用 ARC，并且您违反了三个魔法词到处都是，你仍然没有问题.说起来令人震惊，但你去了.ARC 可能会保留一些您不想保留的东西，但它也会释放它们，所以这无关紧要.如果我今天在 Cocoa 中教一门新课程，我可能不会在实际内存管理规则上花超过五分钟的时间，而且我可能只会在讨论 KVC 命名时提到内存管理命名规则.有了 ARC，我相信你实际上可以成为一个体面的初级程序员，而无需学习内存管理规则.

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.

但是你不可能成为一个像样的中级程序员.您需要了解规则才能与 Core Foundation 正确桥接，每个中级程序员都需要在某个时候处理 CF.并且您需要了解混合 ARC/MRC 代码的规则.当您开始使用 void* 指向 id 的指针时，您需要知道规则(您继续需要正确执行 KVO).还有块……嗯，块内存管理很奇怪.

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.

所以我的观点是底层内存管理仍然很重要，但是我曾经花大量时间为新程序员陈述和重申规则，而 ARC 正在成为一个更高级的话题.我宁愿让新开发人员从对象图的角度思考，而不是用对 objc_retain() 的底层调用来填补他们的头脑.

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().

这篇关于ARC 还是不 ARC?优缺点都有什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！