>在运行App for Profiling时选择Directly the Allocations
>当我运行应用程序进行性能分析时选择泄漏.
在这两种情况下,我都启用了Allocations工具进行测试.但令人惊讶的是,在这些情况下,我有两种不同类型的Out-for Allocations.
他们应该表现得不一样吗？或者这是仪器的问题.
我用Leaks工具描述的时间：
在分配图中：
1.我在图表中获得了很多峰值,实时字节和总字节数是相同的.
2.使用1分钟后,我得到黑旗(我认为它会报警内存警告).然后在出现一组标志后,我的应用程序崩溃了. (有时会发生这种情况,即使直接在设备中运行App)
我用分配工具描述的时间：
在分配图中：
我经常没有像上面那样得到峰值.实时字节总是小于总字节数.
我已经使用了20多分钟,从未得到过黑旗.
我开始知道的一个事实是,当Live字节和总字节数相等时,可以启用NSZombieEnabled.
有没有人遇到过这个问题.
更新1：
第一个案子我遇到了另一个问题.每当我在短时间内进行分析后(与第二种情况下的分析相比),该应用程序获得了大量黑旗并且我的应用程序崩溃了. (由于记忆警告)
当我尝试类似的一步一步使用Application我的应用程序没有崩溃并没有标记.
为什么会出现这种差异？
解决方法
两者都很有用,但原因略有不同.
仅跟踪实时分配(通常与快照分析结合使用)是分析应用程序中永久堆增长的好方法.一旦你知道永远存在的东西,你就可以找出原因,看看是否有办法优化它.
跟踪所有分配(活动和死亡)是跟踪分配带宽的非常有效的方法.您可以按总字节排序,并从最大的#开始.查看所有分配点(单击所选行的类别中标签旁边的小箭头),并查看所有分配的来源.
例如,您的图表显示在该段时间内有1.27MB的14字节分配 – 9218个分配.所有这些都是免费的()d [good！],但这仍然代表了一堆工作要分配,填充数据(大概),并释放其中的每一个.这可能是一个问题,也许不是.
(为了更好地理解这一点,我使用这种技术来优化应用程序.仅仅通过专注于减少瞬态 – 短期分配 –,我能够使应用程序的主要算法速度提高5倍并减少内存使用结果显示应用程序正在复制字符串很多次.)
不知道为什么你的应用程序如你所描述的那样崩溃了.由于它是内存警告,您应该看到最常分配的内容.
请记住,如果启用了僵尸检测,则会占用大量额外内存.
