iOS 中的潜在内存泄漏答案

【问题标题】：Potential Memory Leak in iOSiOS 中的潜在内存泄漏
【发布时间】：2013-12-26 01:43:59
【问题描述】：

所以我刚刚制作了一个应用程序，它可以加载带有一些标记的地图。该应用程序有一个导航控制器，可以从主屏幕切换到地图并返回。在我的手机和模拟器上运行应用程序时，我注意到如果我在主屏幕和地图之间来回切换，应用程序使用的内存量只会无限增长。有没有办法协助内存管理过程（我知道系统使用 ARC）？顺便说一句，我正在使用谷歌地图 sdk。

谢谢！

【问题讨论】：

参见 WWDC 2013 视频 Fixing Memory Issues 或 WWDC 2012 视频 iOS App Performance: Memory。它们描述了内存问题的类别并说明了如何使用 Instruments 来识别它们。在回答您的问题时，可能是强大的参考周期阻止了东西被释放、其他一些泄漏、废弃的内存或设计不当的缓存。根据您迄今为止分享的内容，无法判断。
您是否使用转场返回主屏幕？如果是这样，那是你的问题。
我只是在展开转场（通过 UINavBar 上的后退按钮）

标签： ios objective-c google-maps memory-leaks

【解决方案1】：

是否会导致应用内存不足并崩溃？

或者它是在使用大量内存，收到内存警告，然后转储所述内存？

因此，除非它导致崩溃，否则它可能会正常运行。

【讨论】：

它的行为可能正确，但不太可能，当然也不应该让人相信。应用随机消耗内存直到用完是不负责任的；如果不出意外，您可能会不必要地抛弃其他应用程序。值得称赞的是，CoderNinja 正试图了解应用程序为何会消耗内存。恕我直言，唯一属于“不要出汗”类别的问题是某些标准 UIKit 控件可能导致的（字面上）几百字节的 de mimimis 泄漏。但是任何规模大的东西都应该在 Instruments 中进行分析和追踪。
@Rob 我非常同意，这就是为什么我特别提到了 is it crashing 案例。我不同意的是，应用程序缓存到收到内存警告，清除所述缓存，然后继续前进是不好的行为。这完全符合系统的设计参数和目标之一。当然，对于活动的后台应用程序来说这样做是不利的，但是当前的应用程序可以随意消耗尽可能多的资源，以便为用户提供最佳体验。话虽如此，优化绝对至关重要，了解正在发生的事情也是如此！
我们只是同意不同意“在收到警告之前使用内存”设计方法的优点。这些 WWDC 视频讨论了未能缓解高水位标记如何导致 (a) 如果后台应用程序经常被驱逐，多任务用户体验会减少； (b) 更大的堆碎片； (c) 从技术上讲，您不能保证收到内存警告。无论如何，我们似乎在更广泛的观点上达成了一致：我只是担心你的回答可能被解释为“嘿，如果它没有崩溃，那就别担心”，但听起来你不是这样的试图说。

【解决方案2】：

Apple 为诊断此类问题提供广泛且有据可查的支持。见"Locating Memory Issues in Your App"。

【讨论】：

【解决方案3】：

检查使用 NSThreads 和 GCD 块的代码。如果有些地方创建了很多线程，建议添加一个 autoreleasepool 块。

在这些情况下内存可能会泄漏：

如果您正在编写不基于 UI 框架的程序，例如命令行工具。
如果您编写的循环会创建许多临时对象。
如果您生成辅助线程。

供参考：Using Autorelease Pool Blocks

【讨论】：

是的，如果您手动创建自己的线程，那么，肯定需要创建自动释放池，否则@autoreleasepool 不太可能在解决 OP 所描述的内存问题方面富有成效。池不会更改已释放和未释放的内容，而只是对这些释放的时间提供一点控制。
我不（认为）我正在创建任何线程？至少不明确