使用Instruments进行iOS开发的模糊性

Question

我正在使用仪器分析应用程序。使用Allocations Tool以两种方式完成分析：

1. 在运行应用程序进行性能分析时直接选择分配
2. 在运行应用程序进行性能分析时选择泄漏。

在这两种情况下，我都启用了Allocations工具进行测试。但令人惊讶的是，在这些情况下，我有两种不同类型的Out-for Allocations。

他们应该表现得不一样吗？或者这是仪器的问题。

我使用泄漏工具描述的时间：

在分配图表中： 1.我在图表中获得了很多峰值，实时字节和总字节数是相同的。 2.使用1分钟后，我得到黑旗（我认为它会报警内存警告）。然后在出现一组标志后，我的应用程序崩溃了。 （有时会发生这种情况，即使直接在设备中运行App）

我使用分配工具分析的时间：

在分配图表中： 我经常没有像上面那样得到峰值。实时字节总是小于总字节数。 我已经使用了20多分钟而且从未得到过黑旗。

我了解到的一个事实是，当实时字节和总字节数相等时，可以启用NSZombieEnabled。

你们有没有遇到过这个问题。

更新1：

我遇到了第一个案件的另一个问题。每当我在短时间内进行分析后（与第二种情况下的分析相比），该应用程序获得了大量的黑旗和我的应用程序崩溃。 （由于记忆警告）

当我尝试类似的逐步使用Application时，我的应用程序没有崩溃并且没有标记。

为什么会出现这种差异？

Answer 1

在第一种情况下，您只跟踪实时分配，因为“泄漏”模板以这种方式配置分配工具。在第二种情况下，您将跟踪实时和取消分配的分配。 （正如CocoaFu所说）。

两者都很有用，但原因略有不同。

仅跟踪实时分配（通常与快照分析结合使用），是分析应用程序中永久堆增长的好方法。一旦你知道永远存在的东西，你就可以找出原因，看看是否有办法优化它。

跟踪所有分配（活动和死亡）是跟踪分配带宽的一种非常有效的方法。您可以按总字节排序，并从最大的＃开始。查看所有分配点（单击所选行类别中标签旁边的小箭头），并查看所有分配的来源。

例如，您的图表显示在该段时间内有1.27MB的14字节分配 - 9218个分配。所有这些都是免费的（）d [good！]，但这仍然代表了一堆工作要分配，填充数据（大概），并释放其中的每一个。这可能是一个问题，也许不是。

（为了正确看待这一点，我使用这种技术来优化应用程序。仅仅通过专注于减少瞬态 - 短期分配 - ，我能够使应用程序的主要算法速度提高5倍，减少85％的内存使用量。结果是应用程序复制字符串很多次。）

---

不确定您的应用为何如您所描述的那样崩溃。由于它是内存警告，您应该看到最常分配的内容。

请记住，如果启用了僵尸检测，则会占用大量额外内存。

Answer 2

根据分配实例化的方式，有不同的选项。通过单击“分配”磁贴中的“i”符号来检查选项。

是的，我觉得这也很烦人。