应用程序崩溃说使用弧的内存警告 [英] App Crashes saying Memory Warning Using Arc

问题描述

我正在使用ARC，应用程式崩溃，说收到内存警告。我使用了苹果乐器：

I am using ARC and the app crashes saying received memory warning. I have used the apple instruments:

看起来我没有任何泄漏，但我找不到哪里错了。崩溃与内存有关，因为我无法使用发布和任何类型。这是我第一次使用arc来处理内存使用。有没有我可以调试这个，因为我在处理这个近两个月。我的代码在我的git中心，所以如果你看这将是有帮助的。你可以找到它 here。

It looks like I do not have any leaks but I cannot find where is wrong. The crash has to do with the memory and due arc I cannot use release and any sort. It is my first time dealing with memory usage using arc. Is there away I can Debug this since I am dealing this for nearly two months. I have my code on my git hub so it will be helpful if you look at it. You can find it here.

我在处理这个问题好几个星期，想要结束这个。谢谢。

I am dealing this problem for weeks and want to end this. Thanks.

推荐答案

并不是所有的泄漏都出现在仪器的泄漏工具中。特别是，如果视图控制器具有强大的参考周期，视图控制器不仅不会被释放，也不会释放任何成员。但是看看你的分配你的记忆永远不会被释放，所以你可能在某个地方有泄漏。我们很难诊断，因为你的github项目是不完整的。但这里有一些想法：

Not all "leaks" show up in the "Leaks" tool in Instruments. And, notably, if a view controller has a strong reference cycle, not only will the view controller not be deallocated, but none of its members will be deallocated either. But looking at your allocations your memory is never getting released, so you probably do have a leak somewhere. It's hard for us to diagnose, though, because your github project is incomplete. But here are a few thoughts:

1. 强引用周期并不总是显示在泄漏工具中

1. Strong reference cycles don't always show up in the Leaks tool.

在传统的强参考循环的变体中，您的代码使用重复的 NSTimer 保持对您的视图控制器的强烈参考，这将导致您的视图控制器永远不会被释放（因为定时器维护自己对视图控制器的强大参考）。要解决这个问题，您的视图控制器必须在相关视图消失时停止计时器：

In a variation of the traditional strong reference cycle, your code employs a repeating NSTimer that will keep a strong reference to your view controller which will result in your view controller never being released (because the timer maintains its own strong reference to your view controller). To fix this, your view controller must stop the timer when the associated view disappears:

- (void)viewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];

    self.timer = [NSTimer scheduledTimerWithTimeInterval: 0.05f target: self selector: @selector(tick) userInfo: nil repeats: YES];
}

- (void)viewWillDisappear:(BOOL)animated
{
    [super viewWillDisappear:animated];

    [self.timer invalidate];
    self.timer = nil;
}

除了强大的参考周期，如上所述，导致像您与我们分享的更多分配是视图控制器之间的循环流程。例如，如果您的应用程序从视图控制器A执行推/模式划分以查看控制器B，则应用程序必须弹出/关闭/退出才能查看控制器A.如果您将/模式从B推送到新的A实例，你最终会放弃你旧的A的实例，导致像你这样的分配图。

Besides of strong reference cycles, like above, another phenomenon that can result in increasing allocations like you've shared with us is a circular flow between view controllers. For example, if your app does a push/modal segue from view controller A to view controller B, the app must then pop/dismiss/unwind back to view controller A. If you push/modal from B to a new instance of A, you'll end up abandoning your old instance of A, resulting in an allocations graph like yours.

可以导致您的分配图的各种事例的几个例子。但是，我们很难通过提供的有限信息来进一步诊断。

These are just a few examples of the sorts of things that can result in your allocations graph. But it's hard for us to diagnose further with the limited information provided.

在做任何事情之前，请使用Xcode的静态分析器（命令 + 转移 + B 或产品菜单上的分析），并确保您在那里得到一个干净的健康账单。让Xcode帮助您识别代码中的编程问题。

