ARC，值得吗？
当我从C ++（和小Java）移到Objective C（iOS）时，我很难理解iOS中的内存pipe理。 但现在所有这一切似乎很自然，我知道保留，autorelease，复制和发布的东西。 在阅读了ARC之后，我想知道使用ARC还有更多好处，或者您不必担心内存pipe理。 在转向ARC之前，我想知道如何转向ARC。
- XCode具有“转换为Objective C ARC”菜单。 转换是如此简单（没有什么可担心的）？
- 它有助于我减less我的应用程序内存足迹，内存泄漏等（不知何故？）
- 它是否对我的应用程序有很多testing影响？
- 什么是非明显的优势？
- 任何移动到它的缺点？
这是我对ARC的具体看法：
1）XCode有“转换到Objective C ARC”菜单。 转换是如此简单（没有什么可担心的）？
这很简单。 有用。 用它。 正如Kevin Low所指出的那样，您将需要经过并修复使用Core Foundation对象的位。 __bridge需要__bridge或__bridge_transfer的健康捆绑。
2）它有助于我减less我的应用程序内存足迹，内存泄漏等（不知何故？）
不，不是。 好的，有点。 这将有助于减less之前编码不正确的内存泄漏。 它不会减less内存占用。
3）它是否对我的应用程序有太多的testing影响？
没有任何。
4）什么是非显而易见的优势？
未来。 编译器会对引用计数的对象有一个复杂的了解，所以会有更多的好处。 例如ARC已经提供了可爱的objc_retainAutoreleasedReturnValue优化，这非常好。
5）有什么缺点吗？
没有任何。
请听我的话，并开始使用ARC。 国际海事组织（IMO）没有理由不这样做，所以这些优势绝对是超出了这个劣势！
要深入了解ARC的工作方式，或许可以帮助说服你，这很好，请看看我的博客文章，题目是“ARC的风采” – 在 这里 ， 在这里和这里 。
以下是您真正需要了解的ARC的相关信息：
编译器比你更了解Objective-C和Cocoa。 我不是说这是一种侮辱; 它比我更了解它。 我认为你可以放心地说，它比世界上所有的人都更了解规则，但也许十几个人。 而且它知道把这些技巧用到我们无法重复的程度上，即使我们理解的也一样。
其余的只是细节：
- 你会写很多无聊的代码。 如此无聊的代码很容易犯错。
- 作为一个混合的编译时间和运行时间的过程，它可以访问你不知道的技巧。
- 即使你编写理论上完美的内存pipe理代码，编写内存pipe理代码的工作也会比你做得更好。
- 它会减less“高潮”的内存使用（有点），没有你的努力。
- 通过清零弱引用，避免由悬挂指针引起的崩溃更容易。
- 如果你正在开始一个新的应用程序，停止考虑它，只是使用它。
- 如果你有一个现有的应用程序：
- 您将需要重新testing它。 你需要确保你没有循环引用。
- 如果您有一个现有的iOS 5之前的iOS应用程序，则不支持调零弱引用。 你应该认真考虑需要iOS 5。
- 如果您有一个针对iOS 4之前的iOS的现有应用程序，则根本无法使用它。 你在想什么，支持那个老废话？！？
- 在Xcode的最后一个版本中，它不是完全没有bug的。 这可能还不是。 但它仍然值得使用。
-
如果你使用的是Core Foundation或者非Objective-C的代码，那么就不是那么简单，你需要手动检查你的代码，并且确保Objective-C和Core Foundation之间的所有转换都是桥接的（如果你有铸）。 您还需要pipe理非Objective-C代码的内存。
-
它应该基本上为你处理所有的内存泄漏，因为它可以自动保留，释放，复制等。到目前为止，自从切换到ARC之后，我从来没有发生Objective-C泄漏。
-
编号可能稍微长一些，因为它必须通过所有代码并插入所有保留和释放代码。
-
不知道有没有。 最后，所有的ARC都是一个automator。
-
你将不得不学习桥接模型以及你不能build立任何低于iOS 4的东西。
最后，这绝对是值得的。 我一开始很怀疑，但是在看完WWDCvideo后，他们解释了它是如何工作的，我越来越喜欢它了。
你有没有读过苹果的ARC文档 ？ 它回答了你所问的很多问题。
根据我的经验，这是我的想法：
- 是的，这很简单。 不过，你必须在转换后testing你的应用程序。
- 它可以帮助减less你的应用程序的内存使用和泄漏，但不能保证这样做。
- 是。 转换成ARC之后，你会想testing。
- 您不必浪费太多时间思考和追踪泄漏。 您可以花更多的时间和精力在应用程序的实际代码上，而不用担心保留/释放。 即使保留/释放代码对你来说是自然而容易的，你也不是绝对可靠的，你偶尔会忘记释放一些东西。 ARC不会忘记。
- 如果您支持iOS 4，则必须处理弱引用，因为ARC不支持iOS 4中的引用。
3）你应该重新testing你的应用程序，但根据我的经验，它几乎只是工作。 尽pipe看看所有的编译器警告！
4）非显而易见的优势：当您不必考虑内存pipe理时，编写代码的速度会更快。 也许这是显而易见的，但它的帮助仍然让我感到惊讶。
5）缺点：真的唯一的缺点是不得不closures一些第三方库的ARC。
ARC一直非常有用，我不会再没有它的代码了。 没有理由必须处理所有这一切，并且在实践中运作良好。
观看ARC上的WWDCvideo： https ： //developer.apple.com/videos/wwdc/2011/？ id = 323
苹果在该video中的官方立场是所有可以使用ARC的应用都应该使用ARC。 video是为什么的，对这项技术是一个很好的概述，所以我不打算在这里重复一遍。
我发现：ARC使你的代码更快。 在苹果的WWDCvideo中，他们说，每个NSObject的保留和释放方法都保存了几个CPU周期。 这是因为不再需要在运行时检查它（现在是外包给编译器）。 每个保留约6个CPU周期。 如果你使用一个能创build很多对象的循环，那么你真的可以感受到它的不同。
ARC不仅使代码更快，而且编写的代码更less，从而大大加快了开发过程。 最后但并非最不重要的是你不能search大约90％的代码中的内存泄漏。 如果你不使用很多底层的东西，它们必须使用“__bridge casts”，那么你完全是内存泄漏。
结论：如果你能做到这一点，做吧！