当应用程序终止时,空新的Cocoa Mac OS X应用程序有14799项"仍然存在".他们泄漏了吗?

War*_* P 3 xcode memory-leaks instruments

当我使用XCode 4.5创建一个全新的Cocoa(Mac OS X)应用程序,关闭"基于文档"选项,并启用"自动引用计数"时,构建,而不更改任何内容,并使用"泄漏"使用Profiler运行模板,我看到19.76兆的暂时内存使用量和2.23兆字节的"活字节",包括3132个CFStrings,1371个CFBasicHash和几百个mallocs(),包括仍然由CoreGraphics分配的192 kb,即使程序已经终止.我在"Allocations"时间轴中看到了所有这些,但在"Leaks"时间轴中没有输出.我发现这种差异令人困惑.

我想知道,例如,如果可能的话,使用一个简单的Cocoa基础参考应用程序,如果没有,那么我想知道参考技术是什么,以了解哪些泄漏是我的,哪些是预期的.

请注意,使用Foundation-framework链接命令行工具,"开箱即用漏洞"的数量要简单得多,只有大约18个mallocs(),总计1.06 kb,因此似乎AppKit(Cocoa)是大多数的起源默认情况下"活动对象仍然在程序结束时堆上,不知何故,不泄漏".

有没有办法制作一个简单的非泄漏的Cocoa基础参考应用程序,或者框架本身是否泄漏了太多(可能是有意的),事实上,这是不可能的?

是的,我知道静态分析.是的,我知道垃圾收集.如果有人不想使用垃圾收集,但只想使用ARC,并希望在运行时真正看到泄漏的内容,那么这个人可以这样做,而不必忽略14799左右的基础和框架漏洞吗?

更新:我自己混淆的源#1正如建议的那样,我正在查看错误的时间线......但是,在我自己的辩护中(或解释我的困惑),我一直在考虑任何仍然分配的对象在程序执行结束时的堆上作为泄漏,这是一种常见于Pascal(Delphi)和C++世界的规则,实际上是在Linux和Windows上的大多数非垃圾收集语言中.也许这在Objective-C世界中根本不是"泄漏"?内存时间轴中的"生活项目"仍然"在堆上活动",这与泄漏有什么不同?事实上,我的AppController从未被告知"dealloc",这对我来说也是令人惊讶的,但我被告知是"可以预期的".

在此输入图像描述

Ber*_*ter 6

那些看起来像"创造并仍然生活"的物体.这些不是泄漏,而只是没有完成其生命周期的对象.由于应用程序仍在运行,因此总会有一组仍然存在的对象,但仍然有指向它们的指针.

泄漏是一个仍然存在的对象,但没有指向它.如果没有指针,则无法将该部分内存返回给操作系统.

要查看实际泄漏,请查看仪器上部的泄漏时间线.发生泄漏时,您会在此时间线中看到一个红条.设置此栏周围的检查范围,以查看下面有关泄漏的详细信息

在此输入图像描述