首页 > 代码库 > [Unity优化] Unity CPU性能优化 (难度3 推荐4)

[Unity优化] Unity CPU性能优化 (难度3 推荐4)

http://www.cnblogs.com/chwen/p/4396515.html

 

  前段时间本人转战unity手游,由于作者(Chwen)之前参与端游开发,有些端游的经验可以直接移植到手游,比如项目框架架构、代码设计、部分性能分析,而对于移动终端而言,CPU、内存、显卡甚至电池等硬件因素,以及网络等条件限制,对移动游戏开发的优化带来更大的挑战。 

  这里就以unity4.5x版本为例,对Unity的优化方案做一个总结,有些是项目遇到的,也有些是看到别人写的不错拿来分享,算作一个整理,后期也会持续更新。本优化从CPU、GPU和内存三个方面着手总结,这一篇先从CPU说起,整理一些针对CPU相关的优化建议。

  对CPU的优化主要是从drawcall、物理组件、GC(垃圾回收)、脚本等几个方面开展。

  1. Drawcall 的优化
  • 什么是Drawcall? 

  Drawcall是CPU向GPU发送绘制命令的接口调用。理论上每一个不同材质的物件需要渲染在屏幕上时,CPU都会调用图形API ( openGL or Diract3D ) 的Draw接口触发显卡进行绘制。

  • 为什么优化Drawcall?

  Drawcall对硬件和驱动而言,要求大量设置状态(使用哪些顶点、哪些shader等)和状态转换。而Drawcall最大的消耗在于:如果每次drawcall只提交少量的数据将导致CPU瓶颈,CPU无法将GPU填满。Drawcall对GPU的耗费在于硬件一直等待CPU提交数据,而无法得到有效利用。GPU大量的时间耗费在不断切换状态和正确性检测上。 GPU在Draw Call之间,为了防止前后Draw的依赖关系造成绘制错误或者资源竞用,一般会在Draw Call后Flush整个流水线,小粒度的Draw Call对GPU流水线来说是个很大的浪费。(这个问题在D3D老版本存在,在新版D3D11中得到改善。)实际上unity官方指出,Drawcall数量的降低并非重点,重点是减少批次的数量,Drawcall优化实际上是对批次数量的优化。 
  延伸阅读:
  · why are draw calls expensive? — Stack Overflow
  · Direct3D Draw函数 异步调用原理解析

  • 如何优化Drawcall?

  在Unity中对Drawcall的优化有以下几个策略:Drawcall batching,合并打包图集,减少光照和阴影以及遮挡剔除和视锥剔除等。以下分别谈一下各个策略的优缺点。

  1.1. Drawcall Batching

  Unity中对Drawcall的批次有两种:静态批次(static batching)和动态批次(dynamic batching)。但不论静态批次还是动态批次都要求对象的材质是共享的,即不同材质的对象是无法进行批次的。而且要注意的一点:如果在脚本中调用材质时,使用Renderer.material会造成材质的拷贝,而使用Renderer.sharedMaterial来调用则不会拷贝材质。

  1.1.1. 静态批次 Drawcall static batching

   场景中的多个物件如果是不移动的(包括位置、缩放、旋转等),并且共享同一材质,比如地形、建筑、花盆等,那么可以选择采用静态批次。静态批次只需要在Inspector勾选static选项即可。静态批次需要注意的是,unity会将进行批次的多个对象合并成一个大的对象,也会导致内存损耗,有时候要避免太多对象静态批次造成的内存过高。这也表明,优化并非绝对做好某一方面,而是平衡各个硬件的瓶颈和效率,选择相对适中的方案。

  1.1.2. 动态批次 Drawcall dynamic batching

  动态批次是运动的物件在unity中也可以进行批次渲染,动态批次不需要手动设置,是unity自动进行的,但是这里有诸多陷阱和约束,开发者需要遵守一定的限制条件才能享受动态批次的好处。

  根据unity官方文档描述:

  1) . 动态批次是逐顶点处理的,因此仅对少于900个顶点的mesh有效。如果shader使用了顶点位置,法线和UV那么仅支持低于300顶点的mesh,而如果shader使用了顶点位置,法线、UV0、UV1和切向量,则之多仅支持180顶点。

  2) . 缩放问题

  缩放对于批次是有影响的,这里涉及到一个统一缩放和非统一缩放的概念。统一缩放即为三轴同比例缩放,比如(1,1,1),(2,2,2)(5,5,5)... 非统一缩放即为三轴不同比例缩放,如(1,2,1)(2,1,1)(1,2,3)等等。

  Unity对统一缩放的对象是不进行动态批次的,而对非同一缩放的对象是可以进行动态批次的。这里有点诡异,查阅了一些资料,解释如下:

  对于非同一缩放的物件,unity将其mesh进行了复制,因此即便是从相同物件进行的非同一缩放的两个对象是两份mesh;对统一缩放的对象来说,unity不对mesh进行复制,而是使用同一mesh进行缩放,此时复制mesh来进行批次渲染是不值得的,但是对于非统一缩放的对象,既然已经复制了mesh(不是为了批次,而是其他原因决定复制mesh),那么进行批次是顺带实现的。

   (参考 Dynamic Batching and Scale ——unity3d answers  )

  3) . 使用了不同的材质,即便实质上是相同的(比如两个一模一样的材质),也不会进行批次。

  4) . 拥有lightmap的物件含有额外的材质属性,比如lightmap偏移和缩放系数等,所以拥有lightmap的物件不能批次。

  5) . 多通道的shader会妨碍批处理操作,接受实时阴影的物件无法批次。

  

  注意: unity渲染是有顺序的,渲染排序有可能打断动态批次。

  例如:

  场景中有物件ABC,假设AB使用同一材质1,C使用材质2.那么drawcall有可能是2个,也有可能是3个。

  如果顺序为: 

    1.渲染A,使用材质1 

    2.渲染B,使用材质1 

    3.渲染C,使用材质2

  那么drawcall是2个,AB进行了动态批次。

  如果顺序为:

    1.渲染A,使用材质1 

    2.渲染C,使用材质2 

    3.渲染B,使用材质1

  那么drawcall就是3个,AB的批次被C打断了。

