大家可能不知道，Wwise 生态系统其实具有很强的可扩展性。有时，各公司要为其项目构建定制的插件，供应商会将自研插件迁移到 Wwise。对此，我们必然要提供相应的支持。新的 Wwise 版本很快就会发布。届时，我们将首次对原有系统实行全面改进。

在本系列博文中，我会探讨为 Wwise 构建插件的各种方案，并对新的 API 做简要的介绍。

• 第 I 部分：背景和目标
• 第 II 部分：插件剖析
• 第 III 部分：构建插件

第 I 部分：背景和目标

插件对 Wwise 来说至关重要。藉此，声音设计师可根据项目需要灵活运用各种效果器和音频源。目前，Wwise Launcher 中提供有很多可供选择安装的插件。除此之外，Wwise 内部还嵌入了二十多款捆绑插件。与此同时，音频社区用户也在不断为 Wwise 开发新的插件。

每个插件都包含两个部分：声音引擎部分（捆绑在产品的可执行文件中）和设计工具部分（允许根据自身需要进行设置）。

开发背景

在过去 15 年中，我们不断完善用来构建插件的系统，并与设计工具和声音引擎紧密集成。事实上，插件的结构和函数已被广泛地用于各种内部功能的构建。

这显然是一把双刃剑。一方面，它意味着系统紧密集成，所有路径都经过了优化。同时，也使得我们很难对内部结构进行必要的重构和修改。不过，虽然没有办法更改内部结构，但是并不妨碍统合插件接口，以此来实现版本之间的兼容。

这对声音引擎来说尚且行之有效，毕竟产品需要高效、快速地运行。但对 Wwise 设计工具而言就成为了一种负担，因为所有东西都要基于 Windows API 来构建。

时代变迁

我们的宗旨是能够支持所有平台，但设计工具端并没有做到这一点。对于声音引擎端，我们团队一直在为支持新的 SDK 和平台努力，同时设法向产品用户提供必要的修复和改进。要是觉得自己产品的支持矩阵庞大，不妨看看我们的编译机来对比一下！然而，对于设计工具端，多年来客户一直满足于 Windows 版本以及移植的 Mac 版本。

我们越来越清楚地认识到，接下来有必要着力加强跨平台兼容性。15 年前，我们最先为 Xbox 和 Windows PC 平台提供了支持。所以，直接选择与 Windows 紧密集成肯定会更容易一些。不过，这些年来，互联网越来越发达，游戏开始流媒体化，开发者转而使用 Linux 作为后端服务器。与此同时，智能手机操作系统被 iOS 和 Android 完全占据，Mac 重获昔日辉煌，成了首选的创作平台。有鉴于此，单一的平台代码库已经无法满足当下需求。

对编程语言来说同样如此：据 TIOBE 榜单统计，C++ 的使用率从高达 16% 降到了 6%，新的编程语言（如 R）不断涌现，Python 成了很多业内人士的不二之选。要知道，即便是使用 C++ 15 编写的代码在 C++ 17 中都不兼容。编程方法也是如此：曾几何时，Microsoft Project 的 Waterfall 管理法被奉为圭臬。目前 Scrum 开发法在很多公司的文化中根深蒂固，但单元测试法已然越来越受到青睐。另一方面，Apple 有自己的 CPU，但 Microsoft Visual Studio 可为 Apple 设备生成代码，甚至可在 Mac 上运行。几经思虑，我们最终选用了射线追踪法。毕竟，大部分用户的 CPU 都至少有四个核心。15 年中真的可以发生很多变化啊！

循序渐进

四年前，我们开始设法消除问题的根源，而不是仅仅着眼于表层的修复。不过，更改 12,000 个文件中的 220 万行 C++ 代码 (2017) 并不是件容易的事。这需要时间和投入。光是插件代码现在就包含了上百个函数，其中很多在第一个版本之后就没再碰过。在保证生产稳定性的前提下，所有改动都要慢慢落到实处，同时避免修复带来不良影响。

举个简单的例子：设计工具代码大多采用宽字符，也就是每个字符对应两个字节。这最终会反映到我们的插件中。另外，宽字符在 Windows 上为两个字节，而在 Mac 上是四个字节。所以，不同平台上的结果和代码是不一样的。在过去四年里，UTF-8 的优势越来越明显，并逐渐成为跨平台开发的标准选择。为此，我们开始将很多基础架构迁移到 UTF-8。这一改进在 2019.1 和 2019.2 版本中就已初见成效。当然，未来还有很长的路要走。

