在上一期《场景检测:雾效、Canvas 和碰撞体》中,我们依托本地资源检测中和场景检测相关的规则,把涉及到的知识点跟大家进行了简单的讲解。这些看似细小的知识点,很容易在大家的开发和学习过程中被疏忽,而长期的问题积累最终都会反映到项目的性能表现上。为此,我们将这些规则列出,并且以一个个知识点的形式向大家逐一解读。
本期,我们将继续聚焦场景相关的检测规则:“挂载多个 AudioListener 的物体”、“检测场景物件与 Prefab 的连接是否正常”和“挂载 RigidBody 的静态物体”,我们将力图以浅显易懂的表达,让职场萌新或优化萌新能够深入理解。
这里涉及到的其实是 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 这一组件的使用。
Prefab,即预制体,这是 Unity 中最常见的资源类型。在 Unity 场景里,我们经常会涉及到大量相同或者相似对象的使用与管理。比如批量修改资源属性设置,以及修改属性时不改动相关的资源的单独设置,对 Unity 而言,Prefab 就非常适合处理这些情况。最常见的例子就是 MMORPG 游戏中的刷怪点。
当我们修改原始 Prefab 资源时,所有由它而来的 Prefab 实例都会同步修改并应用对应的设置,而且不会改动具体实例的特殊化设定。比如修改 Prefab 资源里的野狼,把皮肤颜色由棕色换成银白,那么所有野狼刷怪点的狼都会变成银白色,但精英刷怪点的野狼身上的火焰特效会继续存在。
而当派生的 Prefab 实例与原始 Prefab 的连接处于中断状态的话,这种对原始 Prefab 资源的修改就无法同步到这些出问题的实例上。比如一群银白雪狼里却有几只灰狼突兀地夹杂在刷怪点里,那么整个场景的和谐感都会被破坏掉。
本条规则将 GameObject 与 Prefab 的 Missing 或 Disconnected 两种状态都视为 “连接不正常”,典型的 Missing 出现在 GameObject 对应的 Prefab 被删除的情况下,而 Disconnect 会由项目对 Unity 版本的升级等原因造成。当遇到类似情况时,我们建议研发团队要么将 GameObject 与 Prefab 之间的关系彻底解除(Unpack),要么将两者之间的连接关系重新恢复,以规范项目的开发。
在上一篇《场景检测:雾效、Canvas 和碰撞体》中,我们简单介绍了碰撞体的概念,而在项目的实际开发中,Collider 和 RigidBody 往往是配合使用的。
如果说碰撞体组件使得场景中相关物体去遵守 “物理法则”,那么 RigidBody 组件则赋予了相关物体对应的 “物理属性”。
我们可以在 RigidBody 组件上为物体设置各种属性,例如质量、阻力、重力生效与否、运动学规律生效与否等多种基于现实物理规律模拟的属性设定。
在真实世界里,物理规律对万事万物都有影响;但在 Unity 项目场景中,出于场景实际需求和项目性能限制,很多场景元素其实不需要拥有物理属性,就比如作为不可动的地形元素石头、树木等,加了重力,摩擦力等属性不仅不会提升场景的拟真效果,反而会造成不必要的性能消耗。对于这类不需要具备运动属性的物体,我们可以勾选 “Static”,Unity Editor 会对静态物体的某些信息进行预计算(如静态合批)。
如果开启了 Static 的 GameObject 上挂载了 RigidBody 组件,那么不但会造成不必要的物理开销,还会产生一些意外的运动效果。所以当本条规则检测出这些带有 RigidBody 的 Static 物体后,开发团队进行进一步的检查和判断,然后就可以果断删除相关静态物体的 RigidBody 组件,以降低不必要的计算开销。
希望以上这些知识点能在实际的开发过程中为大家带来帮助。需要说明的是,每一项检测规则的阈值都可以由开发团队依据自身项目的实际需求去设置合适的阈值范围,这也是本地资源检测的一大特点。同时,也欢迎大家来使用 UWA 推出的本地资源检测服务,可帮助大家尽早对项目建立科学的美术规范。
万行代码屹立不倒,全靠基础掌握得好!
相关推荐
性能黑榜相关阅读
《那些年给性能埋过的坑,你跳了吗?》
《那些年给性能埋过的坑,你跳了吗?(第二弹)》
《掌握了这些规则,你已经战胜了 80% 的对手!》