这篇文章最初发表在 Plarium 官网上。

手游的技术和美学要求一直在提高，跟主机和 PC 游戏的水准越来越接近。声音设计要求也是一样的，但手机存在诸多技术限制。比如，默认构建的大小、音量高低、同时播放的声音数以及 CPU 负荷。如果声音系统设计得有问题，可能会影响手游的商店评分。因为算法会统计所有崩溃情形，并据此决定是否减少曝光机会。与其在诊断出这样那样的问题之后再对项目返工，不如从开发伊始就采用系统化的方法来制作声音。这样可以节省很多成本。

我叫伊利亚•戈戈列夫，目前在 Plarium 担任音频制作人。过去 10 多年来，我一直从事手游、电影、电视和在线广告的声音设计工作。我和同僚跟音频团队一起开发了很多 Plarium 项目。其中最广为人知的包括《RAID: Shadow Legends》和《Mech Arena》。在此，我想说说如何在不影响项目进度或玩家体验的前提下优化手游的音频内容。事实上，本文无论对内部或外包声音设计师还是独立开发者都有相当的参考价值。 

为什么要对手游的音频进行优化

手机不是游戏主机。它不像 PlayStation 或 Xbox 那样是专门为游戏设计的。作为开发者，我们必须适配各种各样的设备，而不是某一型特定的移动设备。如果没有针对手机对游戏进行优化，玩家就可能会获得不好的游戏体验，继而感到失望，转而做出别的选择。

为什么玩家会转投别的游戏？

• 游戏加载时间过长
• 游戏的安装包太大
• 游戏跑得慢或闪退
• 声音和画面不同步
• 声音太小或者太大（很烦人且影响游戏体验）

当然了，可能还有其他方面的原因。不过，本文只重点探讨那些声音优化会对最终结果产生影响的情形。

本质上来说，优化就是在各种可用资源（如 RAM、磁盘空间和 CPU 用量）之间不断求得平衡。

来源：音频设计师 Zander Hulme 撰写的《Unity Audio Import Optimisation》博文

上图对所有需要对手游实施优化的人都有相当的参考价值（包括技术美工和开发人员）。

设计难题：限制构建大小

App Store 和 Google Play 对默认构建大小的限制对手游的制作和开发模式产生了很大影响。目前，两家商店的限值均为 200 MB。在这篇关于针对 App Store 的手机应用大小及优化策略的文章中，市场营销专家乔纳森•费什曼 (Jonathan Fishman) 分享了以下研究成果：

在应用超过 200 MB 时，系统会显示关于应用大小的警告消息，而这会导致用户转化率下降 15-25%。

事实上，在涉及到数万甚至数十万玩家时，即使失败率比这还要低很多，开发者也会设法对游戏实施优化，并将构建大小控制在 200 MB 以内。

解决方案

尽早对游戏中所用的资源实施性能分析。事实上，在 Unity 中即使不用中间件也能做到这一点。为此，您需要提前了解即将发布哪些功能，预估默认构建中的声音所需的空间，然后借助工具来捕获所有这些信息。

Audiokinetic 的 Wwise Profiler 中显示某一时刻与声音相关的所有对象的层级结构。在此可以清楚看到资源的体量如何影响运行游戏的设备的性能（来源：audiokinetic.com）

根据我们的经验，音频素材至少要占默认构建总计大小的 10%。

这些对文件压缩的要求相当严格。对此，我们会做进一步的考虑。至于额外的内容，后续会以素材包的形式上传。

尽早构建音频内容层级结构。那么，如何在构建中分配有限的空间来容纳不同的音频内容呢？其各自的比例可能因类型而异。有时需要更多环境声，有时则需要更多界面音效、音乐、语音等等。所以，越早整理资源，越好推进游戏的开发，并预估新功能的体量。您可以基于既定的技术边界和现实的一些限制灵活地制定解决方案。

设计难题：资源压缩

您可以通过以下方式优化资源占比：

• 采样率
• 格式和品质

至于发展和演变过程，我们不做过多的探讨。在此，只要了解手机对采样率的设定就可以了。事实上，有两种最常用的媒体采样率：44,100 Hz 和 48,000 Hz。两种一直以来都在用，只不过用途不太一样。

CD 采用 44,100 Hz 格式，电影和有线电视则采用 48,000 Hz 格式。这两种格式对设备和服务的后续开发产生了很大影响。作为 MP3 播放器的换代产品，智能手机长期以来一直采用 44,100 Hz 格式。自 iPhone 6S 发布后，Netflix、YouTube 等流媒体服务以及大型电子游戏凭借 48,000 Hz 内容迅速盖过传统手机。

