我一直在阅读很多关于追踪乐器内存使用情况的内容,但与Monotouch结合使用的情况很少。
这里似乎有三个选择权声明:
从我注意到的事情:
那么正确答案是什么?只有一个吗?
编辑:我附上了两张图片。一个在我的应用程序生命中间阶段显示内存使用情况,以及稍后一秒显示内存使用情况。两个图像都反映了UI中同一点的内存使用情况,屏幕上只有两个控制器。也许有人仍然可以评论从这些数字中可以读到什么,特别是神奇的“Memory Tag 70”。
答案 0 :(得分:3)
仪器有点像黑盒子,但我认为这是:
这里似乎有三个相反的主张:
1.使用Instruments的* Allocation * s实用程序。 “活字节”的数量是应用程序使用的物理内存量。
我不确切知道“Live Bytes”是什么,但它不是应用程序使用的物理内存量。我认为它是所有ObjectiveC对象使用的物理内存量(如果这个理论是正确的“Live Bytes”不包含托管代码使用的任何内存,也不包含ObjectiveC对象间接使用的任何内存(如图像数据),这似乎是真的)。如果你想追踪泄漏的物体,“Live Bytes”肯定是有用的,但它并不(必然)是一个关于实际使用多少内存的好指标。
2。使用Memory Monitor插件。从进程列表中,选择您的应用程序并选中“Real memory”列。这是当前使用的RAM量。
这有点接近:“Real Mem”是应用程序使用的物理内存量,不与其他应用程序共享。应用程序使用的物理内存总量是“虚拟内存”,但是大量的“虚拟内存”在应用程序之间共享(即共享库当然会在内存中加载时使用内存,但由于它是不可变的,它将会只会为所有进程加载一次。但是它会被添加到每个进程的“虚拟内存”中,因此如果你将所有进程使用的“虚拟内存”加起来,你将超出你设备的实际物理内存。 / p>
3。使用VM Tracker并生成自动快照。如果您追求的是“脏大小”。
正确。 “Dirty Size”就是你所追求的 - 然而这与“Real Mem”密切相关,只是将“Real Mem”分成几类,这样你就可以很容易地看到使用内存的是什么。
对于因图像泄漏而使用大量内存的典型情况,过程如下:
1.使用内存监视器验证您的应用确实存在内存问题
2.在VM Tracker /“Dirty Size”中看到图像数据使用了大量内存(这就是神奇的“Memory Tag 70”)。
3.使用Allocations找出CGImages的创建位置,查看相应的堆栈跟踪并找出未释放这些图像的原因。
每个应用程序都有所不同,因此不可能提出适用于所有情况的简短配方。
- “实时内存”会在GC触发后立即下降
- 即使我的“Live Bytes”仍然保持在30MB左右,我最终会收到内存警告
- 通过不断的“Live Bytes”,“Real Memory”可以显着增加并轻松增长到200MB或更多。
以上解释了所有这些。
- 在使用QLPreviewController并查看疯狂的大型Word文档(1000页)时,滚动浏览该文档会像疯了一样增长真实记忆。如果收到内存警告,则实际内存和实时字节都不会丢失。最终,应用程序将崩溃; Monotouch问题还是Apple的问题?
这也可能是你的问题:)如果不知道记忆的去向,就不可能分辨出来。
- 有时,真正的记忆似乎在增长,没有什么可以阻止它。然后,GC似乎清除了它的大块。这里没有真正的模式。
你的意思是你正在观看真正的记忆增长而你的应用程序什么都不做?如果您在应用程序中实际执行某些操作,这是完全正常的。