0

我最近将一个项目移植到 ARC，因为我遇到了崩溃问题并实际确定了原因，无论是泄漏还是保留周期等，现在我已经将它移植过来，我还没有进行大规模测试以查看它是否仍然崩溃因为我没有设法通过活动监视器，当它显示我的应用程序正在执行此操作时，它给了我 heeby jeebies（活动监视器分析器）

活动监视器

而在分配工具中，它看起来像

分配

实际内存使用量甚至不是最糟糕的，它一度飙升至大约 90 多 MB，我不确定如何进行，因为我不是 100% 确定如何处理此处提供的信息，除非假设我可能是东东，非常错误，而且我也运行了泄漏工具，我有一些，但它们很小，它们都是字节。

有人有解释吗？或者至少能够澄清我可能在看什么？real memory usage和 和live bytes和有什么不一样overall bytes？这些结果也得到了一次完全相同的动作，然后在结束时显示给你。

我一直在尝试减少实际内存使用量，因为 ARC 转换前我经常遇到内存警告和静默崩溃，转​​换后我没有再次遇到这些，但我没有进行任何长时间的测试，因为我什至无法想象何时尝试真正的内存使用情况是这样的。这实际上看起来比 ARC 之前要高很多……尽管在 ARC 之后实时字节看起来确实更低……疯狂！

4

1 回答 1

1

让我困惑一段时间的事情是 ARC——尽管它很精彩——并不一定避免对@autoreleasepool.

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html

我在应用程序中运行了非常大的内存使用，直到有人建议：

@autoreleasepool {

    // lots of allocating of objects returned from methods then discarded

} // and the closing brace of the autoreleasepool block causes their memory to be recovered here

也许这会对你有所帮助。

Instruments ObjectAlloc: Explanation of Live Bytes & Total Bytes中对分析器中各个列的含义进行了很好的解释

于 2012-12-11T09:15:57.753 回答