自定义Unity组件——AudioManager（音频管理器）

我与岁月的森林

已于 2024-07-06 12:26:14 修改

阅读量2.1k

点赞数 4

分类专栏： # 自定义组件文章标签： unity 音频

于 2023-09-25 16:05:57 首次发布

本文链接：https://blog.csdn.net/hgf1037882434/article/details/133272525

版权

自定义组件专栏收录该内容

5 篇文章 0 订阅

订阅专栏

需求描述

在游戏开发中，音频资源是不可或缺的，通常情况下音频资源随机分布，各个音频的操作和管理都是各自负责，同时对于音频的很多操作逻辑都是大同小异的，这就造成了许多冗余代码的堆叠，除此之外在获取各类音频资源的时候也会造成不必要的开销。所以解决资源分散的问题最直接的方式就是集中管理和分配，通过统一的渠道和特有标识即可获取或操作对应的音频资源。所以本篇文章将围绕这个方案进行尝试。

功能描述

在Unity中我们导入的音频资源都会转换为AudioClip，音频的设置和管理则由AudioSource负责，AudioListener负责监听音频。我们可以在此基础上去封装，从而打造一个音频管理器。

音频管理器负责管理音频信息以及操作音频，比如音频信息的增加和删除，音频的播放和暂停等；

音频信息可以使用一个单独的实体类来记录，用于记录AudioSource组件中的信息，之所以单独用一个实体类来记录音频信息而不直接采用AudioSource，主要是可以通过业务需求去动态调整所要记录的音频信息，我们的实际开发中并非需要AudioSource中所有的信息，有时候仅仅需要其中的一部分，同时音频信息可能涉及存储，直接采用AudioSource可能无法与已经开发好的存储系统相互兼容，而实体类可以为其添加接口或继承来兼容存储系统；

AudioSource组件的管理可以通过一个组件池进行管理，我们知道AudioSource也是等同于一个音频实体类，但是其同时也是一种组件，组件同样作为一种资源，通常情况下相比简单的实体类而言会带来更大的开销，例如一个场景中有十个游戏对象有播放音频的需求，那么按照传统情况就需要每个游戏对象挂载一个AudioSource组件，但是实际运行中十个游戏对象并不一定需要同时播放音频，它们或许都存在各自触发音频播放的条件，我们只需要在游戏对象需要播放音频时为其分配一个AudioSource组件即可，组件池则负责维护AudioSource组件的生产、获取和归还，进而减少资源开销。

本质上，AudioSource组件承担的工作就是记录音频信息和操作音频，我们现在将记录工作分担给音频信息实体类，而操作音频的工作则分担给音频管理器，例如音频管理器的播放依旧是调用AudioSource的播放方法，在播放之前由音频管理器去获取AudioSource组件并且为之配置音频信息，其它的音频操作逻辑同理。