在 Xcode 4.5 中进行分析后 iOS 应用程序内存泄漏答案

【问题标题】：iOS app memory leaks after doing Analyze in Xcode 4.5在 Xcode 4.5 中进行分析后 iOS 应用程序内存泄漏
【发布时间】：2013-01-12 22:18:11
【问题描述】：

我正在使用 Xcode 4.5.2 来练习 iOS 编程。我的应用程序似乎编译得很好，但是当我执行 Product -> Analyze 时，我得到以下消息，这些消息在

中得到了更好的说明

如果有人可以向我解释一下，我将不胜感激？

附言。除了编译器建议的 __bridge 这个词外，我有点理解它的作用，我同意添加它。

【问题讨论】：

【解决方案1】：

您应该使用__bridge_transfer，而不是__bridge。您想将所有权转让给 ARC，因此它会为您清理它。否则将导致泄漏。

请参阅过渡到 ARC 发行说明中对 toll-free bridging 的讨论。

根据 WWDC 2012 的说明，Apple 实际上建议使用 CFBridgingRelease。因此：

NSString *encodedString = CFBridgingRelease(CFURLCreateStringByAddingPercentEscapes(...);

【讨论】：

非常感谢。只是出于好奇，我在哪里可以了解所有这些新增功能：__bringe、__weak 等？
我参考的那个文件，Transitioning to ARC 谈到了它。另请参阅Advanced Memory Management Programming Guide。

【解决方案2】：

只要您仔细跟踪它并在适当的时候释放它，它就不是泄漏。分析器只是提示，如果有人在外部需要它，函数应该返回自动释放的 ref，或者在函数内部释放它。

【讨论】：

我想我已经有一段时间没有进行 Objective-C 编码了，因为我确实尝试过 autorelease 它，但它将其标记为错误，说 APC 或其他东西不喜欢它。 ..
您不应从名称不以 alloc、new、copy 或 mutableCopy 开头的方法返回 +1 对象。这确实构成泄漏。
wolfrevokcats，您的项目可能是 ARC 配置的。如果是这样..我说的不太对；）我不喜欢ARC，自己发布东西。
老实说，是的，这个 ARC 确实让我感到困惑，但如果你仔细想想，如果它负责释放所有分配的内存（就像 C# 那样）——那就太好了。虽然，我不确定生成的代码会慢多少——希望不像 C# 的东西那么糟糕？对于一个普通的应用程序来说，这不会是一个问题。但它可能，例如，对于一个密集的游戏......
@wolfrevokcats 虽然我对 Umka 的观点表示同情，但我不得不说我认为不使用 ARC 很疯狂。我从未听说过可观察到的负面性能影响，它大大减少了我们为日常内存管理编写和测试代码的代码量。