再来举个例子：原有的 WwiseCLI 可执行文件负责在后台运行整套图形界面，其目前仍允许使用现在的命令行来运行 Wwise。该图形界面与 Windows 紧密集成。经过两年的重构，其被分为了跨平台逻辑部分和 Windows GUI 部分。最终，我们在 2019.1 中对 WwiseCLI 实施了全面改进。现在其会运行整个逻辑部分，而不单单是命令行前端。不过我们并没有就此止步，而是选择了继续改进和更新代码，直到在 2019.2 版本中将其替换为了 WwiseConsole。 

新旧兼顾

在 2019.2 中，新插件的构建慢慢提上日程。在避免对用户产生不良影响的前提下，我们一边开发设计工具一边开始发布新一代插件。虽然插件都很简单，不过仍然值得欣慰！在收集有关稳定性的反馈时，我们发现基本上没什么反馈！这说明原有插件和新的插件之间并没有明显区别（甚至性能都差不多）。不过有些功能比较慢，而且全部都是桥接的。当然，这也意味着在插件中实现功能要容易很多，而且可以轻松提升 Wwise 设计工具的性能。

自 2019.2 以来，我们一直在同时为原有插件和新的插件提供支持。有必要的话，以后也会如此。

新的 API

未来展望

距离与设计工具一起构建的第一个插件版本已经有十五年多了。相信即便再过十五年，这个版本在 Wwise 设计工具中一样能用。确保长久适用才是最重要的，插件接口总是在变会很难办。

在其他各个方面，我们也是这么做的。

普遍适用

在 Wwise 支持的所有平台上，插件代码应该是完全一样的。不过，谁又能知道设计工具体验将来会如何演变呢？在启动跨平台项目的时候，我们想保留原生的 Mac 和 Windows 可执行文件，希望能尽快构建相应的图形界面。最初，我们觉得不妨构建一个没有图形界面的版本。在获得初步结果之后，发现早期采用者希望在 Linux 上也能生成 SoundBank。除此之外，最好能更加紧密地集成到 Unreal 和 Unity 中，并通过命令行、无外设 WAAPI 服务器提高生成效率。不过，手持设备的功能会不断增强，谁也不知道以后到底会怎样。

活用语言

正如前面所说，C++ 只是插件开发当中可用的众多语言之一。如今，越来越多的人希望能够使用多种编程语言来构建插件。随着 2021.1 的发布，我们甚至会针对声音引擎提供使用 Python 运行的示例代码！因为，我们不希望插件受到限制。“插件应当选用最适合的语言来构建”，这一点对 C++ 和其他语言来说依然适用。

为此，新的设计工具插件采用了 C 基础架构，无论是在 ABI 还是 API 方面都很稳定。即便是对于新的版本，不管插件采用哪种语言构建，整个接口都能确保稳定性。借助现代化元编程桥接技术，我们可以轻松而高效地构建 C++ 插件。

简化用例

为了使功能得到扩展，声音引擎插件不可或缺。不过，最好能避开设计工具端来构建整个插件。实现方法有好几百种，关键在于通过构建管线尽量简化用例。

向后兼容

显然，如果想对插件实行所有这些改进，插件供应商肯定要做大量的工作。不过，我们会尽可能地做到无缝过渡。这也是我们保留原有插件的原因：虽然不是最好的选择，而且插件无法跨平台兼容，但至少只需使用最新的 2021.1 SDK 便可重新编译插件，而且直接在 Windows 上就能运行。

对今后的版本来说也是如此：只要设置所需的 SDK 版本，并使用最新版本来向后编译，即可确保接口尽可能地兼容。

由于向后兼容最终会成为负担，这些临时桥接肯定是要移除的。但是只要不引发问题，我们会一直提供支持。

首先要移除的是原有桥接，因为其不支持跨平台兼容。不过对 2021.1 来说，并不需要任何修复。

灵活扩展

因为代码会继续使用并在版本之间过渡，所以我们要逐步对接口实施各种改进（比如添加、修改和移除）。举个非常简单的例子：在 2021.1 中，目前尚无可用的跨平台 GUI，因为我们准备先对设计工具做调整。另外，有些插件类型（如转码和分析插件）理论上可由第三方供应商来做，但是这些目前还无法实现。

充分测试

如此多的变动可能会引起恐惧、不安和怀疑。多年的努力实属不易，我们只想把事情做好。不妨把 Wwise 设计插件工具部分当做其他插件的试金石。没准儿我们会在此基础上对声音引擎实施改进。不是没有这个可能。

大家可能不知道，Wwise 生态系统其实具有很强的可扩展性。有时，各公司要为其项目构建定制的插件，供应商会将自研插件迁移到 Wwise。对此，我们肯定要提供相应的支持。新的 Wwise 版本今年稍后就会发布。届时，我们将首次对原有系统实行全面改进。