使用仪器通过低内存警告 [英] Using Instruments to Work Through Low Memory Warnings

查看:160
本文介绍了使用仪器通过低内存警告的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我尝试使用仪器通过一些低记忆条件。我可以看到物理内存释放监视器的内存消耗下降到几个MB,即使分配显示所有分配约3 MB和总字节为34 MB。



我已经开始经历崩溃,因为我把一些操作移动到一个单独的线程与NSOperationQueue。但我在改变之前没有使用仪器。然而,我敢打赌,我做了一些事情,我可以撤销来停止崩溃。



顺便说一下,没有仪器或调试器连接更稳定。 / p>

我有泄漏几乎没有(在崩溃前最多可能有100个字节)。



看看Allocations,我只看到非常原始的对象。它报告的总内存也很低。因此,我无法看到我的应用程序是如何导致这些低内存警告。



当我从启动时看到Heap Shots,我看不到超过约3 MB在基线和所有堆增长值的总和之间。



我应该怎么查找问题在哪里?我可以将它隔离到我的一个视图控制器实例,例如?还是我的其他一个实例?



我做了什么:
我已关闭设备电源,这是一个重大的改进。仪器不报告低内存警告。此外,我注意到启动时的物理可用内存在重新启动之前只有大约7 MB,重新启动后大约60 MB。



但是,我看到一个非常规则(周期性)丢弃,从43 MB下降到6 MB(一个,然后回到43 MB)。我想knwo什么造成的。我没有任何计时器运行在这个程序。 (我有一些performSelector:afterDelay :,但是这些测试期间没有活动。)



我没有使用ARC。

解决方案

分配实际上采取,但不是它们的底层非对象结构(后备存储)正在采取。例如,对于UIImages它将显示您有几个分配的字节。这是因为 UIImage 对象只接受那些字节,但实际包含图像数据的 CGImageRef



如果您不是这样做,请尝试以同样的方式运行 VM Tracker 您运行分配工具的时间。它将给你一个想要分配的类型内存。对于iOS,由此仪器显示的<脏内存通常会触发内存警告。 脏内存是VM系统无法自动舍弃的内存。如果您看到许多CGImages,图片可能就是您的问题。



另一个重要的概念是放弃的内存。这是被分配的内存,它仍然被引用某处(因此不是泄漏),但未使用。这种类型的存储器的示例是某种类型的高速缓存,其在内存警告时不释放。找到这一点的一种方法是使用堆Shot分析。按分配工具的标记堆按钮,进行一些操作,返回到应用程序中的上一点,然后再次按标记堆。第二个堆镜头应该显示在这两个时刻之间分配了什么新对象,并且可能会揭开这个谜团的一些光。你也可以重复模拟内存警告的操作,看看这种行为是否改变。



最后,我建议你阅读这篇文章, a href =http://liam.flookes.com/wp/2012/05/03/finding-ios-memory/> http://liam.flookes.com/wp/2012/05/03/finding- ios-memory / 。


I am trying to work through some low memory conditions using instruments. I can watch memory consumption in the Physical Memory Free monitor drop down to a couple of MB, even though Allocations shows that All Allocations is about 3 MB and Overall Bytes is 34 MB.

I have started to experience crashing since I moved some operations to a separate thread with an NSOperationQueue. But I wasn't using instruments before the change. Nevertheless, I'm betting I did something that I can undo to stop the crashes.

By the way, it is much more stable without instruments or the debugger connected.

I have the leaks down to almost none (maybe a hundred bytes max before a crash).

When I look at Allocations, I only see very primitive objects. And the total memory reported by it is also very low. So I cant see how my app is causing these low memory warnings.

When I look at Heap Shots from the start up, I don't see more than about 3 MB there, between the baseline and the sum of all the heap growth values.

What should I be looking at to find where the problem is? Can I isolate it to one of my view controller instances, for example? Or to one of my other instances?

What I have done: I powered the device off and back on, and this made a significant improvement. Instruments is not reporting a low memory warning. Also, I noticed that Physical Free Memory at start up was only about 7 MB before restarting, and its about 60 MB after restarting.

However, I am seeing a very regular (periodic) drop in Physical Free Memory, dropping from 43 MB to 6 MB (an then back up to 43 MB). I would like to knwo what it causing that. I don't have any timers running in this app. (I do have some performSelector:afterDelay:, but those aren't active during these tests.)

I am not using ARC.

解决方案

The allocations and the leaks instruments only show what the objects actually take, but not what their underlaying non-object structures (the backing stores) are taking. For example, for UIImages it will show you have a few allocated bytes. This is because a UIImage object only takes those bytes, but the CGImageRef that actually contains the image data is not an object, and it is not taken into account in these instruments.

If you are not doing it already, try running the VM Tracker at the same time you run the allocations instrument. It will give you an idea of the type memory that is being allocated. For iOS the "Dirty Memory", shown by this instrument, is what normally triggers the memory warnings. Dirty memory is memory that cannot be automatically discarded by the VM system. If you see lots of CGImages, images might be your problem.

Another important concept is abandoned memory. This is memory that was allocated, it is still referenced somewhere (and as such not a leak), but not used. An example of this type of memory is a cache of some sort, which is not freeing up upon memory warning. A way to find this out is to use the heap shot analysis. Press the "Mark Heap" button of the allocations instrument, do some operation, return to the previous point in the app and press "Mark Heap" again. The second heap shot should show you what new objects have been allocated between those two moments, and might shed some light on the mystery. You could also repeat the operation simulating a memory warning to see if that behaviour changes.

Finally, I recommend you to read this article, which explains how all this works: http://liam.flookes.com/wp/2012/05/03/finding-ios-memory/.

这篇关于使用仪器通过低内存警告的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