Objective c 电弧过早释放或根本不释放的问题

Objective c 电弧过早释放或根本不释放的问题,objective-c,cocoa,automatic-ref-counting,avfoundation,Objective C,Cocoa,Automatic Ref Counting,Avfoundation,我有一个简单的小音乐播放器,是用10.8版本的AVFoundation编写的。它工作得很好,但我最近才被介绍到ARC,这给我带来了一些麻烦 该应用程序是基于文档的,所需的大部分代码都保存在预制的document.h/.m文件中。头文件中定义了一个_u strong AVAudioPlayer对象,实现中的所有函数都使用它来播放音频文件。使用标准的readFromURL:方法加载文件 关闭文档时,文件不会被释放,甚至不会继续播放。如果AVAudioPlayer设置为“弱”,它几乎会立即释放,文件将

我有一个简单的小音乐播放器,是用10.8版本的AVFoundation编写的。它工作得很好,但我最近才被介绍到ARC,这给我带来了一些麻烦

该应用程序是基于文档的,所需的大部分代码都保存在预制的document.h/.m文件中。头文件中定义了一个_u strong AVAudioPlayer对象,实现中的所有函数都使用它来播放音频文件。使用标准的readFromURL:方法加载文件

关闭文档时,文件不会被释放,甚至不会继续播放。如果AVAudioPlayer设置为“弱”,它几乎会立即释放,文件将不再播放


这里有我遗漏的东西吗?我知道我不能在ARC下手动释放,所以什么可以使对象保持绑定状态?

默认情况下,ARC中的对象指针很强。任何对
AVAudioPlayer
的引用,如果没有定义为弱引用,并且位于仍然存在的对象/类中,都会阻止它被释放。如果您的文件继续播放,这可能不是ARC问题,而是您正在使用
AVAudioPlayer
执行的操作


在ARC中“释放”内存的一种方法是将指向对象的指针设置为
nil
。如果没有对对象的其他引用,它将被取消分配。

人们真的不应该使用ARC。@NikolaiRuhe这不会再发生了。H2CO3,您的意见虽然对您自己完全有效,但不应该是一个笼统的建议。ARC正是整个系统的发展方向,工具针对ARC进行了优化,编译器在ARC下表现得更好,而ARC在苹果的许多项目中都得到了采用,这正是因为它生产出更稳定的软件,维护问题更少。在这种情况下,听起来OP需要显式停止音频播放,这应该与内存管理分离。谢谢,在WindowClose下将播放器设置为零会很好地工作。不过,我会看看我能不能弄清楚到底是什么让它一直存在。