我正在使用设备上的仪器来尝试确定是否有内存泄漏或被遗弃。具体来说，我正在使用泄漏和分配。虽然仪器没有指出任何泄漏，但这并不意味着我没有内存问题。我已经为此工作了好几个星期，而且我似乎还无法弄清楚我遇到了什么问题(嗯)。
我正在通过在 Action 后进行重复并重复进行测试来测试特定的 Action 。经过前几代“定居”后，我可以看到增长和持久计数都是以一定数量(几个kb)开始的。经过多次重复的迭代(例如10-20)，一些(并非全部)缓慢地消耗到0。这需要一段时间，但确实会发生。那些拥有持久性内存的世代实际上并没有向我展示任何我认为有帮助的东西，因为堆栈跟踪显示了所有系统库。
所以我的问题是:
任何见解的答案将非常有帮助!
最佳答案
我会刺你的问题:
由于您不知道系统框架如何管理其私有(private)内存需求，因此您必须假设是的，只要您调用系统框架，就可能会发生延迟的/延迟的内存释放，在大多数应用程序中，“始终” ”。除了不能排除它之外，我可以肯定地说，肯定有长期的分配是由看似无害的系统框架使用触发的。 (有关示例，请参见this answer中关于UIWebView的长期内存使用的讨论。)
很难说。一个很好的一阶猜测可能是与迭代相关联的堆增长在某种程度上被延迟分配给先前迭代的内存的延迟/延迟释放完全抵消了。
如果Instruments显示堆增长，那么几乎可以肯定存在该堆增长。您是否可以直接控制堆的增长取决于情况。如果您不调用系统框架(不太可能)，那肯定是您的错。调用系统框架后，您必须接受框架可能分配在调用返回后仍保持分配状态的内存的可能性。
变灰的行表示Instruments没有该行的调试符号。就这样。它并不表示有关内存使用的任何特定信息。
如果每次迭代都创建了一个带有循环保留的新对象图，那么可以，您希望每次迭代都会导致堆增长至少达到该对象图的大小。也就是说，小对象图很容易在“噪声”中丢失。如果您有怀疑，一种方法是让“可疑”类的对象执行大量分配，这将使它们从“噪音”中脱颖而出。例如，为每个实例将对象malloc设置为一个兆字节(或更多)(并且显然，在释放实例后将其释放)。这可以帮助问题区域伸出来，使它们最初不存在。
关于ios - 仪器和堆增长，增长何时真正成为漏洞？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/26414711/