memory-management - 我应该使用哪些 Instruments 工具来了解我的 Monotouch 应用程序的内存使用情况?

标签 memory-management xamarin.ios instruments

我已经阅读了很多关于在 Instrument 中跟踪内存使用情况的文章,但几乎没有与 Monotouch 结合使用。

这里似乎有三个相反的主张:

  • 使用 Instruments 的 Allocations 实用程序。 “事件字节数”是应用程序使用的物理内存量。
  • 使用内存监视器插件。从进程列表中,选择您的应用程序并检查“真实内存”列。这是当前使用的 RAM 量。
  • 使用 VM Tracker 并制作自动快照。如果您想要的是“脏尺寸”。

  • 从我注意到的:
  • “真实内存”在 GC 触发后立即下降
  • 即使我的“Live Bytes”保持在 30MB 左右,我最终还是会收到内存警告
  • 使用恒定的“Live Bytes”,“Real Memory”可以显着增加并且很容易增长到 200MB 或更多。
  • 在使用 QLPreviewController 并查看一个非常大的 Word 文档(1000 页)时,滚动该文档会疯狂地增加实际内存。如果收到内存警告,则实际内存和事件字节都不会下降。最终,应用程序将崩溃;单点触控问题还是苹果的问题?
  • 有时,真实的内存似乎在增长,没有什么可以阻止它。再说一次,GC 似乎清除了其中的大部分内容。这没有真正的模式。

  • 那么正确答案是什么?真的有吗?

    编辑 : 附两张图。一个显示我的应用程序生命周期中间阶段的内存使用情况,以及稍后的几秒钟。两个图像都反射(reflect)了 UI 中同一点的内存使用情况,屏幕上只有两个 Controller 。也许有人仍然可以评论可以从这些数字中读取的内容,尤其是神奇的“内存标签 70”。

    enter image description here
    enter image description here

    最佳答案

    仪器有点像一个黑匣子,但我认为它是这样的:

    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 list 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"中看到图像数据使用了大量内存(这就是神奇的 "Memory Tag 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.


    你的意思是当你的应用程序什么都不做的时候,你正在观察实际内存的增长?如果你真的在你的应用程序中做一些事情,这是完全正常的。

    关于memory-management - 我应该使用哪些 Instruments 工具来了解我的 Monotouch 应用程序的内存使用情况?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10402845/

    相关文章:

    linux - 防止备份读取进入 linux 页面缓存

    audio - 使用MonoTouch进行多声道声音播放

    c# - Xamarin Async ViewDidAppear 在 ViewDidLoad 期间调用

    ios - 无法在 Xamarin 中使用 SecKeyChain 将证书存储到 KeyChain

    ios - XCode 4.5 中 ARC 的 Phantom 内存泄漏,其中肯定调用了 dealloc 或 Instruments 问题?

    iphone - 在 iPhone 上优化 OpenGL ES 并解释 Instruments

    swift - 为什么对象只有从 NSObject 继承时才会变成 NSZombie?

    使用FOR lOOP时java堆内存使用异常

    objective-c - 寻找内存泄漏时仪器中的颜色

    c++ - 小对象分配器