iphone - 无法修复 Open AL 中的严重内存泄漏

Question

我的一个大型 iPhone 项目即将结束，在检查内存泄漏时偶然发现了这个巨大的项目。我按照本教程实现了声音:

http://www.gehacktes.net/2009/03/iphone-programming-part-6-multiple-sounds-with-openal/

很有魅力，很多人都使用它，但是当声音最初加载时，我在项目开始时遇到了巨大的泄漏。以下是泄漏开始的代码行:

[[Audio sharedMyOpenAL] loadSoundWithKey:@"music" File:@"Music" Ext:@"wav" Loop:true];
[[Audio sharedMyOpenAL] loadSoundWithKey:@"btnPress" File:@"BtnPress" Ext:@"wav" Loop:false];
[[Audio sharedMyOpenAL] loadSoundWithKey:@"ting1" File:@"GlassTing1" Ext:@"wav" Loop:false];

等等。等等，它总共加载了 20 个声音。更具体地说，在 Audio.m 文件中这段代码:

+ (Audio*)sharedMyOpenAL {

@synchronized(self) {
    if (sharedMyOpenAL == nil) {
        sharedMyOpenAL = [[self alloc] init]; // assignment not done here

    }
}
return sharedMyOpenAL;
}

我不确定如何解决这个问题，如果对此事有任何帮助，我们将不胜感激。

谢谢。

Answer 1

“泄漏”不就是Audio 单例吗？我不确定泄漏检测是如何工作的，但从某种角度来看，大多数单例都是泄漏，因为它们只会在应用程序退出后释放内存。

如果确实是这样，那么就看你是否需要释放声音所占用的内存了。内存使用量不应增加，因此您不必担心“传统泄漏”场景，即您的应用程序占用越来越多的内存直到被杀死。您使用的代码似乎不支持声音卸载，因此如果您想释放内存，则必须自己添加该代码。

还有个人观点:使用单例编写音效引擎并不是一个好的设计。管理声音变得很痛苦(这正是你面临的问题)，单例添加了很多不必要的样板代码等。我认为声音没有理由不应该是具有自己生命周期的简单独立对象 - 这就是方式我已经在 my attempt at an OpenAL SFX engine 中完成了。当然，我可能是错的。

<小时/>

更新:我认为神奇的“此处未完成作业”是关键。单例代码取自Apple documentation ，但有人插入了额外的作业。 sharedFoo 方法应如下所示:

+ (MyGizmoClass*)sharedManager
{
    @synchronized(self) {
        if (sharedGizmoManager == nil) {
            [[self alloc] init]; // assignment not done here
        }
    }
    return sharedGizmoManager;
}

当您对 self 执行额外赋值时，就会创建您要查找的泄漏。