[Unity workflows] Unity Addressables 迁移：耳边的音乐（第 1 部分）

英文原文：https://thegamedev.guru/unity-addressables/migration-music/

  您已经看到了 Addressables 的潜在好处，并且想在您的游戏中试一试。 但是有很多可能性！ 从哪里开始 Unity Addressables 迁移？ 这里有一个选项供您选择：音乐。

  再来一首歌……

  视频游戏音乐家的那些著名的遗言说服程序员将最后的音轨添加到即将发布的游戏中。

  可能会出什么问题？

  我会告诉你：最后一首歌只是在即将溢出的玻璃杯上加了一滴水。

  实际上，它溢出了。

  当 Bobby 收到女友的短信要求他洗衣服时，需要这首歌额外增加的 10MB。

  所以操作系统决定收回它的内存。 邪恶的操作系统杀死了鲍比过去两个小时玩的游戏。

  你知道有趣的部分是什么吗？ 保存游戏已损坏。

  你知道我们的朋友鲍比做了什么吗？

  我会告诉你他没有做什么。

  他没有购买更强大的设备。

  相反，他愤怒地掀翻了他面前的桌子。 只是桌子是玻璃做的。

  在清理掉地板上的所有碎片之前，Bobby 做了一些事情。 他向自己承诺，将尽其所能防止这种情况发生在其他用户身上。

  Bobby 去了应用商店，写了历史上最著名的 1 星评论。 人们在情感上与他的联系如此紧密，以至于他的评论得到了难以置信的支持。 如此受欢迎，以至于它超越并超越了所有 5 星评论。

  事实上，再也没有任何其他用户发生过崩溃，因为新玩家的手指离开了安装按钮。

  Bobby 可以做什么呢？

  好吧，Bobby 可以给开发人员发消息，而不是将您将要阅读的文章发送给他。

  降低内存消耗以减少崩溃？ 提高性能？ 减少加载时间？

  不管你的目标是什么。 如果您想立即开始使用 Addressables，您将体验 Unity Addressables 迁移过程。

  迁移无非就是从你所在的地方搬到你想去的地方。

  在本系列的上下文中，我们将把您当前使用的资产管理系统迁移到基于可寻址的系统。

  是的，即使您不知道什么是资产管理系统，您也已经默认使用了一个：Unity 的直接引用。

  正如我稍后将向您展示的那样，每次从项目视图将此资产分配给检查器中组件的字段时，您都可以说您直接引用了该资产。 例如，将声音分配给 AudioSource 的字段 AudioClip 被视为具有对该声音的直接引用。

  但是这些直接引用有什么问题呢？

  这应该是您主要关心的问题：Unity 会自动将直接引用的资源加载到内存中。 除了不提供直接参考之外，您无能为力。

  多么沉重的负担。

  另一种方法是使用间接引用。

  好处是什么？

  使用 Addressables，您可以选择何时以及是否加载您指向的资产。 粒子、预制件、纹理、音乐，应有尽有。 通过这样做，您将减少内存消耗、提高性能并获得其他几个巨大的优势，例如发布 DLC 的可能性等。

  在这篇博文中，您和我将开始升级之旅，并迁移制作精美的游戏中最常见的内容类型之一：配乐。

表中的内容

• Unity Addressables 迁移：要求
• 一级开发人员：直接引用的 AudioClips
• 二级开发人员：间接引用的 AudioClips
• Unity Addressables 迁移：我们从这里何去何从？

---

Unity Addressables 迁移：要求

  这个很简单，除非你坚持使用旧版本的 Unity。

  您需要为 Unity 2019+ 安装 Unity Addressables Package。

  我在我的 Unity Addressables Tutorial 博客文章中发布了分步指南，但您现在不必阅读它。 这就是你想要的：

1. 打开Unity，进入Window → Packages打开包管理器界面
2. 向下滚动并查找 Addressables 包
3. 安装它

按下按钮开始我们的任务

---

一级开发人员：直接引用的 AudioClips

  我们将通过迁移最简单的资产之一：音乐来开始我们的升级任务。

  我假设您的项目周围有一个全局 MusicPlayer 对象。 那个人附有一个 AudioSource 组件，因此我们可以通过其 AudioClip 组件播放我们选择的音乐。

  一般来说，我们还有一个脚本，其中包含要播放的曲目列表，因此我们会接连播放。

  下面是一个隐藏在视线中的直接引用示例。

  回到我们的主题，您真的不希望一次有太多对不同 AudioClip 的直接引用。 这意味着，它们都加载到内存中，即使我们可能只播放一首歌曲。

  拥有较长的 AudioClip 会增加应用程序的内存使用量以及加载时间。

  你会从你的内存预算中窃取而不是花在真正酷的东西上。

  要么你必须非常小心你使用的直接引用，或者更好的是，你可以使用 Unity Addressables 从间接引用中获益。

自然地，您和我在这里选择第二种方法。

---

