【问题标题】:Debugging strategies for over-retain in ARC?ARC中过度保留的调试策略?
【发布时间】:2013-01-23 09:24:03
【问题描述】:

我有一些对象被传递给我的应用程序中的很多不同的视图和控制器。当我期望它们被释放时,它们并没有被释放。显然某处存在错误的强指针,但它可能存在的表面积非常大——这些对象被移入和移出许多不同的数据结构。

我通常的首选解决方案是泄漏(不报告周期)和分配(列出该对象的 500 多个保留/释放)。有什么办法可以减少我的搜索空间吗?

理想情况下会有一个工具可以让我输入一个指针并查看对该对象的所有强引用,并且我可能会在大约 60 秒内查看列表并找到额外的引用.事实上,有这样一个工具——Object Graph 工具——但它不适用于 iOS 软件。

【问题讨论】:

  • 参见stackoverflow.com/questions/9139619/… - 泄漏确实找到了保留周期。如果它没有找到任何内容,您可能仍然可以从您的应用中可访问的某个地方获得一些强有力的参考。
  • 那些强引用正是我想要找到的。

标签: ios objective-c automatic-ref-counting instruments


【解决方案1】:

您需要分配工具。要跟踪单个对象类型,请启动应用程序。您需要在每个重要事件上创建一个 heapshot(我通常在您刚刚转换到视图控制器或从视图控制器转换时创建它们)。

一旦您获得了一个包含您有兴趣追踪的对象的 heapshot,那么您应该能够在 heapshot 的显示三角形下方找到该对象类型。对于该类型的每个对象,您可以通过单击该对象所在行中的箭头来获取已发送到该对象的保留和释放的历史记录。

【讨论】:

  • 这应该是公认的答案——救了我的培根!
【解决方案2】:

识别是否存在保留循环的最简单方法,只需在控制器的 dealloc()/deinit()(swift) 方法中放置一个断点,并且每当您弹出控制器时,检查是否调用此方法(如果有)控制器中存在保留循环,不会调用此方法。

斯威夫特

deinit {
    print("Memory to be released soon")
}

目标 C

- (void)dealloc {

    NSlog("Memory to be released soon");

}

如果您想获得有关强引用和根本原因的更多详细信息,您应该选择 Instrument 作为另一个答案。

【讨论】:

    猜你喜欢
    • 2019-10-15
    • 1970-01-01
    • 1970-01-01
    • 2016-10-08
    • 2019-09-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-02-11
    相关资源
    最近更新 更多