文章目录
- 前言
- GPU性能优化
- 打包素材
- CPU性能优化
- 代码执行优化
- 性能测试
- Vector2.Distance 和 sqrMagnitude哪个好?
- 动画切换优化
- shader属性优化
- URP渲染器资产优化
- 对象池优化
- 删除没必要的空函数
- 图片、音乐音效、贴图等素材压缩
- ScriptableObject优化参数
- 参考
- 完结
前言
功能的实现必不可缺,当然也要注意程序性能的优化。随着项目越来越大,优化变得至关重要,它能确保你的游戏任然可以快速流畅地运行。如果想知道如何对unity进行性能优化以及如何进行性能测试,那就继续往下看吧。
GPU性能优化
打包素材
点击运行游戏,打开分析帧调试器
然后点击启用工具,逐步查看Unity如何将图像渲染到屏幕上,我们可以看到有五个绘制调用,分别是背景、地板、敌人、玩家和玩家的武器
如果我们可以使用更少的绘制调用来实现相同的结果,它肯定会更快,我们可以使用Sprite Atlas来做到这一点
把所有的资源都拖入,进行打包(注意这里属性和图片差不多,如果你是像素素材同样可以选择点类型,无压缩进行优化)
打包效果
我们再回去分析帧调试器查看,你会看到我们只有三个绘制调用
既然前面打包了,那么为什么不是一个呢,你可以看到它没有将敌人与玩家进行批处理,因为它们具有不同的材质
如果我们没必要使用不同的材质,我们可以选择把所有的材质换成一样的
这样的话,可以看到就仅仅绘制了一次,这明显加快了GPU绘制
CPU性能优化
代码执行优化
我们经常会有书写这样的代码,比如新增EnemyBehavior.cs脚本挂载在敌人身上,这里在Update中每一帧都调用敌人面向玩家等操作,但是这完全是资源的浪费,在播放模式下没有必要在每帧上都这样做
运行状态下,打开Profiler 分析器
只需单击图表上的任意位置,我们的游戏就会暂停,以便我们可以对其进行分析,可以看到目前EnemyBehavior的更新占用了1.2%CPU使用率
这时候我们可以选择使用脚本委托和定时器控制它的更新频率,比如新增Ticker脚本,没过0.2秒调用TickEvent方法
逻辑不在Update中调用了,注册委托每0.2s调用一次
可以看到敌人是仍然总是面向玩家,但不是每帧都运行该逻辑,运行频率被降低了,但它并没有对游戏中敌人的行为产生明显的影响
性能测试
但是当涉及到某些代码片段时,仅用这些王具很难判断出什么实际上性能更高,有时您只需要自己测试一些东西,所以让我向您展示如何设置基准测试,来让您运行自己的测试
新增性能测试的类
using UnityEngine;
using System.Diagnostics;
// 用于性能测试的类
public class BenchMarker : MonoBehaviour
{
[Range(0, 1000000)]
[SerializeField] private float _iterations; // 迭代次数
private BenchMarkTest _benchMarkTest; // 性能测试对象
private Stopwatch sw; // 计时器
// 在启动时获取BenchmarkTest组件
private void Awake()
{
_benchMarkTest = GetComponent<BenchMarkTest>(); // 获取BenchmarkTest组件
}
// 执行测试的方法
public void RunTest()
{
sw = Stopwatch.StartNew(); // 创建并启动计时器
for (int i = 0; i < _iterations; i++)
{
_benchMarkTest.PerformBenchmarkTest(); // 执行性能测试
}
sw.Stop(); // 停止计时器
UnityEngine.Debug.Log(sw.ElapsedMilliseconds + "ms"); // 输出测试时间
}
}
Vector2.Distance 和 sqrMagnitude哪个好?
在Unity中,Vector2.Distance 和 sqrMagnitude 都是用来计算向量之间距离的方法,但它们的性能特性略有不同。
新增脚本,这里距离判断我们使用了Vector2.Distance
,实际它的性能很差,因为它在内部计算中使用了开方运算 Mathf.Sqrt,开方运算通常比较昂贵,尤其是在大量计算时会消耗较多的计算资源。
点击测试
可以看到它平均需要执行390毫秒左右
我们现在换成性能更高的办法.sqrMagnitude
进行距离判断,sqrMagnitude 属性返回向量的平方长度,与Vector2.Distance 方法不同,sqrMagnitude 不进行开方操作,因此它的计算代价更低。
重新测试发现,平均快了几毫秒左右
事实证明,我们可以继续使用Vector2.Distance
进行距离计算,因为它的可读性更高且对性能的影响似乎可以忽略不计
动画切换优化
通常我们都是这样进行动画切换
测试效果
但是其实有更好的办法,其实Unity获取这个动画字符串后会在幕后对其进行哈希处理,所以之后我们可以通过只做一次来节省时间,所以在这里我们可以提前对动画字符串进行哈希处理
可以看到,节约了近30毫秒的性能
shader属性优化
我们也想给改变shader属性来执行相同的操作,比如这里实现更改敌人的材质的颜色
改变颜色
测试结果,可以看到大概需要610ms左右
让我们尝试同样对字符串进行哈希处理
结果,发现速度加快了将近一半
URP渲染器资产优化
在URP渲染器资产中,如果你不需要深度纹理(Depth Texture)或不透明纹理(Opaque Texture )可以将其关闭,因为这些纹理最终会根据您的相机所看到的内容绘制纹理的深度或不透明度。如果你关闭它们,最终会优化大量不必要的内存
对象池优化
但如果您进行了大量实例化和销毁操作例如,如果您有一个带有大量子弹的游戏,那么您将需要实现个对象池系统,参考:【Unity小技巧】Unity探究自制对象池和官方内置对象池(ObjectPool)的使用
删除没必要的空函数
如果你的脚本中有空函数,请删除它们,每个函数也会有一点开销成本,即使它实际上没有执行任何内容
图片、音乐音效、贴图等素材压缩
合理压缩素材会很大的减低我们的内存
比如先看看我的背景没有压缩,它是6.8MB
低质量压缩它是1.1MB
ps
:合理的使用压缩,确保它不会明显降低你的画面质量
ScriptableObject优化参数
不同的敌人实例之间更改这些变量,现在当我点击播放时,这些脚本中的每一个都将有自己的实例,并且在这些类实例中的每一个上这些变量将在内存中拥有自己的副本,并且对于这种情况完全是浪费
这里我们可以使用ScriptableObject
配置
这样我们就不会为这些变量的创建数十几个副本存放在内存中,它只是位于ScriptableObject上的一个副本,每个敌人都只指向该ScriptableObject的对象
即使你想要实现不同的敌人配置,你也只需创建另一个ScriptableObject的对象资产,绑定它并修改参数即可
参考
https://www.youtube.com/watch?v=kJ5I9md9NG4
完结
赠人玫瑰,手有余香!如果文章内容对你有所帮助,请不要吝啬你的点赞评论和关注
,以便我第一时间收到反馈,你的每一次支持
都是我不断创作的最大动力。当然如果你发现了文章中存在错误
或者有更好的解决方法
,也欢迎评论私信告诉我哦!
好了,我是向宇
,https://xiangyu.blog.csdn.net
一位在小公司默默奋斗的开发者,出于兴趣爱好,最近开始自学unity,闲暇之余,边学习边记录分享,站在巨人的肩膀上,通过学习前辈们的经验总是会给我很多帮助和启发!php是工作,unity是生活!如果你遇到任何问题,也欢迎你评论私信找我, 虽然有些问题我也不一定会,但是我会查阅各方资料,争取给出最好的建议,希望可以帮助更多想学编程的人,共勉~