当手机在原生频率下运行时，若某些应用强制其播放其他频率的文件，设备应当快速转换文件频率 – 不过直接听听不出来。根据是将频率降到还是提到工作频率，我们相应地将之称为降采样或升采样。虽然通过降低素材的频率可在设备上节省空间，但同时也会加重 CPU 的处理负荷。正因如此，很多手机都改用了 48,000 Hz 格式 – 这样可以直接在原生频率下运行。

解决方案

根据 Google Developers 的建议，最好将所有内容保留设为 48,000 Hz，因为绝大多数手机都是在此频率下运行的。不过，这在现实当中是不可能实现的，因为一般情况下都要进行压缩。

若因采样率而需压缩素材以节省空间，不妨先试试 24,000 Hz 或 16,000 Hz。对于要对素材实施升采样的手机，将频率乘以二或三算是最简单的数学运算了。最适合做大幅度压缩的对象有 VO、环境声以及其他以噪声成分为主的声音 – 不过要仔细听有没有杂音。

能否不用这些解决方案？

可以，前提是对游戏的性能有充分的了解，并且可通过性能分析器确认转换为不同频率并使用更大的格式不会影响进程。另外，记住要坚持自己的创作理念为先。我们不一定要按照 Google 的建议来压缩所有内容。

压缩音频素材时最常用的格式

• ADPCM 会对素材进行线性压缩。文件大小将缩减至原来的三分之一。解包过程非常快，且不占用 CPU 资源。此格式尤其适合 UI。比方说，要在按下按钮之后快速做出响应。
• Vorbis 允许最大限度地压缩文件，但解压时会消耗更多 CPU 资源。要判断听到的结果是否达到预期水准，需仔细听声音有没有足够的时间解压。此格式设有一定的品质范围，不过我们得理解其中的含义：品质参数不决定压缩文件的品质，它决定的是压缩工具本身的品质。比如，Unity 将其值域定义为 1 ~ 100，Wwise 则将其定义为对数公式。这就是为什么品质可以是 0 或 -1。 

下面我们来听一段来自《RAID: Shadow Legends》近期更新的 VO：

示例：

• 原始文件：48 kHz PCM WAV – 1 MB
• 采样率压缩文件：24 kHz PCM WAV – 500 kB
• 添加有音乐的高品质压缩文件（最终收听效果）：OGG Vorbis (~q. 0.4) – 100 kB

如果不管前面 Google Developers 给的建议，我们还可以对自己的文件做进一步的压缩。比方说，可将文件压缩到 20 kHz，或采用 Vorbis 格式来降低其品质 – 不过，肯定不能有太多杂音。而且，还要兼顾音频内容的优先级及其重要性。

设计难题：RAM 优先级系统

手机针对各种操作构建了一套优先级系统。另外，还为一些被认为比游戏更重要的进程预留了大量内存（比如紧急通知、通话、健康应用等）。而且，用户多半会同时使用多个应用 – 比如，同时观看 Netflix、下载文件和使用即时通讯工具。

结论：我们永远无法在游戏中使用为手机指定的那么多内存。

所以，我们要在一定的限制之内进行操作，否则手机会尝试关闭所有低优先级的程序。

如何确定游戏在声音方面占用了多少内存？只需将场景中所有 SoundBank 的大小加在一起就可得到内存用量。场景或特定功能需要的全部保留，所有不必要的都进行严格的限制。比如，菜单、过场动画或已从内存中卸载的前一场景的声音。

为什么这很重要：

• 占用过多内存空间 = 帧率下降，游戏卡顿
• 占用过多内存资源（比如不控制 SoundBank 的加载和卸载）= 超出内存限制，导致发生崩溃；游戏进度丢失，玩家感到恼火，转投别的游戏

解决方案

明确目标设备并对其进行全面测试。

尽早实施性能分析，并预估每种场景和功能占用的内存大小。

创建很多小的 SoundBank – 比只创建一个大的 SoundBank 好。这种方法在刚开始的时候感觉可能比较麻烦，但后续可以避免在游戏中占用不必要的资源。

构建灵活的 SoundBank Trigger 系统。控制在哪些情形下从内存中加载或卸载 SoundBank。最好手动完成此操作，同时使用中间件（如 Audiokinetic Wwise）。跟 Unity Audio（运作机制相对隐蔽）不同，Wwise 允许控制游戏中每个声音的加载及生命周期。