Before doing anything else, use Xcode's static analyzer (command+shift+B or "Analyze" on the "Product" menu) and make sure you get a clean bill of health there. Let Xcode help you identify your programming issues in your code.

一旦解决了静态分析器识别的任何问题，您就可以进入仪器。请参阅WWDC 2012视频， iOS应用程序性能：内存。大约32分钟，它显示了一个非常像您的分配图，描述了这些问题（泄漏，废弃内存或缓存内存）的三个来源，并向您展示了如何使用分配工具来确定准确的来源这个问题。

Once you've resolved any issues identified by the static analyzer, you can then dive into Instruments. Refer to the WWDC 2012 video, iOS App Performance: Memory. About 32 minutes into it, it shows an allocation graph much like yours, describes the three sources of those sorts of issues (leaks, abandoned memory, or cached memory), and shows you how to use the Allocations tool to identify the precise source of the problem.

您应该遵循该视频，您一定会对分配工具功能（例如比较堆快照）进行了解，以识别泄露的对象，或查看扩展的详细信息并调用树来查找创建泄漏对象的源代码。一旦准确地确定了哪些漏洞，我们就可以帮助您解决问题。

You should follow along that video and you'll definitely gain some familiarity with Allocations tool features (such as comparing heap snapshots) to identify what object leaked, or look at the extended details and call tree to find the source code that created the leaked object. Once you identify precisely what's leaking, we can help you resolve the issue.

顺便说一下，比快照更容易在该视频中描述的，我经常只需在<分配>中的图形中的选项 - 点击并拖动特定的峰值（特别是显然从未释放的）。如果这样做，对象摘要将显示您在执行窗口期间已分配并未释放的对象（如果按实时字节排序排序最有用）：

By the way, even easier than the heapshots described in that video, I'll often just option-click-and-drag at a particular spike (notably one that obviously is never released) in the graph in "Allocations". If you do that, the object summary will show you the objects (most useful if you sort by "Live Bytes") that have been allocated and not released during that window of execution:

这可以是有帮助的，但有时它只是隐含的 CFString 或 CGImage 分配。因此，有时候有必要在代码中查看这些对象的分配位置。如果从统计 - 对象摘要切换到调用树，它现在将显示每个方法占用了多少内存（如果我还检查反转调用树，我发现此屏幕最有用和隐藏系统库）：

That can be helpful, but sometimes it's just cryptic CFString or CGImage allocations. It's therefore sometimes useful to see where in your code those objects were allocated. If you switch from "Statistics" - "Object Summary" to "Call tree", it will now show you how much memory was taken up by each of your methods (and I find this screen most useful if I also check "Invert Call Tree" and "Hide System Libraries"):

如果您在此处双击一个符号名称，它实际上会显示违规代码：

If you then double click on a symbol name here, it will actually show you the offending code:

通过这个过程，我可以看到正在分配的是什么，我现在可以去确定为什么这个记忆永远不会被释放（在这种情况下，这是我故意使用重复的计时器，我从来没有无效）。

Through that process, I can see what is being allocated at that spike, and I can now go about identifying why that memory is never getting released (in this case, it was my deliberate use of a repeating timer that I never invalidated).

还有其他的技巧在更复杂的场景中很有用（我特别喜欢让我的代码信号标志出现在仪器中我可以更准确地关联活动在我的代码中，我在仪器中发生了什么），但这可能太多了。希望这个选项 - 在文书中点击和拖动将是一个有用的工具，用于识别被分配的内容，从未发布。

There are other tricks that are useful in more complicated scenarios (I'm particularly fond of having my code signaling flags that appear in instruments so I can more accurately correlate activities in my code with what's going on in Instruments), but that's probably too much to get into here. Hopefully this option-click-and-drag in Instruments will be a useful tool to identify what's being allocated and never released.

这篇关于应用程序崩溃说使用弧的内存警告的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！