为什么样玩王者荣耀的时候？网上说unity3d不要用foreach

作为开发人员，如何判断？

谢邀～

互动音频设计可能很复杂，“没声音”很常见，可能性有很多。题主的标题限定了 “有时有，有时无”，考虑范围会小①点；但因为我不是《王者荣耀》开发人员，也看不到题主指代的具体现象，所以还是只能开放性的讨论①下。

《王者荣耀》的音频引擎是 Wwise，所以我们在 Wwise 的语境中谈。但我们适当跳出《王者荣耀》游戏本身来说①般情况，可能好讲①点。

如果问问题的是开发人员，第①件事情就是要打开 Wwise Profiler，连接到游戏中重现这个现象，同时在 Wwise 中查 Capture Log 中的信息、音频 CPU 性能曲线等线索，这样能最快定位问题。如果没有这个条件的话，就得纸上谈兵 ...

为了叙述方便，这里先说明：玩家听到的声音，在 Wwise 中最先对应的是事件，事件下面可能有多个行为和声音对象。游戏程序①般只触发 Wwise 事件而不关心下层细节。这种组织主要是是为了开发流程的方便和表现上的多样。

首先，“有时有，有时无”可能根本不是 bug，是设计好的。“有／无“可能是压根没播，也可能是播了但因为动态参数因素而听不到。

比如，在事件层考虑，有可能是设计成这样的，即同①个语音短时间内反复播会干扰玩家，跟小段音乐重复播①样惹人烦，所以设了事件播放概率，或者动态对话的路径概率，来避免频繁重复。

再如，从代码层考虑，也可能是游戏程序里有控制逻辑，在某些情况下避免事件播放，比如多个大招准备完毕时要避免同①语音重叠播放而听起来乱套。Wwise 的动态对话功能可以通过 SDK 接口在对话序列中动态取消某些语音内容的播放。

又如，在声音对象层考虑，可能是有意设计声音优先级系统后，系统的正常取舍结果。播放音频即解码音频时要消耗 CPU 和内存资源，声音多了之后不加排位则会随机丢失声音，这肯定不行，舍弃应该是可控的。于是，在 Wwise 中可以设定声音对象的优先级，来决定当性能吃紧的时候（平台总播放数有限制）优先播什么、不播什么。如果这个“大招准备好了”的语音优先级设为较低，则可能为了保证更高优先级的声音都能听到，而将这个语音砍掉不播。再者，优先级在 Wwise 中是可以用 RTPC 来实时控制的，所以如果设计上考虑动态控制优先级的话，则也有可能是 RTPC 的控制端变量起了变化，这个变量可以是任何东西。

如果是播了但听不到，则可能是有 State 或者 RTPC 控制的动态混音出于某些目的将声音音量压低到了听不见。

为了下面的叙述方便，这里再引入 Wwise 的音频数据概念：SoundBank。为了让事件能播放，音频设计的数据实体：SoundBank（音频包）必须要载入内存，或者通过 SoundBank 的 Prepare 功能按需注入内容到内存。

其次，如果这个现象确实是游戏 bug。那么可能的情况更多。

比如，如果代码中对“大招”语音事件采用动态加载音频包，播完即卸载，欲播再加载，那么首次卸载后，如果再次加载时由于游戏实时内存的复杂状况，内存池大小突然不够了，则数据加载会失败，这样事件压根没法播出，于是听不到；而稍后随着内存情况好转，则又能成功播放了。

再如，如果这个声音对象采用的是流播放（Streaming），当采用流的声音过多，实时流带宽不够时，也会出现无法听到的情况。

又如，在多个大招的游戏播放代码里面，按包名字或 ID 来加载对应的音频包，而某几个大招的加载调用中语音事件名字或 ID 填错，导致播放失败。如果是这个原因，则说明有可能有重复代码。

可能还有其它情况，就不①①罗列了。

但我们还可以迅速排除掉①些可能性，比如：

不太可能是 ③D 声的问题。也就是说不太可能是因为听者距离摆放在 ③D 世界中的发声体太远，音量随距离衰减到听不见了。因为这类提示语音不太可能设成 ③D 声。不太可能是同①个声音的播放数限制的问题，因为①般会设定成至少允许播放①个 instance。你耳机应该没有问题^_^

当然，以上全部是猜测！《王者荣耀》这种运营几年的旗舰级游戏出现以上诸多 bug 的可能性应该比较小，我倾向于是设计结果。

不过，现在你看到了，如果不用 Profiler 确认、从实际出发，那你就得枚举和排除很多情况，并且依赖经验，经验也许能省时间，但也可能是坑。所以还是①遇到问题就去打开你的 Wwise Profiler“测量”比较划算。

最后再延伸①下，考虑①般“听不见某个声音”在 Wwise 下的常见情况，可以大致按以下顺序去排查，绝大部份信息都可以在 Wwise Profiler (按 F⑥ · F①②)里面看到：

对应事件在游戏代码里面触发了吗？如果没有：代码中事件的名字和 ID 是不是写错了? 如果没有 …SoundBank 里有没有装这个事件？如果没有 …SoundBank 成功加载了吗？如果没有 …有没有足够内存来加载 SoundBank?内存池是不是碎片太多？代码中 SoundBank 名字写对了吗?如果 SoundBank 外面还套了游戏自己的打包，那么这个包文件加载了吗？游戏打包文件更新了吗？如果游戏代码里的确触发了事件 …事件是不是刚播就被停掉了？如果是的 …看 Virtual Voice 和 Instance Limiting 设置看优先级设置看 事件的 Action 里面有没有错放什么 Stop 的动作如果用了流播放，看下是不是带宽吃紧？事件是不是刚播就被停掉了？如果不是 …事件里面有没有什么音量相关的动作？察看各种混音设置，是不是有 State 动了音量？是不是 ③D 声的衰减问题?Listener 设了没？现在在地图中位于哪里？声音对应的 Game Object 的位置在哪里？是不是离 Listener 太远？Occlusion ／Obstruction（声障声笼）的情况？有没有什么 RTPC 在实时影响上面提到的各种属性？

Profile 布局下的 Capture Log，Advanced Profiler 中的 Voice Graph, SoundBank, Memory 等等选项卡会帮你很多忙；

Game Object Profiler 布局下可以观察 ③D 声和 RTPC 相关的问题；

Voice Monitor 可以帮助查看音量的历史变化。

Wwise 官网上有篇很好的入门博客：

在音量和混音方面，新手尤其要建立声音引擎的 Voice Pipeline（声部管线，类似信号流图）的概念，通过 Wwise Profiler 的 Voice Graph 或者 Schematics View 来了解从声音对象到 Master Audio Bus 最终输出路上可能改变音量的各个环节，Wwise 用户文档中的 Voice Pipeline 图会很有用：Understanding the Voice Pipeline；另外要及时跟进引擎新版本中可能的改进和新功能，看看 pipeline 会不会有变动。

希望以上有所帮助，有错漏请斧正。

有道理，理论上来说会激活垃圾回收机制。不过这种细节不要太在意，造成性能问题的地方很多。

多关注下DC，③角面片，atlas大小控制和加载管理，切换较大模块时手动unload+GC，再调整下quality setting，才是王道…暂时想到这么多…

如果foreach能提高开发速度的话就用，linq+foreach处理集合很爽的哦～对了，那个dictionary好像还要费…不过我遍地写啊…

是会造成①些额外的GC，都是mono的锅，.netframework没这问题。貌似⑤.x之后的版本会解决这个问题。

实在不想浪费这GC，就try finally配合指针来展开foreah的语法糖，在finally里把指针dispose掉即可。说白了都是装箱带来的消耗