iOS 中的内存崩溃,实际内存使用量仅为 5megs

Posted

技术标签:

【中文标题】iOS 中的内存崩溃,实际内存使用量仅为 5megs【英文标题】:Memory crashes in iOS with real memory usage only at 5megs 【发布时间】:2010-10-27 16:45:34 【问题描述】:

一段时间以来,我一直在寻找我的应用程序中的内存泄漏。截至目前,当我在观看内存监控仪时在两个视图之间来回切换时,实际内存在 5 到 6 兆之间波动。这一切都很好——据我所知,当我从视图中弹出时,一切都得到了正确的释放。但是,每次我将视图推回视图堆栈时,虚拟内存继续增加,可用的实际内存迅速下降(即使应用程序的实际内存使用量没有增加)。最终,这一切都会导致内存不足崩溃。这是任何特定问题的迹象,还是我只是错过了某个地方的内存泄漏?

编辑:奇怪的是,当应用程序仍然只使用大约 5 兆的实际内存时,我遇到了内存不足的崩溃。

【问题讨论】:

【参考方案1】:

不要使用 -retainCount。

对象的绝对保留计数是没有意义的。这是一个实现细节。它可能会受到远远超出您的代码的许多因素的影响。

您应该调用release 的次数与您导致对象被保留的次数完全相同。不会少(除非您喜欢泄漏),当然也不会更多(除非您喜欢崩溃)。

详情请参阅Memory Management Guidelines。


在这种特定情况下,您正在泄漏内存,但泄漏无法找到它。泄漏的对象仍然以某种方式连接到整个应用程序的对象图。也许通过通知,也许通过委托,都没有关系——泄漏看到引用并得出结论,对象可能仍然存在。

使用分配工具。将其配置为仅跟踪实时分配(因为您不关心已被释放的对象)。用你的应用做一些事情。看看 Allocations 知道什么,并解释为什么所有这些对象都应该保留。您可以使用数据挖掘工具过滤到您的对象。

【讨论】:

【参考方案2】:

无论如何,您也可以使用“构建 -> 构建和分析”选项来查找可疑的非常规代码。

【讨论】:

更好的是,打开“运行静态分析器”构建设置,这样每次构建时 Xcode 都会运行分析器。【参考方案3】:

在较低的 API 层中可能会丢失内存的另一个原因是,如果您没有从视图层次结构中删除所有视图(也就是:不在任何地方调用 [view removeFromSuperview])。至少这似乎发生在我身上。

请注意,大多数时候这不是必需的,因为您只需释放主视图及其所有子视图,然后在需要时从视图控制器重建它。当您不释放整个层次结构而是简单地从层次结构中删除其中一些时,事情开始变得更加棘手。

在这种情况下,我得出的结论是,您可能仍有缓冲区或层缓存在较低的 API 部分中,在这种情况下,您的分配工具将无济于事。 为了正确监控,您需要使用“内存监视器”(在系统中)。您会看到“Physical Memory Free”线下降到接近 0 是发出内存警告的最可靠指标。 使用该仪器的另一个优点是,您可以将其附加到正在运行的进程中,从而可以轻松地将控制台输出和仪器一起运行。

【讨论】:

【参考方案4】:

循环引用也不会计入泄漏,但您可以在分配中跟踪这些引用。最好的办法是启动分配并达到您认为一切都应该消失(或某些对象应该消失)的状态。如果他们在附近闲逛,请深入了解他们并查看他们被保留的位置并理清正确的内存所有权/释放。

至于分配,它不跟踪的一些事情可能会影响整体内存。其中一些内容包括一些 CGImage 后备存储、一些 CoreAnimation 内容和一些数据库内容。

【讨论】:

将计算对象图中的循环引用,否则将与可达对象图隔离;泄漏确实会进行循环检测,但显然,对图中任何对象的误报会导致整个图被报告为未泄漏,因此循环引用有效地增加了泄漏未报告所有相关对象的机会。【参考方案5】:

您是否使用过“泄漏”性能工具?并查看 Organizer 中的日志,看看是否有任何内容。

还要查看视图控制器的 dealloc,并确保您正确地释放了它的所有对象?

【讨论】:

我使用了泄漏。它什么也没找到。我现在正在查看管理器中的设备日志。我的测试中有各种低内存日志,但我不知道如何利用这些信息。 你能在你的视图控制器中实现- (void)didReceiveMemoryWarning吗?推动视图控制器的内存症状听起来像是您可以在不释放所有旧实例的情况下创建新实例。 已经实现了,视图控制器都是自动释放的。 hmmm...也许查看视图控制器的dealloc并确保您正确释放所有对象?也许添加一个断点并检查它们的retainCount。您可以通过po [<variableName> valueForKeyPath:@"retainCount"] 在控制台中执行此操作 不!调用 -retainCount 是调试此类问题的一种可怕方法。它具有误导性且效率低下。

以上是关于iOS 中的内存崩溃,实际内存使用量仅为 5megs的主要内容,如果未能解决你的问题,请参考以下文章

Redis持久化磁盘IO方式及其带来的问题   有Redis线上运维经验的人会发现Redis在物理内存使用比较多,但还没有超过实际物理内存总容量时就会发生不稳定甚至崩溃的问题,有人认为是基于快照方式持

iOS:浏览器因内存不足而崩溃

iOS 内存崩溃上的 Web 音频 API

实际内存不断增加 - 从视图中删除子视图 - iOS (ARC)

如何调试由于内存压力导致的 iOS 崩溃

iOS 内存使用量增加直到崩溃