产品与解决方案 Prefab 优化:预制体中的各种细节选择

侑虎科技 · 2020年12月21日 · 1154 次阅读

在上一期《Shader:优化破解变体的 “影分身” 之术》中,我们针对 UWA 本地资源检测最新的Shader Analyzer功能所涉及到的新规则和相关知识点进行了讲解。这些看似细小的知识点,很容易在大家的开发和学习过程中被疏忽,而长期的问题积累最终都会反映到项目的性能表现上。为此,我们将这些规则列出,并且以一个个知识点的形式向大家逐一解读。

本期,我们将继续讲解 UWA 本地资源检测中和 Prefab 相关的规则:“使用了 Outline 的 Text 组件”、“使用了默认纹理的 RawImage 组件”、“不可见的 RawImage 组件”、“开启 Prewarm 的粒子系统” 和 “开启 Collision 或 Trigger 的 ParticleSystem”。我们将力图以浅显易懂的表达,让职场萌新或优化萌新能够深入理解。


1、使用了 Outline 的 Text 组件

这里有两个概念需要和大家简单说明下。首先是 Text 组件,它是 UGUI 系统下的一个可以用于文本显示与编辑的控件。

在 Text 控件中我们可以对文本内容进行多种设置,比如字体类型、字体大小和对齐方式等。

然后是 Outline 组件。Outline 组件和 Shadow 组件一般都用于对图片或者文字添加阴影效果。而且从形式上看,这俩基本没有区别。

而从效果上来看如下图,Outline 用于添加轮廓效果 ,Shadow 则是用于添加阴影效果;从性能上来看,Outline 生成的网格 Triangles 会比 Shadow 多。

而且根据实际测试,如下图是一段文本分别在 “无阴影效果”、“开启 Shadow” 和 “开启 Outline” 时的顶点数情况。由图可知如果我们在 Text 组件中使用了 Outline 来实现轮廓效果,那么顶点数和网格数的上升会非常明显。

在这里我们推荐大家尝试使用 TextMeshPro 来实现相关的显示效果,在性能和展示效果上都优于 Outline 和 Shadow。

所以在本条规则找出使用 Outline 的 Text 组件后,开发团队可视实际情况去选择是否保留 Outline,或者换用 TextMeshPro;也可以让美术人员直接做出美术字来使用,从根源上减少顶点数,降低性能开销。

2、使用了默认纹理的 RawImage 组件

在之前《Prefab 优化:向预制体打出最有效的组合拳》一文中,我们简单说明了 Image 组件。Rawlmage 组件和 Image 组件类似,都是 UGUI 系统下的图像组件。针对于 Texutre 设置的 TextureType 来说,Image 组件只能使用 TextureType 为 Sprite 类型的资源;而 RawImage 使用的纹理资源可以设置为任意 Type,需要注意的是,如果在 RawImage 组件内拖入的是 TextureType 为 Sprite 的纹理,其实是引用了 Sprite 内的原始纹理。从 UGUI 源码中看,RawImage 类型的 API 函数很少,功能比较简单,而 Image 类型的功能较复杂。

如果 Rawlmage 组件的 Texture 属性没有赋值,那么会生成一张白色的默认纹理,这张白色的纹理存在性能开销。虽然不排除直接使用默认纹理的情况,但大部分的应用场景下,我们都会为 Rawlmage 组件添加符合场景和界面需求的纹理来达到预期的显示效果。

所以我们会找出这些使用默认纹理的 Rawlmage 组件,以供开发团队进行进一步的判别,方便大家及早发现并修改这类纹理使用不当的问题。

3、不可见的 RawImage 组件

这一条和我们在之前的文章《Prefab 优化:向预制体打出最有效的组合拳》讲到的 “不可见的 lmage 组件” 非常相似。在大部分的应用情形下,“视觉上消失,但物理上存在” 背离了作为图像组件的使用初衷。

当我们把 Alpha 值全为 0(即透明不可见)的 Texture 资源导入到相关 RawImage 组件后,这种情况下,Rawlmage 图像组件不仅没有为项目提供任何的展示效果,反而为项目带来了性能和计算上的额外占用与消耗。

当然,还是要强调一下,我们不能武断地排除 RawImage 组件不可视化的特殊应用,开发团队要根据项目的实际需求来进一步判断这些被本条规则筛选出的 Rawlmage 组件。

4、开启 Prewarm 的粒子系统

在 Unity 的粒子系统应用中,我们经常会接触到一个叫做 “预热”(Prewarm)的概念。我们可以在粒子系统的初始化面板内进行 Prewarm 的相关设置。

开启 Prewarm 选项后,粒子系统会在加载后立刻执行一个完整的粒子发射周期,一般用于特定的粒子效果的展示需求。

最典型的就是火焰特效的应用,在某些场景过场中,例如战乱中一间燃烧的木屋。开启 Prewarm 选项,我们就能直接看到熊熊燃烧的大火,而不是看一遍火焰从小烧到大的过程(不然这就违和得离谱)。

在一些粒子系统渲染规模较大的场景中,如果开启 Prewarm 选项,会使得粒子系统在使用时的第一帧产生相对集中的 CPU 耗时,那么很可能会造成运行时局部卡顿,从而对整个项目的运行过程产生感官和体验上的明显影响。

所以本条规则会找出这些开启 Prewarm 的粒子系统,开发团队进行进一步的检查后,根据实际使用需求去决定是否需要关闭相关的粒子预热效果。

5、开启 Collision 或 Trigger 的 ParticleSystem

在 Unity 中,粒子系统一般用于各种渲染效果,不具备实物特性。但在某些具体的应用中,我们希望粒子具有现实中的物理性质来更好地表现想要的效果。

比如在某些二战题材的军事游戏内,用粒子系统去表现 M16 防空车的弹幕射击。为了更好地实现曳光弹、燃烧弹的射击,碰撞和四散的效果,这时候就需要开启粒子系统的物理碰撞。

如图,这是粒子系统中的 Trigger(触发器)和 Collision(碰撞器)设置。简单来讲,合理使用这两个设置,就能很好地模拟出粒子的实物碰撞效果。甚至可以实现比如子弹跳弹后的变轨,雨水滴到湖面后的反弹等现实的物理性质。

不过这些物理碰撞效果的实现是以高额的物理计算消耗为代价的。在实际使用中,大部分的粒子系统只是承担了渲染的作用,并不涉及粒子与物体碰撞的效果反馈。所以在这种情况下,开启 Collision 或者 Trigger 并不会使得原有渲染效果有显著提升,反而会带来相当大的性能负担。

所以本条规则会找出这些粒子系统,以供开发团队检查,在确认当前 ParticleSystem 不需要实现物理特性后,开发团队就可以果断关闭相关属性设置以减小项目的性能开销和计算压力。

希望以上这些知识点能在实际的开发过程中为大家带来帮助。需要说明的是,每一项检测规则的阈值都可以由开发团队依据自身项目的实际需求去设置合适的阈值范围,这也是本地资源检测的一大特点。同时,也欢迎大家来使用 UWA 推出的本地资源检测服务,可帮助大家尽早对项目建立科学的美术规范

万行代码屹立不倒,全靠基础掌握得好!

相关推荐
《UWA 本地资源检测又更新|帮你把关 Shader 变体问题》

性能黑榜相关阅读

《那些年给性能埋过的坑,你跳了吗?》
《那些年给性能埋过的坑,你跳了吗?(第二弹)》
《掌握了这些规则,你已经战胜了 80% 的对手!》

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册