作为一名新的 Objective-C 开发人员，使用 ARC 时应该注意哪些与内存相关的问题？
最近我开始使用 Objective-C 为 iOS 5 设备编写代码。我的全新 MacBook 加载了 Xcode 4.2 和最新的 Mac 和 Mac 版本。 iOS SDK。到目前为止，这是一次有趣的体验，但我发现文档和可用书籍的当前状态存在一个问题。
具体来说，大多数书籍（尚未更新）总是提到如何以及何时管理你的记忆。这很棒，但是，当前的 SDK/编译器包括自动引用计数，并且由于我在项目中打开了此功能，所以我不知道我应该亲自监视和管理自己的内容。
我有 C# 背景。 C#（从技术上讲，.NET）中的内存管理完全由框架垃圾收集器处理。据我所知，ARC 实际上是一个编译器功能，可以自动在其所属的位置添加样板代码。此外，我试图尝试发现应该在哪里管理自己的对象释放，但除了编译器错误之外什么也没引起，因为 ARC 希望帮我处理它。
我还没有找到需要管理对象的情况。我变得“懒惰”，因为我不知道要监视和释放自己的内容，并且我完全不知道这种行为会如何影响我的应用程序的性能。
对于新用户来说，在 iOS 项目中使用 ARC 时应该注意哪些“陷阱”？我在这里阅读了一些有关内存管理和 ARC 的问题，但说实话，它们对新的 iOS 开发人员不太友好。有人可以给出一个合理的要点列表，解释需要注意哪些问题，以及何时需要自我管理记忆的公平指南吗？
Recently I've begun to code in Objective-C for iOS 5 devices. My brand new MacBook is loaded with Xcode 4.2 and the latest Mac & iOS SDKs. So far it's been a fun experience but there is one problem that I see with the current state of documentation and available books.
Specifically, most books (that have yet to be updated) always reference how and when to manage your memory. This is great, however, the current SDK/compiler includes Automatic Reference Counting and since I leave this turned on for my projects, I have no clue as to what I should personally monitor and manage myself.
I come from a C# background. Memory management in C# (technically, .NET) is entirely handled by the framework garbage collector. I understand that ARC is actually a compiler feature that automatically adds boiler-plate code where it belongs. Furthermore, my attempts to try and discover where I should manage my own releasing of objects has caused nothing but compiler errors because ARC wants to take care of it for me.
I have yet to find a case where I've needed to manage my objects. I am becoming "lazy" because I don't know what to monitor and release myself and I am completely oblivious about how this behavior could affect the performance of my application.
In new-user terms, what "gotchas" should I be aware of while using ARC in my iOS projects? I've read a few questions regarding memory management and ARC around here but, to be honest, they are not to friendly to the new iOS developer. Could someone please give a reasonable, bullet-point list that explains what problems and issues to watch out for, as well as a fair guide as to when self-management of memory is necessary?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
循环引用。当对象相互依赖时，它们就会泄漏。您需要将一些引用标记为弱，而 Instruments 可以帮助您找到这些引用。这些泄漏甚至不会显示为泄漏，因为它们相互之间具有强引用。
创建自动释放池
@autorelease，以在创建许多自动释放对象（直接或间接）时保持自动释放池的大小。具体来说，您的程序和您所依赖的程序将自动释放许多对象（ARC 或其他）。自动释放的对象是“将来”将被释放的对象。每个 Cocoa 程序都希望每个线程上都存在一个自动释放池。这就是为什么在创建新线程时创建一个新池，以及在main中创建一个新池的原因。池作为堆栈运行 - 您可以推送和弹出池。当池被销毁时，它会将延迟的release消息发送到它所持有的每个对象。这意味着具有许多临时分配的非常大的循环可能会导致许多对象仅由池引用，并且池可能会变得非常大。因此，在某些情况下，您可以直接耗尽管理池，以最大程度地减少等待释放和释放的对象数量。使用正确的桥接/转换。有时您需要显式管理生命周期。 ARC 可以处理明显的情况，但也有一些复杂的情况，您需要显式管理生命周期。
当使用
malloc'ed和new'ed分配，以及“核心”API中的不透明类型时。 ARC仅管理NSObject类型。在与这些 API 交互时，您仍然需要显式释放、删除这些分配、类型并使用正确的引用计数。始终遵循 NS-API 命名约定，并且 尽可能避免显式内存管理属性。
当您在没有 ARC 或 GC 的情况下编译源代码时，显然需要 MRC。在使用/与其他库/代码体一起工作时，这种情况很常见。当然，编译器会正确处理交互，因此您的 ARC 程序不应泄漏。
如果您使用正确的命名和书写风格，ARC 可以处理您所需的大部分，但也会有一些其他的特殊情况。幸运的是，如果您在开发过程中没有意识到这些问题，您仍然可以运行 Leaks 和 Zombies 来定位这些问题。
Circular References. When objects are codependent, they will leak. You will need to mark some references as weak, and Instruments can help you locate these references. These leaks won't even show up as leaks because they hold strong references to each other.
Create Autorelease Pools
@autoreleaseto keep autorelease pool sizes down where you create many autoreleased objects (directly or indirectly). Specifically, your program and programs you depend on willautoreleasemany objects (ARC or otherwise). An autoreleased object is one which will be released "in the future". Every Cocoa program expects an autorelease pool to exist on each thread. This is why you create a new pool when you create a new thread, and why you create one inmain. The pools operate as a stack - you may push and pop pools. When a pool is destroyed it sends its deferredreleasemessage to every object it holds. This means that really large loops with many temporary allocations may result in many objects which are referenced only by the pool, and the pool may grow very large. For this reason, you drain manage pools directly in some cases to minimize the number of objects that are waiting to be released and deallocated.Use proper bridging/casting. Sometimes you will need to manage lifetimes explicitly. ARC handles the obvious cases, but there are complex cases where you will need to manage lifetimes explicitly.
When using
malloc'ed andnew'ed allocations, as well as opaque types in 'Core' APIs. ARC only managesNSObjecttypes. You still need to explicitly free, delete, and use correct ref counting for these allocations, types, and when interfacing with those APIs.Always follow NS-API naming conventions, and avoid explicit memory management attributes where possible.
You'll obviously need MRC when you compile sources without ARC or GC. This is quite common when using/working with other libraries/code bodies. Of course, the compiler handles interactions correctly so your ARC program should not leak.
ARC handles most of what you will need if you use proper naming and written style, but there will be a few other corner cases. Fortunately, you can still run Leaks and Zombies to locate these issues if you don't realize them during development.