一段时间以来，我一直在寻找我的应用程序中的内存泄漏。截至目前，当我在观看内存监控仪时在两个视图之间来回切换时，实际内存在 5 到 6 兆之间波动。这一切都很好——据我所知，当我从视图中弹出时，一切都得到了正确的释放。但是，每次我将视图推回视图堆栈时，虚拟内存继续增加，可用的实际内存迅速下降（即使应用程序的实际内存使用量没有增加）。最终，这一切都会导致内存不足崩溃。这是任何特定问题的迹象，还是我只是错过了某个地方的内存泄漏？
编辑：奇怪的是，当应用程序仍然只使用大约 5 兆的实际内存时，我遇到了内存不足的崩溃。
【问题讨论】：
标签： iphone memory-leaks ios
对象的绝对保留计数是没有意义的。这是一个实现细节。它可能会受到远远超出您的代码的许多因素的影响。
您应该调用release 的次数与您导致对象被保留的次数完全相同。不会少（除非您喜欢泄漏），当然也不会更多（除非您喜欢崩溃）。
详情请参阅Memory Management Guidelines。
在这种特定情况下，您正在泄漏内存，但泄漏无法找到它。泄漏的对象仍然以某种方式连接到整个应用程序的对象图。也许通过通知，也许通过委托，都没有关系——泄漏看到引用并得出结论，对象可能仍然存在。
使用分配工具。将其配置为仅跟踪实时分配（因为您不关心已被释放的对象）。用你的应用做一些事情。看看 Allocations 知道什么，并解释为什么所有这些对象都应该保留。您可以使用数据挖掘工具过滤到您的对象。
【讨论】：
无论如何，您也可以使用“构建 -> 构建和分析”选项来查找可疑的非常规代码。
【讨论】：
在较低的 API 层中可能会丢失内存的另一个原因是，如果您没有从视图层次结构中删除所有视图（也就是：不在任何地方调用 [view removeFromSuperview]）。至少这似乎发生在我身上。
请注意，大多数时候这不是必需的，因为您只需释放主视图及其所有子视图，然后在需要时从视图控制器重建它。当您不释放整个层次结构而是简单地从层次结构中删除其中一些时，事情开始变得更加棘手。
在这种情况下，我得出的结论是，您可能仍有缓冲区或层缓存在较低的 API 部分中，在这种情况下，您的分配工具将无济于事。 为了正确监控，您需要使用“内存监视器”（在系统中）。您会看到“Physical Memory Free”线下降到接近 0 是发出内存警告的最可靠指标。 使用该仪器的另一个优点是，您可以将其附加到正在运行的进程中，从而可以轻松地将控制台输出和仪器一起运行。
【讨论】：
循环引用也不会计入泄漏，但您可以在分配中跟踪这些引用。最好的办法是启动分配并达到您认为一切都应该消失（或某些对象应该消失）的状态。如果他们在附近闲逛，请深入了解他们并查看他们被保留的位置并理清正确的内存所有权/释放。
至于分配，它不跟踪的一些事情可能会影响整体内存。其中一些内容包括一些 CGImage 后备存储、一些 CoreAnimation 内容和一些数据库内容。
【讨论】：
您是否使用过“泄漏”性能工具？并查看 Organizer 中的日志，看看是否有任何内容。
还要查看视图控制器的 dealloc，并确保您正确地释放了它的所有对象？
【讨论】：
- (void)didReceiveMemoryWarning吗？推动视图控制器的内存症状听起来像是您可以在不释放所有旧实例的情况下创建新实例。
po [<variableName> valueForKeyPath:@"retainCount"] 在控制台中执行此操作