2013-02-07 49 views
5

分析应用程序时,我注意到每次执行某些操作(涉及UIViews)时,活动字节数增加约250 KB。XCode - 了解分配工具

查看对象列表中,主要(增长)的罪魁祸首只是读作“malloc 144字节”。

偶尔我用Allocations工具来发现我保存的对象比我想要的要长,但我不确定如何解释“malloc”对象。

任何指导将不胜感激。

+0

您是否正在使用核心数据? –

+0

不,但我加载256 UIImageViews并不断更新他们的图层。 – achiral

+0

我不确定,我的应用程序也有一些保留的malloc,但我也无法理解它们,我的总内存使用量保持在10兆以下,所以我没有真正追求任何东西,但id也对一个答案感兴趣。 –

回答

11

一对夫妇的想法:

  1. 分配工具是伟大的,但我会专注于Leaks,第一。你有没有干净的健康保险单?

  2. 你是否通过静态分析器运行你的代码(“产品”菜单上的“分析”)。特别是在非ARC代码中,可以识别许多问题。

  3. 您使用ARC吗?如果是这样,则缩小搜索范围。

  4. 你有僵尸打开吗?这将导致内存不被释放。确保关闭僵尸。

  5. 您确定您没有强大的参考周期(又名保留周期)吗?你可以在视图控制器的dealloc中放置NSLog或断点,并确保它已被调用,并确保没有强引用周期(两个或多个对象之间的循环引用不会被释放)。 (如果您没有dealloc方法,只需添加一个NSLog语句。)未能invalidate重复NSTimer是某些可能会无意中导致强参考周期的极好例子。关键问题是你必须确认dealloc正在发生。

  6. 您是否肯定弹出/解散视图控制器而不是推送/呈现其他视图控制器的另一个副本? (未能看到NSLogdealloc方法/断点可以通过这个引起的,除了在之前点讨论了有力的参考周期。)

  7. 在你的256(!)图像视图你在干什么imageNamed设置image属性? imageNamed方法缓存图像不会释放内存,直到您收到内存警告(尽管它只会检索新图像时消耗内存,不会重新检索现有图像)。

底线,可能有很多可能的问题,并且您的问题中没有足够的帮助我们诊断问题。你必须帮助我们缩小问题的范围。

但是看看你的控制器,并确保他们正在被释放,就像他们应该。我感觉你对144字节的问题很痛苦,但这不可能是每次消费250kb的罪魁祸首。 malloc更可能是一个问题的症状,而不是问题的根源,我会专注于上面列出的更基本的东西,然后花费太多时间来追踪调用的来源。