使用流播放。并非 Spotify，而是一种基于磁盘的资源打包技术。藉此，在游戏中无需占用 RAM 就可解压文件。音乐、环境声和 VO 都可进行流播放。不过不要过度使用，这样可以节省内存，但会加重 CPU 负荷。

设计难题：实声部数受限

手机在同时对多个声音进行流播放方面存在限制。这些被称为实声部，其数量受到严格限制。这篇关于如何控制声部的文章建议将声部限制在 50 ~ 100 个。根据我们团队的经验，这是个很乐观的估值。

我们觉得同时存在 20 ~ 30 个声部就已经很勉强了。这么高的数值在 Android 和 iOS 上很容易出现故障。

假设你在开发一款三消游戏，场景中包含多个物体。比如，都是会爆炸的菠萝。为此，你将声音与素材逐一关联。不过，有时候会有 15 个菠萝。所以，要控制音量的大小，并限制物体的数量。事实上，同时播放 15 个声音太嘈杂了，而且会加重 CPU 的处理负荷。

解决方案

设置优先级。您需要根据声音的重要性构建层级结构。有些声音非常重要、绝对不能砍掉，即使超出规定的声部限值也要保留。相反，有些素材优先级比较低，达到临界限值便可舍弃。

比如，我们可以添加一个条件：不管场景中有多少个菠萝爆炸，玩家听到的爆炸音效都不超过三个。玩家只需要知道有多个菠萝爆炸就行了。而且，手机不能音量太大或同时运行过多相同的进程。

Audiokinetic 的 Wwise Profiler 中的声音层级结构看起来就像依次传给听者的实时事件队列

设置声部限值。限值可针对整个平台，也可针对特定的素材。在后一情况下，可选择引擎如何处理多余的资源。比如，停止播放原有资源，或不允许播放新的资源，直到实声部被放行。

基于平台和素材设置限值

在目标设备上做全面的测试。

分析统计数据。收集游戏会话日志非常重要，因为只有通过大量数据才能判定项目中存在的问题及其严重程度。其中包括内存用量、文件上传速度、崩溃情形等等。更何况，自己不做，商店也会做。如果其判定玩家弃坑是因为游戏崩溃或性能不佳，那么该游戏在商店搜索结果中的排名就会被下调。

设计难题：动态范围受限

相较于台式电脑、游戏主机和电视，手机在动态范围方面受到严格限制。对玩家来说，这意味着最安静和最响亮的声音之间的差别更小一些。音量的渐变更平缓，而且没有那么精细。

相较于台式电脑和游戏主机，开发者在为手机开发应用时需要将所有内容的音量调高一些，而且要做更大幅度的压缩。

解决方案

遵循 Sony 和 Google Developers 有关混音电平的建议（分别为 -18 LUFS 和 -16 LUFS）。不过，这只是一般性的建议。与 PlayStation 或 Xbox 不同，App Store 和 Google Play 都没有获得响度认证。即便未达到给定标准，验证也不会出现问题。

创建两套混音分别用于耳机和扬声器并动态地切换状态。就连 Unity 也为此内置了相应的工具 – Mixer Snapshot。在 Wwise 中，可创建一个独立的状态。同时，创建模板来为玩家使用扬声器时的状态做单独的设置，并添加触发器以便在玩家连接或断开耳机时切换状态。

测量游戏会话混音来大致了解跟建议标准的差距。录制真实游戏会话的视频（最好不短于 30 ~ 40 分钟），并使用免费插件（如 Youlean Loudness Meter）进行测量。这样可以清楚地了解游戏音量的高低。

结语

我在上面提到的所有技术阻碍都不应影响到游戏本身的创作。如果确定结果与创作理念一致，即便偏离标准也是可以接受的。

另外，要记住社区里总有志同道合的人可供寻求建议。专业社区对分享经验、学习知识和建立人脉非常重要。比如，乌克兰的音频设计师社区 Noise Shelter（目前在 Discord 上汇聚了 100 多名专业人士）。

各位也可以看看我的另一篇文章：《Game audio: an extensive text about working with sound in games》[仅提供乌克兰语版本]。这篇文章主要面向初学者以及对这一职业和相关工具感兴趣的人。

如果有什么想法和问题，欢迎大家在评论区留言。感谢各位为此抽出宝贵的时间！