使用Instruments进行iOS开发的模糊性 [英] Ambiguities in using Instruments for iOS Development

问题描述

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

1. 通过在运行应用程序进行性能分析时直接选择分配


2. 当我运行应用程序进行性能分析时选择泄漏。

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

他们应该采取不同的行为吗？或者这是仪器的问题。

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

在分配图表中：

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

我使用分配工具进行配置文件的时间：

在分配图表中：

1.我做不像上面那样经常得到峰值。实时字节总是小于总字节数。
2.我已经使用超过20分钟并且从未得到过黑旗。

我发现的一个事实是，当Live字节和总字节数是相等，可以启用NSZombieEnabled。

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

更新1：

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

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

为什么会出现这种差异？

解决方案

在第一种情况下，您只跟踪实时分配，因为Leaks模板以这种方式配置Allocations仪器。在第二种情况下，您将跟踪实时和取消分配的分配。 （正如CocoaFu所说）。

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

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

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

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

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

---

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

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

I am Profiling an Application with Instruments. The profiling is done using Allocations Tool in two ways:

1. By choosing Directly the Allocations when I run the App for Profiling
2. By Choosing Leaks when I run the App for Profiling.

In both the cases , I had Allocations tool enabled for testing. But surprisingly , I had two different kind of Out put for Allocations at these instances.

Are they supposed to behave differently? or this is a problem with Instruments.

The time I Profile the with Leaks Tool:

In Allocations Graph: 1. I get lot of Peaks in Graph, The Live bytes and overall bytes are same. 2. I get the Black flags (I think it alarms about memory warning) after 1 minutes usage. Then after a set of flags appearing, my App Crashes. (This happens at times, even when directly run the App in Device)

The time I Profile the with Allocation Tool:

In Allocations Graph: 1. I do not get peaks often as it was in the above case. The Live bytes was always way less than Overall bytes. 2. I have used for over 20 minutes and never got Black flags.

One fact I came to know is that, when Live bytes and overall bytes are equal, the NSZombieEnabled could be enabled.

Have any of you ever encountered this problem.

UPDATE 1:

I faced another problem with first case. Whenever I profiled after a short duration (compared to profiling in second case), the app got lots of Black Flags and my App Crashed. (Due to Memory warning)

And when I tried the similar step by step use of Application my Application did not crash and got no flags.

Why this discrepancy?

解决方案

In the first case, you are only tracking live allocations because the "Leaks" template configures the Allocations instrument that way. In the second, you are tracking both live and deallocated allocations. (As CocoaFu said).

Both are useful, but for slightly different reasons.

Only tracking live allocations (in combination with Heapshot Analysis, typically), is a great way to analyze permanent heap growth in your application. Once you know what is sticking around forever, you can figure out why and see if there are ways to optimize it away.

Tracking all allocations, alive and dead, is a very effective means of tracking allocation bandwidth. You can sort by overall bytes and start with the largest #. Have a look at all the points of allocation (click the little arrow next to the label in the Category of the selected row), and see where all the allocations are coming from.

For example, your graph shows that there are 1.27MB of 14 byte allocations -- 9218 allocations -- over that period of time. All have been free()d [good!], but that still represents a bunch of work to allocate, fill with data (presumably), and free each one of those. It may be a problem, maybe not.

(To put this in perspective, I used this technique to optimize an application. By merely focusing on reducing the # of transient -- short lived -- allocations, I was able to make the primary algorithms of the application 5x faster and reduce memory use by 85%. Turns out the app was copying strings many, many, times.)

---

Not sure why your app crashed as you described. Since it is a memory warning, you should see what is most frequently allocated.

Keep in mind that if you have zombie detection enabled, that takes a lot of additional memory.

这篇关于使用Instruments进行iOS开发的模糊性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！