【问题标题】:Understanding task_basic_info task resident_size了解 task_basic_info 任务 resident_size
【发布时间】:2013-09-09 15:32:35
【问题描述】:

简短的问题:有人(引用。5)告诉我,我的系统可以回收常驻内存。这是什么意思?这是否意味着我的应用程序没有使用该内存,或者常驻内存值与我的应用程序当前使用的内存直接相关?除了answers 之外,我还没有找到太多关于此的文档。

我正在尝试解决一个问题。我正在编写一个使用 iOS 6.0 和 Cocos2d 2.0 的游戏,但我确实遇到了一些内存问题。我有 Cococs2d 2.0 作为静态库,我使用 ARC 编写代码(我怀疑这是原因)。

从初始场景到角色选择场景,然后到行星选择场景,最后是游戏场景,我观察到内存的 resident_size 增加了。

我在每个场景初始化时添加了this 代码,并追踪了这些值。下图是我做的用户体验路径。左列是场景名称,第二列是正常流程中使用的内存量(不回到前一个场景),第三列是常驻内存的值,往复从特定场景。

我们可以观察到,主场景呈现出可能与其他场景不同的问题。每次加载场景时,我都会增加大约 15 MB 的内存。

我在场景上运行了一个独立的测试(使用重新加载回调方法),我得到了以下值:

有趣的是,在 CharacterSelection 场景上运行相同的测试在第三次加载后内存并没有逐渐增加(保持 37MB)。但是我不明白为什么最初从 27 MB 变为 32 MB 而不是 37MB(或者,我应该说,我不明白为什么它从 32 MB 变为 37 MB)。

我运行另一组测试试图从一个场景解析到另一个场景,我确实得到了有趣的结果。这是架构:

**有人 answered 对我说“常驻内存是对已分配给您的应用程序但尚未被系统回收的内存的度量,但部分/大部分常驻内存可以被系统回收。"

这是否意味着常驻内存值不一定是我的应用使用的内存?

根据我的测试,场景与其使用的内存和常驻内存值之间似乎确实存在相关性。

因此,如果这是正确的,我应该继续尝试解决这个问题,因为常驻内存值越高,我的 APP 被杀死的可能性就越大。相反,如果内存可供系统使用,则不会发生崩溃。鉴于有崩溃,我假设内存以某种方式泄漏。但是泄漏工具没有检测到任何泄漏(这是因为我使用的是 XCode 4.5 吗?)。

有什么帮助吗?这与使用 ARC 有关吗?

【问题讨论】:

  • 澄清一下,Instruments 是否还在说您的应用程序的“实时字节”与常驻内存相比非常小?泄漏仪器报告没有泄漏?如果是这样,我将尝试的下一件事是明确询问分配工具您的各种场景对象的活动实例的数量。 (我假设当你进入下一个场景时,应该释放前一个场景,并且有某种主场景类包含进入场景的所有内容。)我怀疑你正在泄漏场景和仪器只是没有报告这些泄漏。
  • @AaronGolden 感谢 Aaron,就是这样。好建议。我会尝试它,用评论更新,如果它有效,请接受答案(所以如果你愿意,你可以将它添加为编辑)。再次感谢您的支持:)

标签: ios xcode memory-management memory-leaks automatic-ref-counting


【解决方案1】:

问题是我在新场景的 init 方法期间测量内存。因此,该报告包括了前一个场景的资产(因为它尚未被解除分配)。

添加延迟为 0.1 的回调解决了它并回答了我的问题:

问:

有人(引文 5)告诉我,常驻记忆可以由我的 系统。这是什么意思?这是否意味着我的应用程序没有使用 该内存或者是与该内存直接相关的常驻内存值 我的应用当前正在使用的内存?

答:

它是与我的应用程序正在使用的内存直接相关的内存。在this function 的回调中使用延迟加上对[[CCTextureCache sharedTextureCache] dumpCachedTextureInfo]; 的调用将确认这一点。

问:

有什么帮助吗?这与使用ARC有关吗?

答: 幸运的是,在这种情况下不是。还有其他问题在某些场景中导致泄漏。例如,起始场景是另一个场景的子类。这个起始场景有一些子节点被添加为子节点,这些子节点在场景的清理方法中没有被删除。添加显式删除这些子节点解决了这个问题。我不确定为什么需要这样做(我希望所有子节点都会被自动删除),但它解决了这个问题。

【讨论】:

    猜你喜欢
    • 2013-11-17
    • 2021-08-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-10-05
    • 1970-01-01
    • 2018-04-08
    • 1970-01-01
    相关资源
    最近更新 更多