二级开发人员：间接引用的 AudioClips

  让您的性能爆炸开始。

  通过在项目视图中浏览我们的音乐曲目来开始迁移。 就我而言，我的音频剪辑称为 8-bit-music-track-1、8-bit-music-track-2 等等。

  选择每个 AudioClip 后，我们在检查器中勾选其 Addressables 复选框。

  这些 AudioClip 现在是 Addressables 系列的一部分，并且可以间接引用它们。

关于我们的下一个任务……

拥有权利的同时也被赋予了重大的责任

  这些间接引用不会自行管理！

  我们将创建一个整洁的 MusicPlayer 脚本，它将一个接一个地播放每个音乐曲目。 我们会将此脚本添加到同名的新游戏对象中。

所以我们去输入一些基本代码

namespace TheGamedevGuru
{
	public class MusicPlayer : MonoBehaviour
	{
	    [SerializeField] private AudioSource _audioSource = null;
	    [SerializeField] private AssetReference[] _soundtracks = null;
	    private int _playingSoundtrack = 0;
	    IEnumerator Start()
	    {
	        while (true)
	        {
	            var currentOperationHandle = _soundtracks[_playingSoundtrack].LoadAssetAsync<AudioClip>();
	            yield return currentOperationHandle;
	            var newAudioClip = currentOperationHandle.Result;
	            _audioSource.clip = newAudioClip;
	            _audioSource.Play();
	            
	            yield return new WaitUntil(() => _audioSource.isPlaying == false);
	            
	            _audioSource.clip = null;
	            Addressables.Release(currentOperationHandle);
	            
	            _playingSoundtrack = (_playingSoundtrack + 1) % _soundtracks.Length;
	        }
	    }
	}
}

这个示例脚本做了很多简单的事情。

  首先，在第 5 行中，我们保持对音频源组件的（直接）引用。 这个组件是纯粹的行为，它（几乎）没有与之关联的数据，所以直接引用是可行的方法。

  引用的 AudioSource 组件稍后将播放我们选择的音频剪辑。

  在第 6 行中，我们保留了一系列对将按顺序播放的音轨的间接引用。 该数组的每个元素对应于用户完成任务时要播放的曲目。 这里的关键是要注意我们正在使用 AssetReference 来保存对音轨的间接引用。 如果我们要使用直接引用，我们就会有一个 AudioClip 数组。

  但是以这种方式使用间接引用将阻止 Unity 自动加载它们并使您和我的内存消耗和加载时间猛增。 这些间接引用可以直接从检查器中分配，如下所示。

在第 7 行中，我们只保留一个整数以了解我们当前正在播放的配乐索引。 簿记之类的。

  然后，在第 9 行，我们告诉 Unity 生成一个协程来处理播放音乐逻辑的主循环。 有几种方法可以在没有协程的情况下做同样的事情，但我会坚持清楚。

  第 13 行是什么？

  那里，我的朋友，是所有神奇果汁发生的地方。

  我们命令 Addressables 加载我们的整数指向的 AudioClip。 由于这需要一些时间，我们在继续之前等待它在第 14 行完成。

  什么时候加载完成？ 我们播放它！ 生成的 AudioClip 可以在我们等待的句柄的结果字段下的下一行中找到。

  然后我们在第 16 行分配新加载的剪辑并继续播放它。

砰！

那是什么？

那是一声爆炸。

您的玩家开始流出冷汗并感到肾上腺素激增

所有这一切都归功于你刚刚开始将令人毛骨悚然的音乐推入他们的耳朵

  但遗憾的是，所有曲目都结束了。 所以我们等待它在第 19 行完成，然后我们从 AudioSource 取消分配该 AudioClip。

  最后，第 22 行释放了我们之前通过 Addressables API 加载的数据。

  一切都像（精心照顾的）婴儿一样干净。

  在第 24 行中，我们指向下一个要在循环的下一次迭代中加载和播放的 AudioClip。 冲洗并重复。

  嘿，我们在几分钟内就启动并运行了我们的数字点唱机。 不错。

  但是有什么好处呢？

现在您的游戏将表现出色。 您的游戏一次只会在内存中保存一个曲目（而不是 4+）

该解决方案的扩展性很好，就是这样。

  作为旁注，AudioClip 的加载类型字段可以设置为流式传输。 这会给你一种错误的印象，即你不会从 Addressables 中获利。

  我将论证内存中的流式传输和压缩都可以为您带来内存收益，但这是以增加 CPU 负载为代价的。 Addressables 将为您提供最大的性能，例如在加载时解压缩，同时保持较低的内存开销，因为您只会加载当前正在播放的音乐。

Unity Addressables 迁移：我们从这里何去何从？

  我们几乎没有触及 Addressables 的皮毛。

  但是现在你的音乐作曲家有了一些新玩具可以玩。 这才是最重要的。

  在下一篇文章中，我们将迁移更多内容……怎么说呢，具有挑战性。 但我还没有破坏它。

  如果我引起了您对该主题的好奇，请查看我为您编写的 Unity Addressables 教程。

  到那时，如果您在下方发表评论并与社区分享您使用 Addressables 的经验，我将非常高兴。