渲染顺序跟什么有关呢?

    首先根据物件到摄像机的距离,进行远处物件先渲染近处物件后渲染。相同材质的物件尽量在一层,不要让不同材质的物件进入这一层。如果无法保证这一点,那么还有一种方法:修改shader中渲染队列值。即打开shader 将subshader中的tag{}中queue 修改为小于2500的值。

   渲染队列小于等于2500时,unity认为其是不透明的,对于不同材质但z值相同对象,unity不对其进行排序,这样能保证相同材质的多个对象能是一个批次,不同材质的对象如果进入两个相同材质的对象之间,不会打破批次;

    渲染队列大于2500时,unity会对不同材质的对象进行排序,此时如果不同材质的对象进入到两个相同材质的对象之间的话,会使相同材质的对象批次被打破。

  批次先写到这,其实很多网上都有,不过有些没深入讲解,也有些没给出解决办法,我就使用每个方案时遇到的困难给出了自己的解决方案。其实批次还有不少研究的地方,之后想到了会继续更新。

  延伸阅读:   

  · Unity -Draw Call Batching 

  · Unity Drawcall 优化手记 

 

      1.2. 合并图集

  其实合并图集也是利用了Unity的Drawcall batching。将多个纹理进行打包成图集是为了减少材质,这样多个对象共享一个材质,并进而使用同一个纹理和shader,触发unity的动态批次。图集打包工具有很多,Asset store中也可以搜到不少,比如Texture Packer Free 、 DrawCall Optimizer(收费) Mesh Baker Free 等等都可以将贴图打包合并。

  但是合并图集也有缺点,合并贴图时应该注意选择同时出现在屏幕的对象贴图进行合并。如果不能做到这一点,那么合并图集可能起到反作用,即渲染一个对象需要加载过多无用贴图,造成内存占用率升高。我的项目这个方案也是采用之后又弃用的,因为归类同时出现在屏幕的贴图并非易事!

  1.3. 光照和阴影

  实时光照和阴影可能增加Drawcall,带有光源计算的shader材质会因为光照产生多个Drawcall。使用灯光会打断Drawcall batching,尽量使用烘焙灯光贴图等技巧来实现灯光效果。

  延伸阅读:

    · Forward Rendering Path Details 

    · Light Troubleshooting and Performance 

  1.4. 遮挡剔除、视锥剔除

   这两个Unity提供的剔除方案,出视野之后应剔除对象渲染。

 

  2. 物理组件

  3. GC 

  GC是unity自动回收内存垃圾的回收器,这虽没有内存泄漏的风险,但是过多的垃圾回收会让CPU高负荷。这里就要避免不必要的内存申请和释放。可以在某个脚本定时清理垃圾,如void update(){if(Time.framecount %5 ==0)System.GC.collect();}

  有以下几点需要注意:

  3.1.  字符串的拼接会产生临时字符串内存,移除代码中的字符串拼接,改用string.format,或stringbuilder,这没测。

  3.2. 用for代替foreach,foreach每次迭代产生24字节垃圾内存。100次循环就是2.4kB.

  3.3. 对象标签tag比较采用comparetag,不要用tag=="mytag"这样。

  3.4. 使用对象池。对象克隆也是调用new,因此对于可以循环利用的对象要采用对象池,比如子弹、特效、宝石等等。

  对象池使用时要注意一点:如果对象上挂了脚本,那么数据需要每次进行初始化或对象回收的时候进行重置,否则下次再利用的对象脚本可能存留上次的数据,那极有可能出bug。

  3.5. 尽量使用struct而非class,因为struct是栈区,class是堆区。

  GC涉及到内存,详细内容会在内存篇展开。

