作为一名新的Objective-C开发者，使用ARC，我应该注意哪些与内存相关的问题？
作为一名新的Objective-C开发者，使用ARC，我应该注意哪些与内存相关的问题？
最近我开始在iOS 5设备上编写Objective-C代码。 我的全新MacBook装载了Xcode 4.2和最新的Mac和iOS SDK。 到目前为止，这是一次有趣的经历，但是当前文档和可用书籍的现状存在一个问题。
具体而言，大多数（尚未更新的）书籍总是提到如何何时管理内存。 这很好，但是当前的SDK /编译器包括自动引用计数，因此我将其用于我的项目，因此我不知道应该个人监视和管理什么。
我来自C＃背景。 C＃（技术上是.NET）中的内存管理完全由框架垃圾回收器处理。 我理解ARC实际上是编译器功能，可以自动在适当的位置添加样板代码。 此外，我试图探索自己在哪里应该管理释放对象的尝试只会引起编译器错误，因为ARC想要替我处理它。
我还没有发现需要管理对象的情况。 我正在变得“懒惰”，因为我不知道应该监视和自行释放什么，而且我对这种行为如何影响应用程序性能完全不知情。
在新用户的术语中，使用ARC在我的iOS项目中应该注意哪些问题？ 我在这里阅读了一些有关内存管理和ARC的问题，但老实说，它们对新的iOS开发人员并不友好。 请问有人能给出一个合理的，列出了需要注意的问题和问题以及必要时自我管理内存的公正指南的点形式清单吗？
-
循环引用。当对象相互依存时，它们将会泄漏。您需要将某些引用标记为弱引用，Instruments 可帮助您定位这些引用。这些泄漏甚至不会显示为泄漏，因为它们对彼此保持强引用。
-
创建 @autorelease 池，以使您创建了许多自动释放的对象（直接或间接）时，可以使自动释放池的大小保持在合理范围内。具体而言，您的程序及其所依赖的程序会自动释放许多对象（包括 ARC 或其他类型）。自动释放的对象是一种“将来释放”的对象。每个 Cocoa 程序都希望在每个线程上存在一个 autorelease 池。这就是在创建新线程时创建新池的原因，以及为什么在主池中创建一个池。这些池操作类似于一个堆栈，您可以压入和弹出池。当池被销毁时，它会向它持有的每个对象发送延迟的 release 消息。这意味着对于具有许多临时分配的非常大的循环，可能会产生许多仅由池引用的对象，并且池可能会变得非常大。因此，在某些情况下，您需要直接管理池，以最小化等待释放和解除分配的对象的数量。
-
使用适当的桥接/强制类型转换。有时您需要明确管理对象的生命周期。ARC 处理了显而易见的情况，但在一些复杂的情况下，您需要明确管理生命周期。
-
在使用 malloc 和 new 分配以及不透明类型时，请注意 'Core' API。ARC 只管理 NSObject 类型。您仍然需要显式释放、删除和使用正确的引用计数来处理这些分配、类型，并在与这些 API 进行交互时使用。
-
始终遵循 NS-API 命名约定，并尽可能避免使用显式内存管理属性。
-
当您编译没有 ARC 或 GC 的源代码时，您显然需要使用 MRC。当使用/与其他库/代码体一起使用时，这是非常常见的。当然，编译器会正确处理交互，所以您的 ARC 程序不会泄漏。
-
如果您使用正确的命名和编写样式，ARC 将处理您大部分需要的内容，但还会有一些边角情况。幸运的是，如果您在开发过程中没有意识到它们，您仍然可以运行 Leaks 和 Zombies 来定位这些问题。