场景检测：Audio Listener、RigidBody和Prefab连接
source link: https://blog.uwa4d.com/archives/UWA_Pipeline33.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
在上一期《场景检测：雾效、Canvas和碰撞体》中，我们依托本地资源检测中和场景检测相关的规则，把涉及到的知识点跟大家进行了简单的讲解。这些看似细小的知识点，很容易在大家的开发和学习过程中被疏忽，而长期的问题积累最终都会反映到项目的性能表现上。为此，我们将这些规则列出，并且以一个个知识点的形式向大家逐一解读。
本期，我们将继续聚焦场景相关的检测规则：“挂载多个AudioListener的物体”、“检测场景物件与Prefab的连接是否正常”和“挂载RigidBody的静态物体”，我们将力图以浅显易懂的表达，让职场萌新或优化萌新能够深入理解。
1、挂载多个AudioListener的物体
这里涉及到的其实是Unity的音频播放的相关知识。这里我们来简单讲一下AudioSource组件和AudioListener组件。
AudioSource组件，主要是用于音频的播放。它可以对音频进行诸如播放情况、音量、混合以及播放速度等多种设定。形象点讲这就是Unity场景中的DJ化身。
Audio Listener一般用于音频的收听。Audio Listener就是我们在场景中的“耳朵”，没有它的话，我们是听不到场景中任何声音的。AudioListener组件没有属性设置界面，它只服务于“收听音频”这么一件事，是一个“存在即合理”的组件。
Audio Listener一般都挂载在摄像机上，而且这也比较符合逻辑：随着镜头视野的移动，我们能动态接收到相关范围内的音频讯息的变化。Unity官方文档中提到：每个场景只能有1个Audio Listener来合适地工作。这是因为：在同一时刻，即使有多个物体上有多个Audio Listener，也只能有1个起作用。我们不排除由于特殊需求，在不同位置的不同物体上都挂载Audio Listener，或在不同时刻启用不同的Audio Listener来实现3D音效的情况。但是一般情况下，在同一个物体上挂载多个Audio Listener大概率是没有意义的。因此，本条规则检测出的即为场景中同一个GameObject上挂有多个Audio Listener的情况。
开发团队可以对本条规则排查出的物体进行检查，以规范场景中对Audio Listener这一组件的使用。
2、检测场景物件与Prefab的连接是否正常
Prefab，即预制体，这是Unity中最常见的资源类型。在Unity场景里，我们经常会涉及到大量相同或者相似对象的使用与管理。比如批量修改资源属性设置，以及修改属性时不改动相关的资源的单独设置，对Unity而言，Prefab就非常适合处理这些情况。最常见的例子就是MMORPG游戏中的刷怪点。
当我们修改原始Prefab资源时，所有由它而来的Prefab实例都会同步修改并应用对应的设置，而且不会改动具体实例的特殊化设定。比如修改Prefab资源里的野狼，把皮肤颜色由棕色换成银白，那么所有野狼刷怪点的狼都会变成银白色，但精英刷怪点的野狼身上的火焰特效会继续存在。
而当派生的Prefab实例与原始Prefab的连接处于中断状态的话，这种对原始Prefab资源的修改就无法同步到这些出问题的实例上。比如一群银白雪狼里却有几只灰狼突兀地夹杂在刷怪点里，那么整个场景的和谐感都会被破坏掉。
本条规则将GameObject与Prefab的Missing或Disconnected两种状态都视为“连接不正常”，典型的Missing出现在GameObject对应的Prefab被删除的情况下，而Disconnect会由项目对Unity版本的升级等原因造成。当遇到类似情况时，我们建议研发团队要么将GameObject与Prefab之间的关系彻底解除（Unpack），要么将两者之间的连接关系重新恢复，以规范项目的开发。
3、挂载RigidBody的静态物体
在上一篇《场景检测：雾效、Canvas和碰撞体》中，我们简单介绍了碰撞体的概念，而在项目的实际开发中，Collider和RigidBody往往是配合使用的。
如果说碰撞体组件使得场景中相关物体去遵守“物理法则”，那么RigidBody组件则赋予了相关物体对应的“物理属性”。
我们可以在RigidBody组件上为物体设置各种属性，例如质量、阻力、重力生效与否、运动学规律生效与否等多种基于现实物理规律模拟的属性设定。
在真实世界里，物理规律对万事万物都有影响；但在Unity项目场景中，出于场景实际需求和项目性能限制，很多场景元素其实不需要拥有物理属性，就比如作为不可动的地形元素石头、树木等，加了重力，摩擦力等属性不仅不会提升场景的拟真效果，反而会造成不必要的性能消耗。对于这类不需要具备运动属性的物体，我们可以勾选“Static”，Unity Editor会对静态物体的某些信息进行预计算（如静态合批）。
如果开启了Static的GameObject上挂载了RigidBody组件，那么不但会造成不必要的物理开销，还会产生一些意外的运动效果。所以当本条规则检测出这些带有RigidBody的Static物体后，开发团队进行进一步的检查和判断，然后就可以果断删除相关静态物体的RigidBody组件，以降低不必要的计算开销。
希望以上这些知识点能在实际的开发过程中为大家带来帮助。需要说明的是，每一项检测规则的阈值都可以由开发团队依据自身项目的实际需求去设置合适的阈值范围，这也是本地资源检测的一大特点。同时，也欢迎大家来使用UWA推出的本地资源检测服务，可帮助大家尽早对项目建立科学的美术规范。
万行代码屹立不倒，全靠基础掌握得好！
性能黑榜相关阅读
《那些年给性能埋过的坑，你跳了吗？》
《那些年给性能埋过的坑，你跳了吗？（第二弹）》
《掌握了这些规则，你已经战胜了80%的对手！》
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK