当我使用Instruments“配置”我的应用程序时发现了一些内存泄漏。有些泄漏很明显，很容易修复，但有些不是。在乐器中显示的一些泄漏日志真的困扰着我。例如： 
应用程序是否有可能需要零内存泄漏？
我甚至不知道我的代码的哪一行叫做这些场景后面的“陌生人”。我怎样才能解决这些泄漏？这是从我的代码泄漏吗？从框架？或者只是一个虚假的报告？
然后我的问题是：
答：是否有可能解决所有的内存泄漏的错误？其中一些真的很难处理。而且你甚至不能说它是来自你的代码还是来自框架的错误。
B：是否有必要修复所有内存泄漏？几个字节泄漏可能不会影响任何内容而你为解决这个问题所做的努力可能会比你得到的花费更多。
答：是否可以修复所有内存泄漏错误？其中一些真的很难处理。而且你甚至不能说它是来自代码 还是来自框架工作的错误。
是的，这是可能的，但请注意一些时候你从分析得到的结果不要你一定要泄漏，有时它们是还没有被自动释放的对象，有时它们不是你的。
B：是否有必要修复所有内存泄漏？几个字节泄漏可能对 没有影响。你付出的努力修复它可能会比你得到更多的花费 。
如果你的意思是你的应用程序不被拒绝，那么没有那不是必要的，不要过度劳累，并强调自己在一些字节，你似乎无法找到，不要去搜索了几个字节的已在这里和那里丢失，只有当你注意到你的应用程序真的在泄漏时才开始寻找泄漏。
是的，这是可能的，是的你应该。
从长远来看泄漏不好，特别是如果你的应用程序运行在后台。 如果泄漏位于第三方库中，请通知制造商修复它。或者如果你有代码修复你的自我。 泄漏你自己的代码可以很容易地修复，所以这样做。
如果您的应用程序运行很长时间（考虑作为某个服务器），那么它会频繁地频繁发出2个字节的泄漏。在某个时间点，你的堆将会充满无限的泄漏。这可能会导致应用程序中的malloc失败。所以修复内存泄漏对于长时间运行的应用程序来说更为重要。而且还有可能修复所有的内存泄漏。
如果应用程序在短时间内运行意味着一旦应用程序存在，所有资源将被操作系统释放，此时泄漏的内存也将被释放。
理想情况下，是的。但这些工具并不完美。通常会出现假阳性和假阴性......然后，偶尔会出现系统泄漏。我会说“永远尽你所能” –
没错，核心框架中的泄漏并不是真正可以解决的。但是在任何时候都应该避免泄漏自己的代码。 – rckoenes