我在 ios 应用程序上运行 uiautomation 脚本。经过大约 40 次迭代后：
登录 一遍又一遍地点击几个按钮，然后注销
我到达了这个图表。
我的问题是关于分配图。它应该看起来像这样吗？我的脚本停止运行，我认为是因为内存泄漏太多？我知道泄漏在哪里，而且它一直都在同一个地方。但是随着时间的推移，分配图应该是这样的吗？我假设在理想的内存意识应用程序中，它基本上会保持 0 斜率。但这对我来说意味着随着时间的推移仍然有很多分配？
问题：图表应该看起来像这样吗？如果内存被正确释放（非弧），我正在执行的步骤是否应该保持倾斜的分配图/随着时间的推移？
不，图表不应该是这样的。分配通常应该回落（缓存除外，甚至那些在内存压力清除时也应该回落）。
但是，在您修复泄漏之前，不必担心分配问题。那可能会做到。修复泄漏并重复上述练习，看看分配是否平坦。如果没有，那么您可能还有其他问题。但是修复泄漏可能会完全解决这种情况。
此外，如果您还没有，请通过静态分析器运行该工具（Xcode“产品”菜单上的“分析”或按shift+ command+ B）。尤其是在 MRC 代码中，这将识别出许多常规内存管理问题。这就像魔术一样。在继续之前，请确保您在那里获得一份干净的健康单。
然后使用该Leaks工具精确定位泄漏的内容。然后，您可以诊断该特定对象泄漏的原因。在继续之前修复该泄漏。请参阅仪器用户指南的查找泄漏部分。
完成所有这些后，您可以重复原始问题的过程，并查看分配是否继续增长（例如，可能是由保留周期引起的）。如果您在修复上述泄漏后仍然遇到问题，则仪器中有一些技术可以识别增量分配的类型，然后您可以使用这些技术来追踪任何进一步的问题（如果有的话）。
例如：
运行Allocations工具，option在分配工具中单击并拖动，然后您可以查看调用树，它会显示正在消耗内存的内容。有关示例，请参见此答案。
运行该Allocations工具。让应用程序稳定下来。单击“标记堆”按钮。做一堆东西。回到你认为应该发布的地方。再次按“标记堆”。现在查看该堆快照并查看两个快照之间已分配但未释放的对象，您应该能够再次诊断出发生了什么。
但是，在您修复泄漏之前，所有这些都没有实际意义，并且该Leaks工具将比其他任何东西更有效地定位泄漏的对象。先解决这个问题，然后看看你的立场。
有关更多信息，您可能会发现WWDC 2012 iOS App Performance: Memory video 中的一些讨论很有用（尤其是在演示部分）。
请检查是否在 Edit Scheme:Diagnostics 中打开了 Zombies。僵尸永远不会被释放，如果您运行分配工具，则不会删除任何内容。