ios - 使用 Instruments 进行 iOS 开发的歧义

Question

我正在使用 Instruments 分析应用程序。分析是使用分配工具以两种方式完成的:

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

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

他们的行为应该有所不同吗？或者这是 Instruments 的问题。

我使用 Leaks Tool 分析的时间:

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

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

在分配图中: 1. 我不会像上述情况那样经常出现峰值。 Live bytes 总是远小于 Overall bytes。2. 我已经使用了20多分钟，从来没有黑旗。

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

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

更新 1:

我在第一个案例中遇到了另一个问题。每当我在短时间内进行分析时(与第二种情况下的分析相比)，该应用程序都会收到大量黑旗并且我的应用程序崩溃了。 (由于内存警告)

当我尝试类似的逐步使用应用程序时，我的应用程序没有崩溃，也没有得到任何标志。

为什么会出现这种差异？

Answer 1

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

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

仅跟踪实时分配(通常结合 Heapshot Analysis)是分析应用程序中永久堆增长的好方法。一旦您知道什么东西会永远存在，您就可以找出原因并看看是否有办法对其进行优化。

跟踪所有分配，无论是活的还是死的，是跟踪分配带宽的一种非常有效的方法。您可以按总字节数排序并从最大的 # 开始。查看所有分配点(单击所选行的类别中标签旁边的小箭头)，并查看所有分配来自何处。

例如，您的图表显示在该时间段内有 1.27MB 的 14 字节分配——9218 次分配。全部都已释放()d [好!]，但这仍然代表一堆工作要分配，填充数据(大概)，并释放其中的每一个。这可能是个问题，也可能不是。

(从正确的角度来看，我使用这种技术来优化应用程序。仅通过专注于减少 transient - 短暂 - 分配的数量，我能够使应用程序的主要算法速度提高 5 倍并且减少 85% 的内存使用。事实证明，该应用程序复制了很多很多次字符串。)

---

不确定为什么您的应用会像您描述的那样崩溃。既然是内存警告，你应该看看什么是最频繁分配的。

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