3

我们正在为 iPhone 制作游戏。我们已经完成了开发并尝试优化游戏的内存。我们注意到，当我们在游戏中加载特定的 MVC 并关闭它时，并非所有分配的内存都被释放。（增加了约 4-5MB）。如果您继续玩 15-20 分钟，这会导致游戏的内存使用率非常高，并且游戏最终会在发出低内存警告后崩溃。

这就是我绑定
的 1. 在游戏上运行静态分析器并修复所有内存泄漏和警告。
2. 手动检查所有类的dealloc是否被调用。这似乎很好。
3. 还尝试在 Xcode 中运行 Allocations 工具，但其中的大多数条目是 CFStrings、mallocs 和 CFNumbers 等，但并没有真正说明它们来自我的哪个类。有没有更好的方法来使用分配工具？

我还有一些与内存相关的问题
1. 我们在游戏中的许多地方都使用了自动释放对象，而没有使用自动释放池。我的理解是自动释放的对象应该在下一个运行循环中释放并且不应该造成这么大的问题？
2. 另外，如果我通过 xib 文件加载图像，它们是否会被 iOS 缓存。他们也会占用内存吗？

我该如何解决我的内存使用问题。任何帮助，将不胜感激。谢谢！

4

3 回答 3

4

几个想法：

  1. 你在使用核心基础课程吗？确保对于您使用Create或Copy以您调用的名称CFRelease（或转移所有权，然后release或autoreleaseObjective-C 对象）调用 Core Foundation 的每个对象。

  2. 您是否也使用过 Instruments 中的 Leaks 工具？我想是的，但你没有提到它。请参阅Instruments 用户指南中的在您的应用程序中查找泄漏。

  3. 你是通过加载图像imageNamed吗？这会缓存图像并且不利于释放它们。手动使用imageWithContentsOfFile和管理缓存更安全。

  4. 我假设您的视图控制器dealloc正在被调用，并且您正在释放与类属性/ivars 关联的所有对象？

  5. 你有没有打开僵尸？这对于诊断目的非常有用，但在关闭僵尸之前您不会释放内存。

于 2013-01-21T20:30:00.127 回答
2

如果您“正在”制作某些东西，则应该使用ARC（自动引用计数）。一旦您全部转换为 ARC，您将不再需要那些自动释放对象，编译器将在适当的时间释放对象。如果您发现对象池仍在失控的情况下，您可以使用@autoreleasepool声明式创建自己的自动释放池。

我认为切换到 ARC 将帮助您，并使您的进一步开发变得更加简单。转换为 ARC 后，在 Instruments 中再次分析您的应用程序，并缩小创建大型对象池的任何违规代码。

如果您选择不转换为 ARC，根据您的解释，听起来您可以使用您所指的视图进行保留周期。通过追踪它保留的每个地方，确保该视图实际上正在被释放。

于 2013-01-21T20:28:33.967 回答
2

Rob 和 Chris 所说的，然后执行此操作：

使用配置为仅跟踪活动分配和记录引用计数的分配工具。

在 Allocations 收集数据时使用您的应用程序，然后暂停您的应用程序。

暂停时，按 Live Bytes 和# Living 排序是您最有用的视图。对于利用 Foundation 集合类的以数据为中心的应用程序，*String、*Dictionary 和 *Array 的某种组合可能是最常见的。

那没问题。如果单击查看其中任何一个的详细信息，您将获得当前内存中所有实例的长列表。你可以po <addr>看看他们中的任何一个是什么。您还可以滚动查看列表以查看哪些函数最常负责分配。同样，您可以单击任何实例以查看它的分配位置和/或它可能仍然存在的原因。

同样，您可以从概览表开始，按#Living 排序，然后向下滚动到某个类的第一个实例。如果该类植根 - 持有 - 大量数据，那么消除或优化这是一个很好的开始。

当然，不要忘记heapshot 分析是一种非常有效的内存增长世代分析工具。

于 2013-01-21T22:25:18.883 回答