使用工具来查找内存泄漏问题

Question

使用工具来查找内存泄漏问题

iosmemory-leaksautomatic-ref-countinginstruments

8

我已经尝试阅读了互联网上几乎所有好的教程，但仍然无法理解这里到底发生了什么：

我已经选择了“隐藏系统库”和“反转调用树”，但我不知道如何找到实际负责例如此泄漏的代码。任何提示都将不胜感激。也许我遗漏了一些显而易见的东西。我得到了数百个泄漏，但是在闭包中我使用了weak，我没有类相互引用等。但看起来我缺少了一些基本的东西。

- JuicyFruit

我也遇到了同样的问题。 - iTamilan

2个回答

3

您的截图显示的问题是Instruments找不到您应用程序的调试符号。Instruments显示的是内存地址而不是函数名称。如果没有函数名称，即使您反转调用树并隐藏系统库，也无法在Instruments中找到内存泄漏的源头。

请确保您的项目生成调试符号。检查Generate Debug Symbols构建设置是否设置为Yes。如果您的项目正在生成调试符号，则Instruments可能无法找到包含调试符号的dSYM文件。在Instruments中选择Instrument > Call Tree > Locate dSYM。dSYM通常与发布版本的应用程序包位于同一目录中。以下文章提供了额外的信息： Instruments: Locating dSYM Files

- Swift Dev Journal

好的，我已经做了一切，但在导入时遇到了“/appname/的UUID与libdyld.dylib的UUID不匹配”的问题，在谷歌上没有太多信息，有什么提示吗？ - JuicyFruit

我做到了！非常感谢！那就是我所缺少的。 - JuicyFruit

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- AnthonyMDev · Accepted Answer

内存泄漏可能很难追踪。这可能需要耗费很长时间，所以要有所准备。最终，调试内存泄漏通常需要大量尝试和错误。 "内存泄漏"工具过去实际上只为我检测到一个泄漏。我一直使用“分配”工具自己跟踪它们。

过去帮助过我的方法之一是从尝试弄清楚哪些对象实际上正在泄漏开始。点击分配工具（在“泄漏检查”上面的行）。现在尝试按释放的对象数量或使用的内存量进行排序。看看是否有任何对象的计数为0，并且它们应该被清除。查看是否有一种对象类型使用了异常数量的内存。

内存泄漏总是由于开发人员在内存管理方面犯了错误而导致的。 Foundation和UIKit中的某些低级私有API存在一些轻微的内存泄漏。在这些较低的级别上，它们处理更多的手动内存管理，因此很容易犯小错误。您无法真正对此做任何事情，但它们相对较少。

如果您的应用程序运行良好，则可能不需要担心修复这些问题。您要在这里进行一些成本效益分析。如果这不影响性能或稳定性，那么现在修复这些问题的时间投资是否值得提供给您和您的用户的微小好处？

但是值得注意的是，内存泄漏可能会累积，因此，如果用户打开您的应用程序很长时间，则随着时间的推移泄漏的内存量最终将成为问题，如果您继续泄漏更多对象，则应用程序将崩溃并且用户将不得不重新打开。但是，如果您的内存泄漏足够小，以至于除非应用程序已经打开了几个小时，否则这不会成为问题，那么这真的是一个大问题吗？这总是你自己的判断。