我已阅读 Apple 的内存管理指南，并认为我了解应遵循的做法以确保在我的应用程序中进行正确的内存管理。
目前看起来我的代码中没有内存泄漏。但是随着我的代码变得越来越复杂，我想知道是否应该遵循任何特定的模式来跟踪对象的分配和释放。
创建在整个应用程序执行过程中存在的某种全局对象是否有意义，其中包含某种类型的活动对象的数量？每个对象都可以在其 init 方法中增加其类型的计数，并在 dealloc 中减少它。全局对象可以在适当的时候验证特定类型的计数是否为零。
编辑：我也知道如何使用泄漏，以及如何使用 Xcode 分析项目。这篇文章的原因是跟踪可能无法通过泄漏检测或分析的案例。
编辑：此外，拥有这样的东西似乎是有意义的，这样可以通过运行检查全局对象的单元测试及早在构建中检测到泄漏。我想作为一个没有经验的 Objective-c 程序员，我会从其他人的观点中受益。
每个对象都可以在其 init 方法中增加其类型的计数，并在 dealloc 中减少它。
要做到这一点，您必须执行以下操作之一：1) 在某个公共点覆盖行为，例如 NSObject 的-initor ，或 2) 将适当的代码添加到每个类的指定初始化程序。两者似乎都不简单。
全局对象可以在适当的时候验证特定类型的计数是否为零。
听起来不错，但你能详细说明一下“适当的时间”吗？在程序生命周期的任何给定时间点，您如何知道哪些类应该有零实例？你有一个很好的想法，在程序结束时不应该有任何对象，但在这种情况下 Instruments 可以告诉你同样的事情。
Objective-C 已经采取了几个步骤来简化内存管理。尽可能使用属性和合成访问器，因为它们本质上是为您管理对象。最近的一项改进是 ARC，它进一步实现了大多数内存管理任务的自动化。您基本上让编译器找出将内存管理调用放在哪里——这就像没有垃圾收集器的垃圾收集。在尝试发明新工具之前，先学会使用这些工具。
不要走那条路......这是单一继承的痛苦。最重要的是，在您认为必须创建一些全局计数器之前，您应该掌握这些出色的工具。全局计数器已经存在于一些工具中——学习它们！
对抗它的方法是学习如何在编写时正确平衡和管理所有内容。事后看来，这真的很简单。
ARC 是另一种选择——实际上只是推迟了你的理解。
我推荐使用第一个“设计模式”release而不是autorelease尽可能使用它（尽管通常对过度发布更有用）。
接下来，定期运行泄漏工具/工具并立即修复所有泄漏/僵尸。
第三，边走边学现有工具！这些工具可以做一些非常疯狂的事情，比如记录每个分配和每个引用计数的回溯。您可以暂停程序的执行并查看存在的分配、分配计数、回溯和各种其他统计信息。