4. 脚本

  脚本中如果在update 函数中调用了Getcomponent等接口,最好将组件缓存。

  在update中的处理如果允许,尽量隔多帧处理一次。

  如:将update() {DoSth();} 修改为:update() { if(Time.framecount %5 == 0) DoSth();}  

  其实脚本的优化主要就是针对update中复杂和耗费的逻辑进行优化,其次对于游戏进行中的卡顿,可以修改逻辑,使用预加载方式,将游戏进行中的对象在开始前一次性加载到内存。

 

 Unity官方给出的一些优化建议:

  1.PC平台的话保持场景中显示的顶点数少于200K~3M,移动设备的话少于10W,一切取决于你的目标GPU与CPU。
  2.如果你用U3D自带的SHADER,在表现不差的情况下选择Mobile或Unlit目录下的。它们更高效。
  3.尽可能共用材质。
  4.将不需要移动的物体设为Static,让引擎可以进行其批处理。
  5.尽可能不用灯光。
  6.动态灯光更加不要了。
  7.尝试用压缩贴图格式,或用16位代替32位。
  8.如果不需要别用雾效(fog)
  9.尝试用OcclusionCulling,在房间过道多遮挡物体多的场景非常有用。若不当反而会增加负担。
  10.用天空盒去“褪去”远处的物体。
  11.shader中用贴图混合的方式去代替多重通道计算。
  12.shader中注意float/half/fixed的使用。
  13.shader中不要用复杂的计算pow,sin,cos,tan,log等。
  14.shader中越少Fragment越好。
  15.注意是否有多余的动画脚本,模型自动导入到U3D会有动画脚本,大量的话会严重影响消耗CPU计算。
  16.注意碰撞体的碰撞层,不必要的碰撞检测请舍去。

[Unity优化] Unity CPU性能优化 (难度3 推荐4)