CocosDenshion声音模块在Cocos2D-X引擎中是一个非常独立的内容。读者甚至可以将其看成是一款跨平台的声音引擎。虽然它也是由引擎的开发者编写的，但是它拥有自己的开源声明、目录代码以及示例项目。这样做的好处，一个独立的声音模块，可以更方便维护升级，也更容易被替换。

与Cocos2D-X引擎的源代码相比，CocosDenshion内容就少了许多。声音模块包含了大约四个类左右。虽然内容少了，但其依然保持了引擎的模式结构和编码风格。

对于大多数开发者来讲，游戏中操作声音方式，无非就是播放背景音乐和音效。因此为了节省开发者编码工作，CocosDenshion代码结构的设计采用了外观模式和单例模式。图8-2展示了CocosDenshionde声音模块的代码结构。

SimpleAudioEngine是一个典型的外观模式，而SimpleAudioEngine、CDAudioManager和CDSoundManager则使用了单例模式。

作为开发者只需要熟悉类SimpleAudioEngine的函数方法，而无需关心CDAudioManager和CDSoundManager的内容。这就是外观模式的好处。它为开发者提供了简单的上层函数接口，隐藏了具体底层的实现方式。然后在引擎当中，不同平台采用了不同的实现技术。比如在iOS平台中使用了OpenAL声音库，而在Android平台则使用了OpenSL声音库，其他平台也使用了各自的声音库。

CDSoundEngine、CDAudioManager两个类提供了操作和管理声音的功能。具体它们是如何工作的，这里就不再讨论了，感兴趣的读者可以自行去研究相关代码。

CocosDenshion针对不同的平台已经封装了低级的操作声音的API，但是对于开发者来讲，其想要了解系统内部是如何协作来完成声音处理任务的。这样会加大开发者使用的难度，同时，也降低了声音模块的灵活性。假如需要升级内部实现的功能，就有可能会影响到已经完成的代码。由此引擎的设计者，巧妙地采用了外观模式与单例模式的混合。

注意：SimpleAudioEngine并没有增加任何功能，而只是把声音操作类进行组合来完成一些常用的功能，为开发者提供简化的函数接口。

单例模式保证了在游戏当中只存在一个处理声音的对象。这样方便开发者在游戏各处的可以操作声音。众所周知，从游戏的开始到结束都会一直伴随着各种各样的声音。因此在开发者编写代码中也会存在许多调用声音功能的地方。单例模式就提供了这种随处调用的便利方式。

注意：单例模式有其便利的地方，也有麻烦的问题。过多的或者不太合理的调用也容易让人迷惑。

跨平台引擎总是要考虑更多的问题。CocosDenshion也不例外。读者可以查看引擎目录下的CocosDenshion文件夹。在此文件夹内，就存放着不同平台的声音实现方式的源代码。这与之前介绍用户交互类似，在Android平台需要使用Java编码，而Mac与iOS则会用到Objective-C编码，只有Linux和Win32仅用了C\C++的编码。各个平台具体的实现方法，读者可以自行查看源代码。