ARC，值得与否？

Question

当我从C ++（和小Java）转移到Objective C（iOS）时，我很难理解iOS中的内存管理。但现在这一切看起来很自然，我知道保留，自动释放，复制和发布的东西。在阅读了ARC之后，我想知道使用ARC有什么好处，或者只是你不必担心内存管理。在转向ARC之前，我想知道如何转向ARC。

1. XCode具有“转换为Objective C ARC”菜单。转换是否那么简单（没什么可担心的）？
2. 它是否有助于我减少我的应用程序内存占用空间，内存泄漏等（不知何故？）
3. 它对我的应用程序有很大的测试影响吗？
4. 什么是非显而易见的优势？
5. 移动它的任何不利之处？

Answer 1

以下是我对ARC的具体看法：

  

1）XCode具有“转换为Objective C ARC”菜单。转换是否那么简单（没什么可担心的）？

这很简单。有用。用它。正如Kevin Low指出的那样，你将需要经历并修复使用Core Foundation对象的位。这只需要__bridge or __bridge_transfer的健康绑定。

  

2）它是否有助于我减少我的应用程序内存占用空间，内存泄漏等（不知何故？）

不，不是真的。好的，有点儿。它有助于减少以前编码错误的内存泄漏。它不会减少内存占用。

  

3）它对我的应用程序有很大的测试影响吗？

无论如何。

  4）什么是非显而易见的优势？

未来。将会有更多的奖励，编译器会对对象的引用计数进行复杂的了解。例如，ARC已经提供了可爱的objc_retainAutoreleasedReturnValue优化，这非常好。

  

5）移动它的任何不利因素？

无论如何。

请接受我的说法并开始使用ARC。没有理由（IMO）没有，因此优势肯定超过了劣势！

要深入了解ARC的工作方式，或许有助于让您相信它的优点，请查看我的博客帖子，题为“在ARC的视线下” - here，here ，here＆amp; here

Answer 2

以下是您真正需要了解的ARC：

编译器比你更了解Objective-C和Cocoa。我不是说这是一种侮辱;它比我更了解它。我认为你可以放心地说它比全世界的十几个人更了解规则。它知道使用它们的技巧，你和我不能重复，即使我们理解它也是如此。

其余的只是细节：

• 你会写一些不那么无聊的代码。代码如此无聊，很容易出错。
• 作为混合编译时和运行时进程，它可以访问您没有的技巧。
  • 即使您编写理论上完美的内存管理代码，编写内存管理代码的工作也会比您更好。
  • 它将减少“高潮”内存使用量（有点），而不需要您付出任何努力。
  • 通过归零弱引用，可以更轻松地避免因悬空指针引起的崩溃。
• 如果您要开始使用新应用程序，请不要再考虑它并使用它。
• 如果您有现有的申请：
  • 您需要重新测试它。您需要确保没有循环引用。
  • 如果您有一个在iOS 5之前针对iOS的现有应用程序，则不支持将弱引用归零。 您应该认真考虑要求iOS 5。
  • 如果您有一个在iOS 4之前以iOS为目标的现有应用程序，则根本无法使用它。 你在想什么，支持旧的垃圾？！？
• 在最新版本的Xcode中，它不是完全无bug。它可能仍然不是。但它仍然值得使用。

Answer 3

1. 如果你正在使用Core Foundation或非Objective-C代码，那么它就不那么简单了，你必须手动完成代码并确保Objective-C和Core Foundation之间的所有演员都是桥接（如果你有任何演员表）。您还需要为非Objective-C代码管理内存。

2. 它应该基本上为你处理所有内存泄漏，因为它会自动保留，释放，复制等。到目前为止，我从来没有因为切换到ARC而发生Objective-C泄漏。 / p>

3. 没有。构建可能需要更长的时间，因为它必须遍历所有代码并插入所有保留和释放代码。

4. 不确定是否有。最后，所有ARC都是自动机。

5. 您必须了解桥接演员表以及无法构建低于iOS 4的任何内容。

最后，它绝对值得。起初我对此持怀疑态度，但在观看WWDC视频后，他们解释了它是如何工作的，我越来越喜欢它了。

Answer 4

您是否阅读过Apple's documentation on ARC？它回答了你提出的很多问题。

根据我的经验，这就是我的想法：

1. 是的，很简单。但是，你肯定需要在转换后测试你的应用程序。
2. 可以帮助减少应用内存使用和泄漏，但不能保证这样做。
3. 是。转换为ARC后，您需要进行测试。
4. 您不必浪费太多时间考虑和追踪泄漏。您可以在应用程序的实际代码上花费更多时间和精力，而不必担心保留/释放。即使保留/释放代码对您来说自然而且容易，但您并不是绝对正确的，而且您偶尔会忘记发布一些内容。 ARC不会忘记。
5. 如果您支持iOS 4，则必须处理弱引用，因为ARC不支持iOS 4中的引用。

Answer 5

3）你应该重新测试你的应用程序，但根据我的经验，它几乎只是工作。尽管如此，请仔细查看所有编译器警告!!!

4）非显而易见的优点：当您不必考虑内存管理时，编码真的会更快。也许这很明显，但它帮助的数量仍让我感到惊讶。

5）缺点：唯一的缺点是必须为某些第三方库关闭ARC。

ARC一直非常有用，我根本不会在没有它的情况下进行编码。没有理由不再需要处理所有这些问题，而且在实践中它运作良好。

Answer 6

观看ARC上的WWDC视频： https://developer.apple.com/videos/wwdc/2011/?id=323

Apple在该视频中的官方立场是，所有可以使用ARC的应用都应该使用ARC。视频介绍了为什么，并且是对该技术的精彩概述，因此我不打算在此重复所有内容。

Answer 7

我发现：ARC使您的代码更快。他们说，在Apples WWDC视频中，为每个NSObject的保留和释放方法保存了几个CPU周期。这是因为不再需要在运行时检查它（它现在外包给编译器）。每次保留大约有6个CPU周期。如果你使用一个创建大量对象的循环，那么你真的可以感受到它的不同。

ARC不仅使代码更快，而且编写的代码更少，从而大大加快了开发过程。最后但并非最不重要的是，您不得在大约90％的代码中搜索内存泄漏。如果你不使用很多低级的东西，它们必须使用“__bridge强制转换”，那么你完全没有内存泄漏。

结论：如果你能做到，那就做吧！