我如何追踪记忆峰值？ （这是ap的峰值，而不是l）
我有一个自助服务terminal应用程序，基本上显示了一大堆幻灯片，上面有各种各样的信息。 我最初是从一年前开始编写这个代码的，当时我开始使用Objective-C和iOS开发。 我发现我的代码风格比现在更清晰，而且我更有经验，所以我决定从头开始重写。
我使用Allocations工具运行我的应用程序，以查看内存使用情况。 考虑到这是一个信息亭应用程序，一切都需要平稳运行，没有泄漏。 （当然，所有的应用程序都需要运行，没有泄漏，但是一个自助服务terminal应用程序使得这个更重要的目标。）我看到了一些有趣的结果，所以我运行了旧版本的代码。
运行旧版本的代码，我发现内存使用量大约为1.15 MB。 似乎所有东西都可以根据需要分配和释放。 然而，在我的新实现中，我看到了一些不同的东西。 内存使用量一直在“高原”中跳跃，最终似乎达到了1.47兆字节的使用率。 以下是运行超过10小时后的新分配报告的外观：
我担心几个原因。
- 在运行开始的奇怪模式。
- 分配似乎达到了1.47兆字节的高峰，但在一夜之间运行表明，随着时间的推移，它实际上会慢慢地使用越来越多的内存。 这不是一件好事。
旧项目和新项目之间有几个显着的差异。
-
较旧的使用Plist作为后备存储（我手动读取和写入plist文件）。新项目使用核心数据。
-
新项目实现了旧项目没有的每个“幻灯片”上调用的库。 我会更关心这个图书馆，除了我写的，我经历了它，以确保我释放的一切，只有自动释放，无论手动释放是不可能的。
-
这两个类都使用工厂类来创build幻灯片。 在旧项目中，工厂class是一个单身人士。 我认为把它变成一个普通的class级将有助于解决记忆问题，因为单身人士从未被释放。 （因此它的属性没有被释放。在新的项目中，工厂类正在被释放，所以我不知道为什么它仍然占用了所有的内存（如果这是什么原因造成的问题。
-
旧项目在各个地方使用string常量。 新的代码使用一个巨大的枚举相同的事情。 （新的代码通常使用更多的常量。）
我能做些什么来追踪记忆峰值？ 内存全部被应用程序清除，当它丢弃它所使用的任何内容时，但在应用程序终止之前似乎没有放弃任何东西。
如果有人能帮助我指出正确的方向，我将不胜感激。
编辑：
看起来高峰是由对KosherCocoa图书馆的调用造成的。 如果有人会介意看看它，并告诉我我在做什么错，只要内存pipe理，我真的很感激它。
我能做些什么来追踪记忆峰值？ 内存全部被应用程序清除，当它丢弃它使用的任何东西时，但是它似乎并没有被丢弃。
这是“遗弃物品”或“使用增长”的经典案例。 也就是说，你有一个应用程序，在运行时，在内存中build立一个对象图，作为正常使用的一部分。 对象不会泄漏，因为它们仍然连接到活动对象graphics。 更可能的是，这些对象是某种caching（最常用的只写caching）或涉及历史状态的机制（撤消堆栈是增长的潜在源）的一部分。
为了解决这个问题，你需要确保你的对象图在你的应用程序运行时被适当修剪。 caching通常应该使用最近最less使用的[LRU]修剪algorithm来限制caching大小。 如果caching键无效，那么该数据也应该被修剪。
对于历史信息，修剪历史是至关重要的。 因此，确保历史数据包含该历史状态的绝对最小表示。
使用Heapshot分析 – 创build它是为了帮助追踪这些types的问题。
我写了详细的“如何”指南; 什么时候泄漏不是泄漏？