【问题标题】:Understanding the Instrument for memory leak checking - iPhone了解用于内存泄漏检查的工具 - iPhone
【发布时间】:2010-11-22 16:57:16
【问题描述】:

上面给出的图像是我的应用程序泄漏。

在这里我想了解一下,在扩展细节中 - 您可以看到不同的颜色,如浅绿色、浅粉色、浅棕色、浅紫色。

每种颜色代表什么?

现在另一个困惑是“如何定位造成内存泄漏的代码?”

内存泄漏达到什么限制 - 实际的 iPhone 可以继续使用。 (假设 10 个字节没问题,20 个字节没问题,200 个字节一个问题)

  • 每种颜色代表什么?
  • 哪种颜色表示我们的代码/我们可以从哪个细节获得分配对象但忘记释放它的代码?

(例如 - 在详细点击 UIKit 第二个单元格时 - 我们无法访问代码)

  • 为什么我们必须解决所有的泄漏问题? - 即使是一次泄漏也会堵塞 iPhone?
  • 为什么 iPhone 允许泄漏保留在内存中? / 为什么应用程序终止后没有自动进行垃圾回收?
  • 如果我尝试根据工具释放应该释放的对象,我的应用程序会异常终止。如果我不解除分配,我的应用程序可以完美运行,如何?
  • 为什么建议您在视图中等待 10 秒或更长时间,如果有泄漏,仪器会检测到泄漏?

【问题讨论】:

    标签: iphone memory-leaks instruments


    【解决方案1】:

    忽略颜色,其中 [DashBoard viewDidLoad] 是泄漏的来源,它是如何初始化 URLConnection 的(可能你在连接完成时没有释放它?)

    现在回答您的其他问题:

    • 为什么我们必须解决所有的泄漏问题? - 即使是一次泄漏也会堵塞 iPhone?

    是的。部分原因不仅是您会简单地用完内存,而且由于整个手机只有这么多内存可以使用,因此看门狗应用程序会不断监视您的应用程序,如果它发现内存使用会提前关闭它只会不断增长...

    • 为什么 iPhone 允许泄漏 在记忆中? / 为什么要垃圾收集 之后不会自动完成 终止申请?

    当应用退出时,所有应用内存都会被释放。

    • 如果我尝试释放对象 应根据 仪器,我的应用程序 异常终止。如果我不 dealloc,我的应用程序运行 完美,怎么样?

    在这里,我无能为力,您确实需要阅读有关保留/释放内存周期的更多信息...如果您释放保留计数为 0 的对象,则应用程序崩溃,因为该对象已消失。

    • 为什么建议您等待 观看长达 10 秒或更长时间,如果 有泄漏,泄漏将是 被 Instruments 检测到?

    因为仪器通过每隔一段时间对内存进行采样来工作,所以仪器可能需要一点时间来在一个动作后读取内存。

    【讨论】:

    • +1 出色的回答肯德尔。 @sagar,您应该注意,对于问题 3,您应该永远 直接调用 dealloc,只保留或释放(唯一的例外是 [super dealloc])。我相信您的解决方案是实施自动释放,因为听起来您的崩溃是由提前释放对象引起的。例如 [[[NSArray alloc] init] autorelease];
    【解决方案2】:

    首先,堆栈中的东西是根据它们来自哪个库来着色的,因此它不包含那么多信息。

    其次,与其担心 iPhone 会泄漏多少,我会专注于不让它泄漏。

    要查找泄漏,有几个选项:

    • 在构建项目时使用CLANG static analyzer
    • 手动查找泄漏。您必须始终遵循内存管理规则:如果您使用allocretaincopy 一个对象(包括使用@property (retain)(copy)),您必须 releaseautorelease 它。

    【讨论】:

      【解决方案3】:

      颜色代表调用堆栈正在经过的不同库。

      泄漏是由代码中进行分配的框架引起的,即使实际分配发生在操作系统库的深处。 Instruments 正在向您显示确切泄漏内存的分配位置。您必须弄清楚代码中的哪一行导致了泄漏的分配,这将是右侧堆栈中的帧之一。

      实际的 iPhone 没有太多 RAM 可供您的应用程序使用。我倾向于保守地估计大约 25MB 的 RAM 供我的应用程序使用。如果代码使用得足够多,任何泄漏,无论多么小,都会使众所周知的船沉没。

      【讨论】:

        【解决方案4】:

        在堆栈扩展视图中查找您的应用程序名称。内存分配通常显示在最后,因此您确切知道哪个库负责内存分配。因此,您应该从代码向下显示的行开始跟踪,直到最后。颜色只是更容易跟踪与相同库相关的代码行。相同的库调用将使用相同的颜色。

        至于追踪泄漏本身。首先通过双击扩展视图中的行转到您的应用程序调用,并尝试了解究竟是什么泄漏。有时您可以用非泄漏替代品替换泄漏呼叫。例如,我使用调用 imageNamed 从包中检索图像,由于内存不足,应用程序不断崩溃。我刚刚搜索了 imageNamed leaks 并找到了关于如何在我的应用程序中实现图像现金的非常有用的文章。事实上,imageNamed API 泄​​漏了。 iphone SDK 中有 API 泄​​漏。

        此外,请尝试检查您是如何使用 alloc/retain/release 等的,无论您是释放还是自动释放分配的内存。

        祝你侦探工作顺利。

        【讨论】:

        • @Nava Carmon - 如果您有该 API 泄​​漏的链接。请你把它放在你的答案中。谢谢。
        【解决方案5】:

        我也有仪器泄漏的问题。我今天第一次使用泄漏运行我的应用程序并发现了几个泄漏。不应该是泄漏的泄漏,因为它们无法泄漏,除非正在执行一些神奇的代码并提高我的对象的保留计数。我了解内存管理指南,知道如何使用自动释放池等。但是,如果我对其进行一些控制,即使是基于空视图的应用程序也会包含泄漏。只需点击 2-3 次左右。继续尝试。我真的不了解信息工具试图提供的信息。这些“泄漏”是真的泄漏,还是只是仪器应用程序可疑的事情?一个没有用户代码、只有几个控件放在一个空视图上的空应用程序是否应该泄漏内存?

        【讨论】:

        • 我不相信它们是可疑的“东西”。 Leak 工具检查应用程序的可写内存、寄存器和堆栈中是否存在对内存块的引用。如果没有,并且内存块仍然存在,则仪器将缓冲区视为泄漏。
        • 这是在模拟器上还是在设备上?我发现在模拟器上检测到的“泄漏”在实际设备上运行时不会出现,所以我不再费心在模拟器上分析泄漏。
        • 设备上的泄漏有所不同,一般来说泄漏较少。我停止为 iphone 开发。
        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2011-02-20
        • 1970-01-01
        • 2012-12-28
        • 2010-10-20
        • 2019-06-02
        • 2011-06-06
        • 1970-01-01
        相关资源
        最近更新 更多