容易忽略的美术资源的优化:
优化的美术制作真是一种感觉和经验的积累,能看出制作水平的不是做的效果多么犀利,而是得看制作的效果与对机器的要求等的性价比。
- 关于合并: 100个三角形的MESH,在渲染时与1500个面数的物体是没太大差别的,最佳的渲染设置应该在每个模型大约1500-4000个三角面。
- 材质共享: 如果需要通过脚本来访问复用材质属性,改变Renderer.material将会造成一份材质的拷贝。应该使用Renderer.sharedMaterial来保证材质的共享状态。
- 批处理动态物体需要在每个顶点上进行一定的开销,也有一些约束:
- 对VB的显存大小也有一定限制,如果着色器使用顶点位置,法线和UV值三种属性,那么只能批处理300顶点以下的物体;如果着色器需要使用顶点位置,法线,UV0,UV1和切向量,那只能批处理180顶点以下的物体了。
- 拥有lightmap的物体含有额外(隐藏)的材质属性,比如:lightmap的偏移和缩放系数等。所以,拥有lightmap的物体将不会进行批处理(除非他们指向lightmap的同一部分)。
- 使用不同缩放(scale)的物体将不能批次。分别拥有缩放尺度(1,1,1)和(2,2,2)的两个物体将不会进行批处理。
- 另外一个值得吸收的经验是非均匀缩放动画在unity中非常的慢,均匀缩放会快很多。
- 骨骼数量控制:一般来说游戏中的骨骼数量为15-60个。骨骼越少运行速度越快,一般来说30块骨骼就可以让角色动的很舒服了。建议每个角色30个骨骼,就按照这个规范吧。
- 尝试用压缩贴图格式,或用16位代替32位。
程序开发层面的注意点:
- 垃圾回收器收集垃圾内存时负载较大,对移动设备是个大问题,因此要从代码层面减少临时内存的生成,
1) 移除代码中的任何字符串连接,因为这会给GC留下大量垃圾。
2) 用简单的“for”循环代替“foreach”循环。由于某些原因,每个“foreach”循环的每次迭代会生成24字节的垃圾内存。一个简单的循环迭代10次就可以留下240字节的垃圾内存。
3) 更改我们检查游戏对象标签的方法。用“if (go.CompareTag (“Enemy”)”来代替“if (go.tag == “Enemy”)”
- 使用#pragma strict 简单的添加#pragma strict在脚本顶部,之后Unity将禁用脚本的动态类型,强制你使用静态类型。
- 缓存各种组件、Object查找
- 尽量使用固定的内置数组:内置数组是非常快的。ArrayList或Array类很容易使用,更方便使用。但是他们有完全不同的速度。内置数组还有好处是,内存连续,元素对齐。
- 不要使用System,System.Xml以及其他系统自带的DLL,会多出几兆空间,找找开源的。
- 尽量采用内置的高效的shader吧,例如(built-in)Shader mobile,如果自己写,复杂的数学计算函数别用,alphatest慎重(美术几何挖洞来实现吧)。shader中注意float/half/fixed的使用。