百分之八十的性能消耗其实来自于百分之二十的代码——没错,就是经典的二八原则。
主要性能优化中必须处理的模块:图形、物理、程序、文件等,以及一些用于性能优化的工具。
CPU:
- 过多的DrawCall
- 复杂的脚本或者物理模拟
像素处理:
带宽:
- 尺寸很大未压缩的纹理
- 分辨率过高的framebuffer
脚本优化
1、性能敏感的使用场景下,频繁的调用函数例如update
2、避免在update中进行字符串操作
3、尽量不要用foreach,迭代器影响GC性能
4、递归的使用:尾递归>头递归
代码性能调优:
- 避免频繁setActive
- Tansform子类过多时候避免频繁操作transform
- 避免频繁Log
- 避免频繁的Find、GetComponent
代码内存调优
内存的优化最多还是在资源以及渲染上面,所以在代码这方面可能会相对欠缺一些,因为C#本身托管的属性,所以代码内存泄露的情况比较少。
资源优化
- 一些不常用的资源在第一次使用的时候再进行加载
- 一些场景中,直接加载了该场景所有的资源,有些资源用到时候再加载
- 用不到的对象置空
资源优化
贴图优化
游戏中暂时用不到,TODO
- 使用图集
- 通用纹理使用九宫格\减少纹理大小
- 透明物理造成大量的Overdraws,应该尽量避免
- 图片压缩到看不出的程度
- 关闭图片的read&write选项,否则内存大一倍
- 降低图片的色阶来减少图片的大小
- 如果我们使用的贴图不需要这样效果的话,就一定要把Generate Mip Maps选项和Read/Write Enabled选项取消勾选!因为Mipmap会十分占内存!
模型优化
- 将没有动画的模型上的动画脚本去除
- read/write Enabled关掉
音频优化
- 比特率调低
文本文件优化
文本转成二进制,可提高读写速度
Assetbundle管理
- FairyGui的细力度,如果Bundle的细粒度超过一定数量的话必然会引起热更包体积过大,玩家的更新需要下载更多的资源包,过小细粒度则会造成场景加载的缓慢,给管理上也会增加难度
- 将公用的资源单独打成包
- 当手机的容量较小时,可以通过WWW.LoadFromCacheOrDownload来进行加载,而不必担心内存不足的问题。
- 当在一个地方需要用到包中的一小个资源,例如一个2048*2048图集中的一个小icon。拷贝一份,并且放入到目前需要使用的包中,避免由于小的资源需求而引入大内存消耗。
资源工作流管理
如果没有好的工具链,好的流程,我们必定将会困在永远做不完的资源管理中。
逻辑架构:模块化,可做优化处理
物理优化:如果游戏物理更新频率不需要太高,可以在菜单 Project Settings -> Time 下更改Fixed TimeStep的值。
Profiler window的使用
Deep Profile:所有函数点用都被记录下来,会话费很大的开销
可用使用Profiler.BeginSample(name)和Profiler.EndSample脚本函数来启用和禁用代码段的分析。
-远程分析 Remote Profiling
-帧率:profiling工具可以显示在给定的帧在每个任务花费多长时间。
造成性能问题的原因:
- 排除垂直同步
- 点击检测,只在一个层做click响应
- 滤镜慎用 影响dc
- 列表优化 同一个列表分成3个列表进行展示
我们资源的加载方式:WWW的assetBundle就是内部数据读取完后自动创建了一个assetBundle