内存管理 – 我应该使用哪些Instruments工具来了解我的Monotouch应用程序的内存使用情况？

概述我一直在阅读有关跟踪Instrument的内存使用情况的很多内容,但与Monotouch的结合很少. 这里似乎有三个选择权要求： >使用Instruments的Allocations实用程序. “活字节”的数量是应用程序使用的物理内存量. >使用Memory Monitor插件.从进程列表中,选择您的应用程序并选中“Real memory”列.这是当前使用的RAM量. >使用VM Tracker并 我一直在阅读有关跟踪Instrument的内存使用情况的很多内容,但与Monotouch的结合很少.

这里似乎有三个选择权要求：

>使用Instruments的Allocations实用程序. “活字节”的数量是应用程序使用的物理内存量.
>使用Memory Monitor插件.从进程列表中,选择您的应用程序并选中“Real memory”列.这是当前使用的RAM量.
>使用VM Tracker并制作自动快照.如果您追求的是“肮脏的大小”.

从我注意到的：

>一旦触发GC,“真实内存”就会下降
>即使我的“live Bytes”仍然保持在30MB左右,我最终也会收到内存警告
>通过不断的“live Bytes”,“Real Memory”可以显着增加并轻松增长到200MB或更多.
>在使用QLPrevIEwController并查看疯狂的大型Word文档(1000页)时,滚动浏览该文档会像疯了一样增长真实记忆.如果收到内存警告,则实际内存和实时字节都不会丢失.最终,应用程序将崩溃; Monotouch问题还是Apple的问题？
>有时,真正的记忆似乎在增长,没有什么可以阻止它.然后,GC似乎清除了它的大块.这没有真正的模式.

那么正确的答案是什么？有一个吗？

编辑：我附上两张图片.一个在我的应用程序生命中间阶段显示内存使用情况,以及稍后一秒显示内存使用情况.两个图像都反映了UI中同一点的内存使用情况,屏幕上只有两个控制器.也许有人仍然可以评论从这些数字中可以读取什么,特别是神奇的“Memory Tag 70”.

解决方法 仪器有点像黑盒子,但我认为这是：

There seem to be to three opposing claims here:
1. Use the *Allocation*s utility of Instruments. The number of “live bytes” is the amount of physical memory used by the application.

我不确切知道“live Bytes”是什么,但它不是应用程序使用的物理内存量.我认为这是所有ObjectiveC对象使用的物理内存量(如果这个理论是正确的“live Bytes”不包含托管代码使用的任何内存,也不包含ObjectiveC对象间接使用的任何内存(例如图像数据),似乎是真的).如果你想追踪泄漏的对象,“live Bytes”肯定是有用的,但它并不(必然)是一个关于实际使用多少内存的好指标.

2 . Use the Memory Monitor plugin. From the @R_502_6818@ of processes,pick your app and check the “Real memory” column. That’s the amount of RAM currently in use.

这有点接近：“Real Mem”是应用程序使用的物理内存量,不与其他应用程序共享.应用程序使用的物理内存总量是“虚拟内存”,但是大量的“虚拟内存”在应用程序之间共享(即共享库当然会在内存中加载时使用内存,但由于它是不可变的,它将会只会为所有进程加载一次.但是它会被添加到每个进程的“虚拟内存”中,因此如果你将所有进程使用的“虚拟内存”加起来,你将超出设备的实际物理内存.

3 . Use VM Tracker and make automatic snapshots. The “Dirty Size” if what you’re after.

正确. “Dirty Size”就是你所追求的 – 然而这与“Real Mem”密切相关,它只是将“Real Mem”分成几类,这样你就可以很容易地看到使用内存的是什么.

对于由于泄漏图像而使用大量内存的典型情况,过程如下：
 1.使用内存监视器验证您的应用确实存在内存问题.
 2.在VM Tracker /“Dirty Size”中看到图像数据使用了大量内存(这是神奇的“内存标签70”).
 3.使用Allocations找出CGImages的创建位置,查看相应的堆栈跟踪并找出未释放这些图像的原因.

每个应用程序都是不同的,因此不可能提出适用于所有情况的简短配方.

“Real Memory” drops as soon as GC is triggered Even if my “live Bytes” remain around 30MB I will eventually catch memory warnings With constant “live Bytes”,“Real Memory” can increase significantly and easily grow to 200MB or more.

所有这些都在上面解释.

While using QLPrevIEwController and vIEwing an insanly big Word document (1000 pages),scrolling through that document will grow real memory like crazy. If a memory warning is received,neither real memory,not live bytes drop at all. Eventually,the app will crash; Monotouch problem or Apple’s problem?

它也可能是你的问题:)如果不知道记忆的去向,就无法分辨.

Sometimes,real memory seems to grow and nothing can stop it. Then again,GC seems to clear big chunks of it. There is no real pattern in this.

你的意思是你正在观看真正的记忆增长而你的应用程序什么都不做？如果你真的在你的应用程序中做某事,这是完全正常的.

总结

以上是内存溢出为你收集整理的内存管理 – 我应该使用哪些Instruments工具来了解我的Monotouch应用程序的内存使用情况？全部内容，希望文章能够帮你解决内存管理 – 我应该使用哪些Instruments工具来了解我的Monotouch应用程序的内存使用情况？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。