Jim*_*Jim 11 cocoa-touch memory-management instruments ios
我正在尝试使用仪器来处理一些低内存条件.我可以看到物理内存空闲监视器中的内存消耗下降到几MB,即使分配显示所有分配大约为3 MB且总字节数为34 MB.
我已经开始遇到崩溃,因为我将一些操作移动到一个带有NSOperationQueue的单独线程.但是在改变之前我并没有使用乐器.尽管如此,我打赌我做了一些我可以撤消以阻止崩溃的事情.
顺便说一句,没有仪器或连接调试器,它会更加稳定.
我的泄漏几乎没有(在崩溃之前最多可能是一百字节).
当我看Allocations时,我只看到非常原始的对象.并且它报告的总内存也非常低.所以我无法看到我的应用程序如何导致这些低内存警告.
当我从启动时看Heap Shots时,我看不到大约3 MB,在基线和所有堆增长值的总和之间.
我应该怎么看才能找到问题所在？例如,我可以将它隔离到我的一个视图控制器实例吗？或者我的其他一个例子？
我做了什么: 我关闭了设备并重新启动,这带来了显着的改进.仪器未报告低内存警告.另外,我注意到启动时的物理空闲内存在重新启动之前只有大约7 MB,重启后大约为60 MB.
但是,我看到物理可用内存非常规则(周期性)下降,从43 MB下降到6 MB(然后再回升到43 MB).我想知道它造成什么.我没有在这个应用程序中运行任何计时器.(我确实有一些performSelector:afterDelay :,但是在这些测试中它们没有活动.)
我没有使用ARC.
Jor*_*rge 19
在分配和泄漏仪表只显示哪些对象采取实际的,但他们的垫层非对象结构(的后备存储)正在不算什么.例如,对于UIImages,它将显示您有一些分配的字节.这是因为UIImage对象只接受那些字节,但CGImageRef实际包含图像数据的对象不是对象,并且在这些工具中不考虑它.
如果您尚未执行此操作,请在运行分配工具的同时尝试运行VM Tracker.它将让您了解正在分配的类型内存.对于iOS ,本仪器显示的" Dirty Memory "通常会触发内存警告.脏内存是VM系统无法自动丢弃的内存.如果您看到很多CGImages,图像可能就是您的问题.
另一个重要概念是废弃的记忆.这是已分配的内存,它仍在某处引用(并且因此不是泄漏),但未使用.这种类型的内存的一个例子是某种类型的缓存,它不会在内存警告时释放.找到这个的一种方法是使用堆镜头分析.按分配工具的"标记堆"按钮,执行某些操作,返回应用程序中的上一个点并再次按"标记堆".第二堆镜头应该会告诉你在这两个时刻之间分配了哪些新对象,并且可能会揭开神秘面纱.您还可以重复模拟内存警告的操作,以查看该行为是否更改.
最后,我建议你阅读这篇文章,它解释了这一切是如何工作的:http://liam.flookes.com/wp/2012/05/03/finding-ios-memory/.
VM Tracker的物理内存与"Allocations"分配的内存之间的差异是由于这些工具的工作方式存在很大差异:
分配 跟踪您的应用程序确实通过在分配内存(功能安装水龙头什么malloc,NSAllocateObject...).此方法可生成有关每个分配的非常精确的信息,例如代码(堆栈)中的位置,数量,时间,类型.缺点是如果你没有跟踪以某种方式分配内存的每个函数(如vm_allocate),你就会丢失这些信息.
VM Tracker 定期对系统虚拟内存的状态进行采样.这是一种不太精确的方法,因为它只是为您提供当前状态的整体视图.它以低频率运行(通常每三秒钟一次),你不知道这种状态是如何达到的.
一个已知的隐形分配的罪魁祸首是CoreGraphics:它在解压缩图像,绘制位图上下文等时使用大量内存.在Allocations工具中,这种记忆通常是不可见的.因此,如果您的应用处理大量图像,您可能会发现物理内存量与总分配大小之间存在很大差异.
物理内存中的峰值可能是由于大图像被解压缩,缩小尺寸,然后仅用于某些视图或图层内容的屏幕分辨率.所有这些都可能在UIKit没有代码涉及的情况下自动发生.
当我读你的文字时，我的印象是你可能有一些隐藏的漏洞。我可能是错的，但是，你百分百确定你已经检查了所有泄漏吗？
我记得几个月前我在做一个特定的项目，我遇到了同样的问题，并且仪器中没有泄漏。我的记忆力不断增长，并且收到内存警告...我开始登录一些重要的 dealloc 方法。我已经看到一些对象、子视图（UIView）正在“泄漏”。但 Instruments 没有看到它们，因为它们仍然附加在主视图上。
希望这有帮助。