我是 Objective-C 的新手（来自 Java），我认为我对内存管理有了很好的理解。但是当我的应用程序加载时，我得到一个非常小的内存泄漏，这只发生在游戏加载时（我们谈论的是 32 到大约 512 个字节）。
泄漏的时候是随机的，而且似乎不是用户触发了泄漏。通常它在大约 20 秒到 1 分钟后被检测到。
我从调试器获得的信息永远不会相同。有时它是“负责框架”的 UIApplication，有时是 [UIWindow makeKeyAndVisible]，有时是 [UNIbDecoder]。
这是低于“可接受”的限制，还是应用程序根本不应该泄漏？这是我的第一个“大”应用程序。我做了一个小的翻转视图应用程序，并且没有任何泄漏。
另一方面，识别泄漏的最佳方法是什么？
这不是很好，但它不会让你的应用程序被拒绝，除非它在审阅者面前导致崩溃。大小不如它发生的频率重要。如果每次运行应用程序时只发生一次，那没什么大不了的。如果每次用户做某事时都会发生这种情况，那么这就是一个更大的问题。
LLVM 的静态分析器可以为您找到其中的一些问题。清理你的构建，然后Build and Analyze从Build菜单中选择。Instruments 中还有一个 Leaks 模板。
跟踪这些错误并修复它们可能是一个好主意，因为与 Java 相比，Objective C 内存管理有很大的不同，在尝试调试一个大问题之前，最好先练习一些较小的东西最后期限迫在眉睫。
过多的总实时内存使用会导致您的应用程序崩溃和/或被拒绝。如果您在循环或重复方法中泄漏内存，泄漏最终会累积起来，您的应用程序将崩溃。
但是如果有泄漏，但不是在循环或重复过程中，并且总量小于应用程序的典型内存使用量，那么它可能是不礼貌和不雅的，但真的没有办法说，而且很少运营不利。
我经常通过在应用程序启动期间故意“泄漏”几兆字节来对我的应用程序进行压力测试，并确保应用程序仍然可以正常运行。其中一些应用程序已获准在应用商店分发，但泄漏的测试代码仍然意外启用（mia culpa！）。但这表明即使是几 MB 的泄漏也不是应用程序批准的问题（除非这足以使您的应用程序在低内存测试期间崩溃）。