使用ARC的优点和缺点是什么？ [英] What are the advantages and disadvantages of using ARC?

问题描述

在iOS项目中使用新的自动引用计数（ARC）内存管理方式有哪些优缺点？

What are the advantages and disadvantages of using the new automatic reference counting (ARC) memory management style in an iOS project?

您可以选择不使用ARC吗？使用iOS 5.0 SDK进行开发？

Can you choose not to use ARC when developing with the iOS 5.0 SDK?

您是否建议为新项目使用ARC或手动引用计数（MRC）？

Do you recommend ARC or manual reference counting (MRC) for a new project?

使用ARC的应用程序是否能够在比iOS 5.0更旧的操作系统版本上运行？

Will an application using ARC be able to run on older OS versions than iOS 5.0?

推荐答案

在iOS项目中使用新的自动引用计数（ARC）内存管理方式有哪些优缺点？

What are the advantages and disadvantages of using the new automatic reference counting (ARC) memory management style in an iOS project?

ARC程序的执行与编写良好的MRC几乎相同。也就是说，行为差异通常是不可检测的，因为操作顺序和性能都非常接近。

An ARC program's execution is nearly identical to well written MRC. That is, the behavioral differences are often undetectable because both the order of operations and performance are very close.

如果您已经知道如何使用手动实现OS X或iOS应用程序引用计数（MRC），ARC并没有真正添加功能 - 它只允许您从源中删除引用计数操作。

If you already know how to implement OS X or iOS apps with manual reference counting (MRC), ARC doesn't really add functionality -- it just allows you to remove reference counting operations from your sources.

如果您不想学习MRC，然后你可能想先尝试ARC。很多人都在努力或者试图忽略MRC的常见做法（例如：我向静态分析器介绍了一些objc开发人员）。如果你想避免这些问题，ARC将允许你推迟你的理解;如果不了解引用计数和对象生命周期和关系，无论是MRC，ARC还是GC，都无法编写重要的objc程序。 ARC和GC只是从您的源中删除实现，并在大多数情况下做正确的事情 。使用ARC和GC，您仍然需要提供一些指导。

If you don't want to learn MRC, then you may want to first try ARC. A lot of people struggle with, or try to ignore common practices of MRC (example: I've introduced a number of objc devs to the static analyzer). If you want to avoid those issues, ARC will allow you to postpone your understanding; you cannot write nontrivial objc programs without understanding reference counting and object lifetimes and relationships, whether MRC, ARC, or GC. ARC and GC simply remove the implementation from your sources and do the right thing in most cases. With ARC and GC, you will still need to give some guidance.

我没有测量过这个，但值得一提的是编译 ARC来源需要更多时间和资源。

I've not measured this, but it may be worth mentioning that compiling ARC sources would take more time and resources.

如果您正在开发的程序使用引用计数相当松散（例如典型的自动释放量），请切换到ARC 可以真正改善程序的执行时间和峰值内存使用率。

If the program you're developing has rather loose usage of reference counting (e.g. a typical amount of autoreleases), switching to ARC could really improve your program's execution times and peak memory usage.

你可以选择不使用ARC时使用iOS 5.0 SDK进行开发？

Can you choose not to use ARC when developing with the iOS 5.0 SDK?

是的，使用CLANG_ENABLE_OBJC_ARC。 ARC是二进制兼容的，所有真正发生的事情是编译器会根据当前转换的可见声明自动为您引入适当的引用计数操作（请参阅我的答案，了解为什么翻译可见性很重要）。因此，您还可以为项目中的某些源启用和禁用它，并为其他源启用它。

Yes, using CLANG_ENABLE_OBJC_ARC. ARC is binary compatible, and all that really happens is that the compiler does its best to introduce the appropriate reference counting operations automatically for you, based on the declarations visible to the current translation (see my answer here as to why translation visibility is important). Therefore, you can also enable and disable it for some sources in a project and enable it for others.

混合模式（某些MRC和某些ARC源）非常复杂并且巧妙地，特别是，可以由编译器复制的实现（例如，内联函数的主体可能是不正确的）。这种混合模式问题很难分离。在这方面，ObjC ++程序和来源将特别难以实现。此外，行为可能会根据您的优化设置而有所不同（作为一个示例）;在调试版本中完美运行的程序可能会在发布时引入泄漏或僵尸。

Mixed mode (some MRC and some ARC sources) is however quite complicated, and subtly, notably wrt implementations which may be duplicated by the compiler (e.g. an inline function's body may be incorrect). Such mixed mode issues will be very difficult to isolate. ObjC++ programs and sources will be particularly difficult in this regard. Furthermore, the behavior may differ based on your optimizations settings (as one example); a program which works perfectly in a debug build may introduce a leak or zombie in release.

您是否建议使用ARC或手动引用计数（MRC） ）对于一个新项目？

Do you recommend ARC or manual reference counting (MRC) for a new project?

就个人而言，我会坚持使用MRC一段时间。即使ARC已经在实际使用中进行了测试，但很可能会出现一些问题，这些问题会出现在复杂的场景中，您可能希望避免成为第一个知道和调试的问题。 OS X的垃圾收集是您可能想要等待的原因的一个示例。作为一个例子，交换机可以在对象被销毁时进行更改 - 您的对象可能会被更快地销毁，并且永远不会被放置在自动释放池中。它也可以改变释放ivars的顺序，这可能会产生一些副作用。

Personally, I'll be sticking with MRC for some time. Even if ARC has been tested in real world usage, it's likely that there are a number issues remaining which show up in complex scenarios, which you will want to avoid being the first to know and debug. OS X's Garbage Collection is an example of why you may want to wait. As one example, the switch could alter when objects are destroyed -- your objects may be destroyed sooner and never be placed in autorelease pools. It could also change the order in which ivars are released, which could have some side effects.

我还有一个很大的代码库，我不想丢失一周此时正在测试此功能。最后，向后兼容性对我来说仍然很重要。

I also have a large codebase that I don't want to lose a week testing this feature for at this time. Finally, backwards compatibility is still important for me.

使用ARC的应用程序是否能够在比iOS 5.0更旧的操作系统版本上运行？

Will an application using ARC be able to run on older OS versions than iOS 5.0?

如果您使用MRC进行开发，它将向后兼容。如果使用ARC开发，则不一定兼容。事实上，如果没有一点额外的工作，它甚至可能无法编译。某些早期版本中提供了运行时的要求。 另见这个问题。如果您需要向后兼容性，ARC将不适用于某些操作系统版本。

If you develop with MRC, it will be backwards compatible. If you develop with ARC, it will not necessarily be compatible. In fact, it may not even compile without a little extra work. The requirements for the runtime are available in some earlier versions. See also this question. If you need backwards compatibility, ARC will not be an option for some OS versions.

最后，如果您要将选择限制为GC或ARC，我建议ARC。

Lastly, if you were to limit the choice to GC or ARC, I'd recommend ARC.

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