问题描述

在 iOS 项目中使用新的自动引用计数 (ARC) 内存管理样式有哪些优点和缺点?

在使用 iOS 5.0 SDK 进行开发时，是否可以选择不使用 ARC?

对于新项目，您建议使用 ARC 还是手动引用计数 (MRC)?

使用 ARC 的应用程序能否在比 iOS 5.0 更早的操作系统版本上运行?

在 iOS 项目中使用新的自动引用计数 (ARC) 内存管理样式有哪些优点和缺点?

ARC 程序的执行几乎与编写良好的 MRC 相同.也就是说，由于操作顺序和性能非常接近，因此通常无法检测到行为差异.

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

如果您不想学习 MRC，那么您可能想先尝试 ARC.很多人都在纠结，或者试图忽略 MRC 的常见做法(例如:我已经向静态分析器介绍了一些 objc 开发人员).如果您想避免这些问题，ARC 将允许您推迟理解；如果不了解引用计数、对象生命周期和关系，无论是 MRC、ARC 还是 GC，您就无法编写非平凡的 objc 程序.ARC 和 GC 只是从您的源代码中删除实现并做正确的事情在大多数情况下.对于 ARC 和 GC，您仍然需要提供一些指导.

我没有对此进行测量，但值得一提的是，编译 ARC 源代码会花费更多时间和资源.

如果您正在开发的程序对引用计数的使用相当松散(例如，自动释放的典型数量)，切换到 ARC可以真正改善程序的执行时间和峰值内存使用率.p><块引用>

在使用 iOS 5.0 SDK 进行开发时，是否可以选择不使用 ARC?

是的，使用 CLANG_ENABLE_OBJC_ARC.ARC 是二进制兼容的，真正发生的事情是编译器会尽力为您自动引入适当的引用计数操作，基于对当前翻译可见的声明 (请参阅我的回答，了解为什么翻译可见性很重要).因此，您还可以为项目中的某些源启用和禁用它，并为其他源启用它.

然而，混合模式(一些 MRC 和一些 ARC 源代码)相当复杂，而且很微妙，尤其是编译器可能会复制的 wrt 实现(例如，内联函数的主体可能不正确).这种混合模式问题将很难隔离.在这方面，ObjC++ 程序和源代码将特别困难.此外，行为可能会根据您的优化设置而有所不同(例如)；在调试版本中完美运行的程序可能会在发布时引入泄漏或僵尸.

<块引用>

对于新项目，您建议使用 ARC 还是手动引用计数 (MRC)?

就个人而言，我会坚持使用 MRC 一段时间.即使 ARC 已经在现实世界的使用中进行了测试，也可能存在许多问题，这些问题会出现在复杂的场景中，您会希望避免成为第一个知道和调试的人.OS X 的垃圾收集是您可能想要等待的一个例子.举个例子，当对象被销毁时，开关可能会改变——您的对象可能会更快地被销毁并且永远不会被放置在自动释放池中.它还可能会更改 ivars 的发布顺序，这可能会产生一些副作用.

我也有一个庞大的代码库，我不想为此浪费一周的时间来测试这个功能.最后，向后兼容性对我来说仍然很重要.

<块引用>

使用 ARC 的应用程序能否在比 iOS 5.0 更早的操作系统版本上运行?

如果您使用 MRC 进行开发，它将向后兼容.如果你用 ARC 开发，它不一定兼容.事实上，如果没有一点额外的工作，它甚至可能无法编译.运行时的要求在一些早期版本中可用.另请参阅此问题.如果您需要向后兼容，ARC 将不是某些操作系统版本的选项.

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

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

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

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

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

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

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.

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.

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.

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

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.

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

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.

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.

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

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.

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

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.

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

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