我正在使用taskInfo
来获取我的应用程序以编程方式使用的内存量。其代码基本上是
kern_return_t result = task_info(mach_task_self(), TASK_BASIC_INFO, (task_info_t)&info, &num); if (result == KERN_SUCCESS ) { memoryUsed = (double)(info.resident_size/1000000.0);
当我在Debug
配置上运行我的应用程序时,与我在Distribution
上运行时相比,它报告的内存要多得多(差异大约100MB)。由于有一些其他第三方库被链接,我不确定他们是否正在做一些奇怪的事情。
我的问题是假设我的应用程序没有做任何奇怪的事情是否有这么大的差异是正常的?
P.S。 :我也在使用cocos2d
,但我觉得这很安全。
答案 0 :(得分:1)
我会说这是预期的行为。至少在我比较DEBUG和RELEASE版本之间的内存使用情况的所有项目中都是如此。
显然,在DEBUG构建中,有很多原因正在完成并且可能保留在内存中。调试主要是你自己和框架(即cocos2d)。各种断言和日志也会增加更多(临时)内存使用量。连接的调试器和调试服务也可能消耗归因于该应用程序的额外内存。
没有什么可担心的。仅在发布版本中测量您的内存使用情况,因为这最终会在用户上运行。设备
答案 1 :(得分:0)
ARC对编译器的优化设置很敏感。
应用程序的默认调试配置会关闭优化(-O0
)。这导致ARC在它插入的retain
和autorelease
中变得迂腐(冗余?),这反过来又会增加对象的生命周期,超出人们通常预期的范围。
另一方面,默认版本配置已启用优化(-Os
)。这会导致一些retain
/ release
对被优化掉(我认为它也会减少对autorelease
的使用频率?)最终会dealloc
更早出现{{1}}对象意味着你会少数人闲逛。
试试这个:转到您的构建设置,然后更改"优化级别" "代码生成"下的调试配置部分。看看之后是否还有更多内存被使用。
答案 2 :(得分:0)
在玩了很长时间之后,我发现cocos2d或任何其他框架都没有任何问题。
相反,有一段毛茸茸的代码正在做类似
的代码dispatch_async(dispatch_get_global_queue(DEFAULT, 0), ^{
for(int i = 0; i < 100000; i++) { // a big loop
[a.b doSomethingAtIndex:i];
}
});
对象a
已实现为代理对象,并使用forwardInvocation:
来解析消息调用a.b
,因此这些调用正在分配但从未被删除,因为它没有被包围任何@autorelease pool
。