4、音频剪辑管理：Resources与Addressables加载音频、音频池（AudioPool）设计模式、动态加载与卸载策略、内存优化技巧

好，咱们今天聊点实在的。音频剪辑管理，说白了就是怎么把声音文件请进游戏里，用完了再体面地送走。我见过太多项目，音频加载写得随意，结果内存爆了、卡顿了，玩家一进战斗就「滋滋」响。嗯，咱们今天就把这块彻底捋清楚。

4.1 Resources vs Addressables：两种加载方式的抉择

先说说最基础的。Unity 里加载音频，老牌做法是 Resources，新贵是 Addressables。我个人习惯是：小项目、原型阶段用 Resources 图个快；但凡有点规模的项目，直接上 Addressables，别犹豫。

4.1.1 Resources 加载

Resources 的用法很简单，把音频文件丢进 Resources 文件夹，然后：

AudioClip clip = Resources.Load<AudioClip>("Sounds/Explosion");
audioSource.PlayOneShot(clip);

但这里有个大坑——Resources 加载的东西，一旦加载就常驻内存。你想想看，一个 RPG 游戏有几百种音效，全塞进 Resources，那内存得多大？我曾经接手过一个项目，光音效就占了 400MB 内存，结果低端手机上直接闪退。

注意：Resources 加载的音频不会自动卸载。你必须手动调用 Resources.UnloadUnusedAssets()，但这个操作很重，别在游戏运行时频繁调用。

4.1.2 Addressables 加载

Addressables 就灵活多了。它支持按需加载、引用计数、自动卸载。我一般这样用：

public async void PlaySound(string address)
{
    var handle = Addressables.LoadAssetAsync<AudioClip>(address);
    await handle.Task;
    audioSource.PlayOneShot(handle.Result);
    // 播放完后记得释放
    Addressables.Release(handle);
}

你看，关键就在这个 Release。用完了就放，内存就不会堆积。我在项目中遇到过，有个同事忘了 Release，结果同一个爆炸音效加载了 30 次，内存直接翻倍。嗯，后来我们加了个引用计数工具来监控。

特性 Resources Addressables
加载方式 同步加载 异步加载（支持同步）
内存管理 手动卸载，易泄漏 引用计数，自动管理
热更新 不支持 原生支持
适用场景 小项目、原型 中大型项目、持续迭代

4.2 音频池（AudioPool）设计模式

好，加载方式选好了，接下来就是怎么高效播放。你想想看，如果每次开枪都 new 一个 AudioSource，那 GC 压力得多大？音频池就是解决这个问题的。

说白了，音频池就是一个对象池，专门管 AudioSource 的复用。我一般这样设计：

public class AudioPool : MonoBehaviour
{
    private Queue<AudioSource> pool = new Queue<AudioSource>();
    private List<AudioSource> activeSources = new List<AudioSource>();

    public AudioSource Get()
    {
        AudioSource source;
        if (pool.Count > 0)
        {
            source = pool.Dequeue();
        }
        else
        {
            source = gameObject.AddComponent<AudioSource>();
        }
        activeSources.Add(source);
        return source;
    }

    public void Return(AudioSource source)
    {
        source.Stop();
        source.clip = null;
        activeSources.Remove(source);
        pool.Enqueue(source);
    }

    private void Update()
    {
        // 自动回收播放完毕的音频
        for (int i = activeSources.Count - 1; i >= 0; i--)
        {
            if (!activeSources[i].isPlaying)
            {
                Return(activeSources[i]);
            }
        }
    }
}

这个池子有几个好处：第一，减少了 AudioSource 的创建和销毁；第二，自动回收播放完的音频，省心。我曾经在射击游戏里用这个模式，同时播放 50 个枪声，帧率纹丝不动。

小技巧：音频池的初始大小可以设为 10-20 个。如果游戏里同时播放的音效特别多（比如爆炸连击），可以动态扩容，但记得设个上限，别让池子无限膨胀。

4.3 动态加载与卸载策略

音频怎么加载、什么时候卸载，这里头学问大了。我总结了一套策略，你们可以参考：

  • 场景预加载：进入新场景前，把该场景会用到的音频提前加载好。比如进入战斗场景前，加载所有武器音效。
  • 按需加载：某些不常用的音频，比如彩蛋音效、特殊剧情音效，用到时再加载。用 Addressables 的异步加载，不会卡主线程。
  • 延迟卸载：音频播放完后，不要立刻卸载。我习惯设一个 30 秒的延迟，如果 30 秒内再次用到，直接从缓存里取，省得反复加载。
  • 场景卸载时清理：离开场景时，把该场景专用的音频全部卸载。通用的 UI 音效、背景音乐可以保留。

为什么会这样设计？说白了，就是「用多少加载多少，用完了别急着扔」。我见过一个项目，每次切场景都把所有音频卸载再重新加载，结果切场景卡了 2 秒。后来改成延迟卸载，切场景丝滑多了。

4.4 内存优化技巧

最后聊聊内存优化。音频占内存，说白了就是两个东西：加载后的 AudioClip 数据，以及播放时的缓冲区。我分享几个实战技巧：

  1. 压缩格式选对：短音效用 PCM（无压缩），长音乐用 MP3 或 Vorbis。别把 10 秒的枪声也用 MP3，解码反而更慢。
  2. 降低采样率：游戏音效 22050Hz 就够了，人声用 44100Hz。我见过有人把脚步声也用 48000Hz，纯属浪费。
  3. 单声道优先：除非是立体声定位的音效，否则一律用单声道。内存直接减半。
  4. 预加载 vs 流式加载：短音效预加载，长音乐用流式加载（Load In Background 勾上）。
  5. Addressables 的远程分组：把不常用的音频放到远程分组，用到时再下载。比如游戏里的周年庆音效，平时根本没人听。
核心原则：音频内存优化的本质，就是「少加载、早释放、选对格式」。别让音频成为你游戏的内存杀手。

嗯，关于音频剪辑管理，今天就聊这么多。下一章咱们会深入讲讲音频的 3D 空间化与混音，到时候再细聊。记住，音频管理做得好，玩家体验差不了。

← 上一章 📖 返回目录 下一章 →