mono优化 unity3d

2016-07-29 11:52:51 gaojinjingg 阅读数 558
(注:本文详细的讲述了C#,Mono,.Net, IL等Unity使用到的概念,如果你已经熟知这些,可以直接跳过看下篇)


Unity3D想必大家都不陌生,独立游戏制作者们很多人都在用它,甚至一些大公司也用在很商业的游戏制作上。Unity3D最大的一个特点是一次制作,多平台部署,而这一核心功能是靠Mono实现的。可以说Mono是Unity3D核心的核心,是Unity3D跨平台的根本。但是在2014年年中的时候,Unity3D官方博客上却发了一篇“The future of scripting in unity”的文章,引出了IL2CPP的概念,感觉有取代Mono之势。那什么是IL2CPP,它能为Unity3D和作为使用Unity3D的我们带来哪些好处和改变?这就是本文尝试说明的。

C#,.Net Framework
我们先说说IL2CPP试图取代的Mono。在说Mono之前,不得不提C#语言和背后的.Net Framework。C#是微软推出的一种基于.NET框架的、面向对象的高级编程语言。C#的发音为“see sharp”,模仿音乐上的音名“C♯”(C调升),是C语言的升级的意思。其正确写法应和音名一样为“C♯”。C#由C语言和C++派生而来,继承了其强大的性能,同时又以.NET框架类库作为基础,拥有类似Visual Basic的快速开发能力。C#由安德斯·海尔斯伯格主持开发,微软在2000年发布了这种语言。说到安德斯·海尔斯伯格这里要多说一句,当年和VC(注意,是VC,那个时候还没有Virtual Studio)齐名还有另外一家公司的IDE也非常流行,那就是Borland公司的Delphi,也是由安德斯·海尔斯伯格主导开发的。


他后来被微软挖走,创建了J++,一门类似Java的语言(好吧,以我肤浅的知识认为,那基本就是照着Java做的)。后来由于和Sun公司授权的原因,微软在2001年停止了J++的开发而推出了C# 1.0。说来要感谢和Sun的这场官司,否则微软也不会有C#,J++也可能一直会跟随Java的脚步。相反C#经过不断的进化,从1.0开始到4.0和最新的5.0,C#已经远远甩开Java几条街了(还是以我个人的使用Java和C#感觉而言,关于两门语言的比较,无论是效率上,夸平台上,还是语言易用性上,社区活跃度上,网上的争论随处可见,每个人都有自己的看法,这也不是本文的重点)。









Mono,Mono VM

C#虽好,但是只能在Windows上运行,微软那时候也没有将其开源,所以总是会有人说不能跨平台,光就这点,C#和Java就不能比呀。

微软公司已经向ECMA申请将C#作为一种标准。在2001年12月,ECMA发布了ECMA-334 C#语言规范。C#在2003年成为一个ISO标准(ISO/IEC 23270)。这意味着只要你遵守CLI(Common Language Infrastructure),第三方可以将任何一种语言实现到.Net平台之上。Mono就是在这种环境下诞生的。

Mono是一个由Xamarin公司(先前是Novell,最早为Ximian)所主持的自由开放源代码项目。该项目的目标是创建一系列符合ECMA标准(Ecma-334和Ecma-335)的.NET工具,包括C#编译器和通用语言架构。与微软的.NET Framework(共通语言运行平台)不同,Mono项目不仅可以运行于Windows系统上,还可以运行于Linux,FreeBSD,Unix,OS X和Solaris,甚至一些游戏平台,例如:Playstation 3,Wii或XBox 360之上。Mono使得C#这门语言有了很好的跨平台能力。相对于微软的.Net Framework运行时库Mono使用自己的Mono VM作为运行时库。 加上C#本身快速友好的开发能力,最终使得Unity团队在创建之初就决定将Mono,C#作为其核心。(嗯,这是我猜的)

有人也许会说,Unity还支持JavaScript和Boo呢,不光光只有C#一门语言。首先我要纠正的是,在Unity中的JavaScript严格意义上说并不是W3C规范中的JavaScript,它正确的名字叫做Unity Script,其实是从Boo演变过来的(这样大家就能理解为啥在3门语言中,Boo用的人最少,但是却还一直存在的原因了吧)。我认为是Unity开始为了让更多的人能够快速的上手,特别是考虑到很多脚本程序员对JavaScript已经很熟悉了,为了照顾这部分人,发明了Unity Script,它的语法和W3C的JavaScript几乎一致,使得大家可以直接用其进行开发,降低门槛。但是Unity Script在运行上却和JavaScript有着本质的不同。这个我会在下一节IL中进行详细的描述。从三门语言在Unity中的使用情况而言:Boo几乎就没人用了,Unity Script和C#两者中无论是演示代码还是Unity Asset Store中的第三方代码,C#已经有85%-90%的比例(个人粗略估计,没有做详细统计)。可见C#在Unity中深受我等游戏码农的爱戴。



IL
啰嗦完了C#,.Net Framework和Mono,引出了我们很重要的一个概念”IL“。IL的全称是 Intermediate Language,很多时候还会看到CIL(Common Intermediate Language,特指在.Net平台下的IL标准)。在Unity博客和本文中,IL和CIL表示的是同一个东西:翻译过来就是中间语言。它是一种属于通用语言架构和.NET框架的低阶(lowest-level)的人类可读的编程语言。目标为.NET框架的语言被编译成CIL,然后汇编成字节码。CIL类似一个面向对象的汇编语言,并且它是完全基于堆栈的,它运行在虚拟机上(.Net Framework, Mono VM)的语言。
具体过程是:C#或者VB这样遵循CLI规范的高级语言,被先被各自的编译器编译成中间语言:IL(CIL),等到需要真正执行的时候,这些IL会被加载到运行时库,也就是VM中,由VM动态的编译成汇编代码(JIT)然后在执行。


正是由于引入了VM,才使得很多动态代码特性得以实现。通过VM我们甚至可以由代码在运行时生成新代码并执行。这个是静态编译语言所无法做到的。回到上一节我说的Boo和Unity Script,有了IL和VM的概念我们就不难发现,这两者并没有对应的VM虚拟机,Unity中VM只有一个:Mono VM,也就是说Boo和Unity Script是被各自的编译器编译成遵循CLI规范的IL,然后再由Mono VM解释执行的。这也是Unity Script和JavaScript的根本区别。JavaScript是最终在浏览器的JS解析器中运行的(例如大名鼎鼎的Google Chrome V8引擎),而Unity Script是在Mono VM中运行的。本质上说,到了IL这一层级,它是由哪门高级语言创建的也不是那么重要了,你可以用C#,VB,Boo,Unity Script甚至C++,只要有相应的编译器能够将其编译成IL都行!


IL2CPP, IL2CPP VM

本文的”男猪脚“终于出来了:IL2CPP。有了上面的知识,大家很容易就理解其意义了:把IL中间语言转换成CPP文件。大家如果看明白了上面动态语言的CLI, IL以及VM,再看到IL2CPP一定心中充满了疑惑。现在的大趋势都是把语言加上动态特性,哪怕是c++这样的静态语言,也出现了适合IL的c++编译器,为啥Unity要反其道而行之,把IL再弄回静态的CPP呢?这不是吃饱了撑着嘛。根据本文最前面给出的Unity官方博客所解释的,原因有以下几个:
1.Mono VM在各个平台移植,维护非常耗时,有时甚至不可能完成
        Mono的跨平台是通过Mono VM实现的,有几个平台,就要实现几个VM,像Unity这样支持多平台的引擎,Mono官方的VM肯定是不能满足需求的。所以针对不同的新平台,Unity的项目组就要把VM给移植一遍,同时解决VM里面发现的bug。这非常耗时耗力。这些能移植的平台还好说,还有比如WebGL这样基于浏览器的平台。要让WebGL支持Mono的VM几乎是不可能的。

2.Mono版本授权受限
        大家有没有意识到Mono的版本已经更新到3.X了,但是在Unity中,C#的运行时版本一直停留在2.8,这也是Unity社区开发者抱怨的最多一条:很多C#的新特性无法使用。这是因为Mono 授权受限,导致Unity无法升级Mono。如果换做是IL2CPP,IL2CPP VM这套完全自己开发的组件,就解决了这个问题。

3.提高运行效率
        根据官方的实验数据,换成IL2CPP以后,程序的运行效率有了1.5-2.0倍的提升。

使用Mono的时候,脚本的编译运行如下图所示:


简单的来说,3大脚本被编译成IL,在游戏运行的时候,IL和项目里其他第三方兼容的DLL一起,放入Mono VM虚拟机,由虚拟机解析成机器码,并且执行







IL2CPP做的改变由下图红色部分标明:


在得到中间语言IL后,使用IL2CPP将他们重新变回C++代码,然后再由各个平台的C++编译器直接编译成能执行的原生汇编代码。

几点注意:
1.将IL变回CPP的目的除了CPP的执行效率快以外,另一个很重要的原因是可以利用现成的在各个平台的C++编译器对代码执行编译期优化,这样可以进一步减小最终游戏的尺寸并提高游戏运行速度。

2.由于动态语言的特性,他们多半无需程序员太多关心内存管理,所有的内存分配和回收都由一个叫做GC(Garbage Collector)的组件完成。虽然通过IL2CPP以后代码变成了静态的C++,但是内存管理这块还是遵循C#的方式,这也是为什么最后还要有一个IL2CPP VM的原因:它负责提供诸如GC管理,线程创建这类的服务性工作。但是由于去除了IL加载和动态解析的工作,使得IL2CPP VM可以做的很小,并且使得游戏载入时间缩短。

3.由于C++是一门静态语言,这就意味着我们不能使用动态语言的那些酷炫特性。运行时生成代码并执行肯定是不可能了。这就是Unity里面提到的所谓AOT(Ahead Of Time)编译而非JIT(Just In Time)编译。其实很多平台出于安全的考虑是不允许JIT的,大家最熟悉的有iOS平台,在Console游戏机上,不管是微软的Xbox360, XboxOne,还是Sony的PS3,PS4,PSV,没有一个是允许JIT的。使用了IL2CPP,就完全是AOT方式了,如果原来使用了动态特性的代码肯定会编译失败。这些代码在编译iOS平台的时候天生也会失败,所以如果你是为iOS开发的游戏代码,就不用担心了。因此就这点而言,我们开发上几乎不会感到什么问题。

最后给出Unite 2014上官方给出的性能测试截图(数字越小表示运行得越快):




有了IL2CPP,程序尺寸可以相对缩小,运行速度可以提高!看了兴奋吗?其实现有的Unity版本中已经引入了IL2CPP技术。本文下篇就通过一个实际的例子,看看IL2CPP都为我们做了哪些,以及我们需要注意些什么。


参考链接:




2016-08-31 17:01:17 honey199396 阅读数 5128

WeTest导读

内存是游戏的硬伤,如果没有做好内存的管理问题,游戏极有可能会出现卡顿,闪退等影响用户体验的现象。本文介绍了在腾讯游戏在Unity游戏开发过程中常见的Mono内存管理问题,并介绍了一系列解决的策略和方法。

什么是Mono内存

对于目前绝大多数基于Unity引擎开发的项目而言,其托管堆内存是由Mono分配和管理的。“托管” 的本意是Mono可以自动地改变堆的大小来适应你所需要的内存,并且适时地调用垃圾回收(Garbage Collection)操作来释放已经不需要的内存,从而降低开发人员在代码内存管理方面的门槛。
Unity游戏在运行时的内存占用情况可以用下图表示:


目前绝大部分Unity游戏逻辑代码所使用的语言为C#,C#代码所占用的内存又称为mono内存,这是因为Unity是通过mono来跨平台解析并运行C#代码的,在Android系统上,游戏的lib目录下存在的libmono.so文件,就是mono在Android系统上的实现。C#代码通过mono解析执行,所需要的内存自然也是由mono来进行分配管理,下面就介绍一下mono的内存管理策略以及内存泄漏分析。

Mono内存管理策略

Mono通过垃圾回收机制(Garbage Collect,简称GC)对内存进行管理。Mono内存分为两部分,已用内存(used)和堆内存(heap),已用内存指的是mono实际需要使用的内存,堆内存指的是mono向操作系统申请的内存,两者的差值就是mono的空闲内存。当mono需要分配内存时,会先查看空闲内存是否足够,如果足够的话,直接在空闲内存中分配,否则mono会进行一次GC以释放更多的空闲内存,如果GC之后仍然没有足够的空闲内存,则mono会向操作系统申请内存,并扩充堆内存,具体如下图所示。


通过上文可知,GC的主要作用在于从已用内存中找出那些不再需要使用的内存,并进行释放。Mono中的GC主要有以下几个步骤:
1.停止所有需要mono内存分配的线程。
2.遍历所有已用内存,找到那些不再需要使用的内存,并进行标记。
3.释放被标记的内存到空闲内存。
4.重新开始被停止的线程。
除了空闲内存不足时mono会自动调用GC外,也可以在代码中调用GC.Collect()手动进行GC,但是,GC本身是比较耗时的操作,而且由于GC会暂停那些需要mono内存分配的线程(C#代码创建的线程和主线程),因此无论是否在主线程中调用,GC都会导致游戏一定程度的卡顿,需要谨慎处理。另外,GC释放的内存只会留给mono使用,并不会交还给操作系统,因此mono堆内存是只增不减的。

Mono内存泄漏分析

Mono是如何判断已用内存中哪些是不再需要使用的呢?是通过引用关系的方式来进行的。Mono会跟踪每次内存分配的动作,并维护一个分配对象表,当GC的时候,以全局数据区和当前寄存器中的对象为根节点,按照引用关系进行遍历,对于遍历到的每一个对象,将其标记为活的(alive)。


如上图所示,假设A是处于全局数据区的一个对象,那么在GC的时候将作为根节点进行遍历,由于B、C、D对象都可以由A遍历到,因此被标记为活的,E、F对象则没有被标记。注意,由于引用关系是单向的,A引用了B并不代表B也引用了A,所以遍历也只能单向进行。

由于GC以全局数据区和当前寄存器中的对象为根节点进行遍历,所以对象的被标记意味着该对象可以通过全局对象或者当前上下文访问到,而没有被标记的对象则意味着该对象无法通过任何途径访问到,即该对象“失联”了,GC最终会将所有“失联”的对象内存进行回收,上图中的E和F将会在GC过程中被回收。

既然mono已经有了完善的GC机制,那是否还会存在内存泄漏呢?答案是肯定的,只是此处的内存泄漏需要重新定义一下,我们把对象已经不再需要使用却没有被GC回收的情况称为mono内存泄漏。Mono内存泄漏会使空闲内存减少,GC频繁,mono堆不断扩充,最终导致游戏内存占用的升高。下图就是一个mono内存泄漏的例子。


解决办法

对于mono内存泄漏,一般只能通过猜测+不断修改代码测试的方法来修复问题,效率很低,腾讯Wetest平台的Cube工具提供了mono内存快照对比的功能,并包括对象分配堆栈,对象引用关系等详细信息,是定位mono内存泄漏问题的一大利器。下面结合具体的代码尝试使用Cube定位mono内存泄漏问题。
首先我们定义类A,并在A的构造函数中申请了一块int[1000]大小的内存。


接着我们定义A类型的静态变量objectA,在游戏界面上绘制一个按钮,并在按钮点击事件中给objectA赋值,此时新生成了new int[1000]对象,并由objectA引用。


使用Cube的mono内存检测功能,并在按钮按下之前和按下之后分别进行一次快照,对比两次快照,查看快照间新增对象。





![Uploading 9_125867.png . . .]
可以看到,按钮按下前后新增的最大对象即为代码中生成的new int[1000]对象,并且该对象被引用的次数为1,为了查看详细的引用关系,下载快照文件snapshot2,其中有这样两行数据:




第一行说明在OnGUI函数中生成了一个A类型的对象,其指针为1533098928,第二行说明在OnGUI()->A:.cotr()中生成了一个Int32[]类型的对象,并且该对象被指针为1533098928的对象引用。即new int[1000]对象被objectA引用,这也是导致new int[1000]对象无法被GC回收的原因。而objectA本身是一个静态对象,是GC的根节点,因此没有对象引用。
如果需要生成的new int[1000]对象被回收怎么做呢?很简单,将objectA.a设置为null,没有了objectA对其的引用,自然会被GC回收了。需要说明的是,将objectA.a设置为null只是断绝了引用关系,真正对象的回收要等到GC的时候才会进行,“Cube”在获取内存快照的时候会首先进行一次GC,防止由于没有及时调用GC导致的误判。

游戏中大部分mono内存泄漏的情况都是由于静态对象的引用引起的,因此对于静态对象的使用需要特别注意,尽量少用静态对象,对于不再需要的对象将其引用设置为null,使其可以被GC及时回收,但是由于游戏代码过于复杂,对象间的引用关系层层嵌套,真正操作起来难度很大。可以首先使用Cube工具进行分析,根据mono内存趋势找出泄漏的具体场景,然后再使用快照对比功能进行详细分析。


2018-08-04 10:01:32 u013509878 阅读数 817

Unity 3D优化,解决游戏开发的优化问题,同时应对面试更是再适合不过了!废话少说,马上开始!

Unity优化是一个很大的概念,我们优化时需要注意三个方面:CPU优化,GPU优化,内存优化.

CPU方面的优化:

(1) 减少DrawCall.

(2) 物理组件(Physics).

(3) 减少GC(垃圾回收)次数.

(4) 脚本的代码质量.

一,对DrawCall的优化

1、什么是DrawCall ?

答:Draw Call就是CPU调用图形编程接口,比如DirectX或OpenGL,来命令GPU进行渲染的操作。

2、 如何减少DrawCall ?

答: 思路就是每个物体尽量减少渲染次数,多个物体最好一起渲染。所以有三个方案:

(1)使用批处理,Unity在运行时将物体合并一次渲染。这里分为动态批处理静态批处理

(2)通过把文理打包成图集尽量减少材质的使用。

(3)尽量减少反光,阴影之类的效果,因为那会使物体多次渲染。

静态批处理就是将没有生命的不同物体设置为Static。

动态批处理是引擎自动进行的,例如动态实例化Prefab(预制体)如果动态物体共享相同的材质,引擎会自动批处理。动态批处理有很大限制,网格物体顶点数不能超过900。

二,对物理组件的优化

1、设置一个合适的FixedTimestep。

2、尽量不要使用网格碰撞器,占用CPU计算。

三,处理GC的优化

虽然GC是用来处理内存的,但是的确会增加对CPU的开销,因此对于GC的优化目标就是尽量减少GC的触发。

GC是何时触发的?

1、堆的内存不足时,自动调用GC。

2、编程人员手动调用GC。

GC的优化说白了就是代码的优化,主要注意一下5点:

(1)字符串连接的处理。。

(2)尽量不要使用foreach,减少迭代器产生。

(3)不要直接访问gameObject的tag属性。换成"if(obj.CompareTag("Player"))"

(4)使用对象池,以实现空间的重复利用。

(5)不要使用LinQ。

四,对代码质量的优化

(1)Transfrom组件获取一次就保留引用,而不是每次都获取。

(2)不用频繁的GetComponent

(3)使用内建数组,如Vector3.zero而不是new Vector(0,0,0)。

(4)对方法的参数优化,善于使用ref关键字。

 GPU方面的优化:

GPU瓶颈:

(1)填充率,可以简单理解为图形处理单元每秒渲染的像素数量

(2)像素的复杂度,比如动态阴影、光照、复杂的shader等

(3)几何体的复杂度(顶点数量)

(4)GPU的显存带宽

影响GPU性能的无非就两大方面,一方面顶点数量过多,像素计算过于复杂;另一方面就是GPU的显存带宽。优化方法:

(1)减少顶点数量,简化计算复杂度。

(2)压缩图片,以适应显存带宽。

一、减少顶点数量,简化计算复杂度。

(1)保持材质的数目尽可能少,更容易批处理。

(2)使用纹理图集,代替小贴图。

(3)如果使用了纹理图集和共享材质,使用Renderer.sharedMaterial来代替Renderer.material。

(4)使用光照贴图(lightmap)而非实时灯光。

(5)使用LOD(多层次细节),好处就是那些离得远看不清的细节可以忽略。

(6)遮挡剔除

(7)使用mobile版的shader,因为简单。

二、压缩图片,减小显存带宽压力。

(1)OpenGL ES2.0使用ETC1格式压缩等,在打包设置里有。

(2)使用MipMap,小图集

内存方面的优化:

(1)Unity3D的内部内存

(2)Mono的托管内存

(3)若干自己引入或第三方DLL所需的内存(非重点)

内容原创,转载请注明出处!

2017-10-10 15:09:30 qq_40557211 阅读数 2604

Mono内存是Unity中不会释放的内存,他的容量一旦被撑大,项目所占的内存就会跟着增大,不能手动释放。是一个比较危险的地方,wetest给出的标准是峰值不要超过50M,wetest里面会有最大的top50的占用信息,里面有一些重复,但是也可以根据这个确定需要优化的内容,并且从中找到关联的一些问题。

根据我这里面显示mono里面主要为:(具体项目具体分析)

1.    protobuf所存的表格的数组信息

2.    uidrawcall的数组队列信息

表格这块的问题:

1.mono内存问题,是表格的结构和设计不合理,存在大量冗余字段和空字段。解决方案为根据自己项目逻辑拆分大表,并删除冗余和无用字段,效果明显。tips:之前几个项目都是缓存部分表,之后用到那张表加载那张表,所以拆分表有利于提高记载速度,但是具体项目具体分析)

2.GC问题,是protobuf所生成的,在项目里面以TXT形式存储数据,在使用时,需要先将txt读取到数组当中,在读取TXT时会产生大量的GC,造成一定的卡顿。(我们当时100K的表会产生1M以上的GC,可能是解析处理的问题,但是后来直接吧这个机制换掉了,没有做深研究,不做介绍了。)最后换成将表格存储在对象上,需要用的这个表就实例化表格对应的对象。

3.表格数量问题,我们当时最大138张表,其中好多表格都为几个字段,1K一张表,还有一些开发过程中临时表。相关表格合并,用字段区分。

4.字典表过大,因为多语言版本最初把其他语言版本配置在一张表中,方便使用。之后把生成和读取的地方做修改,根据语言种类生成N张表,最后只读取一张表。

最后随着项目的增大,数值必然会增加,无需纠结最大值合适自己项目的才是最好的。我们改完之后就可以接受了。

2016-07-12 19:37:28 hcud024 阅读数 3898


官方优化文档--优化图像性能
http://docs.unity3d.com/Documentation/Manual/OptimizingGraphicsPerformance.html

Unity3D性能优化专题
性能优化是一个异常繁琐而又涉及到项目开发的方方面面的一个过程,它的本质是在运行时的一个时间里尽可能完美展现丰富的内容。
实现优化可以通过优化资源、渲染、粒子、物理等模式;
也可以通过修改模型大小、减少纹理尺寸并结合Unity3D的一些相关特性来提升游戏的性能。
随着移动端的设备硬件能力的提升,如何使用尽可能优化的资源和程序效率来展现出更多的细节内容就成为了每个开发者都应该思考的内容,这也使得优化变成了项目开发中非常重要的一环。
***********
首先介绍下draw call(这个东西越少你的游戏跑的越快):
在游戏中每一个被展示的独立的部分都被放在了一个特别的包中,我们称之为“描绘指令”(draw call),然后这个包传递到3D部分在屏幕上呈现出来。这就和你希望你的亲友收到准备好的圣诞礼物需要包装好然后穿过城市准时放在他应该出现的地方一样没什么不同。你的CPU来完成包装和传递他们的活,同时会消耗很多的带宽,所以最终分配好这些关键性资源很重要。目前,真正可怕的事情是从描绘指令消耗远景开始,每一个独立的飞溅到地板上的血迹和一个角色或者一具死尸消耗的字节是一样的多的:他们都消耗同样的描绘指令。除此之外,没有什么更多的差别。
那么如何降低 draw call 呢??那么我们就用到Culling(剔除)技术。如果不应用这个技术,电脑是不管3721把场景里所有的东西都送去渲染的。看得见的也渲染,看不见得照样也送去渲染。很傻是吧,那咋办呢。得告诉电脑,那个你
看得见的渲染,看不见的就算了。于是就有了
1.视锥体剔除(Frustum Culling)这个unity系统自带了好像,就不用操心了。
2.遮挡剔除(Occlusion Culling)
Unity 3专业版内置了一个强大的 Occlusion Culling 插件 Umbra免费的
遮挡剔除(Occlusion Culling)
遮挡剔除是一种什么样的特性呢, 当一个物体被其他物体遮挡住而不在摄像机的可视范围内时不对其进行渲染。. 遮挡剔除在3D图形计算中并不是自动进行的。因为在绝大多数情况下离 camera 最远的物体首先被渲染,靠近摄像机的物体后渲染并覆盖先前渲染的物体(这被称为重复渲染,无效渲染"overdraw"). 遮挡剔除不同于视锥体剔除. 视锥体剔除只是不渲染摄像机视角范围外的物体而对于被其他物体遮挡但依然在视角范围内的物体则不包括在内. 注意当你使用遮挡剔除时你依然受益于视锥体剔除(Frustum Culling).
***********
Unity(或者说基本所有图形引擎)生成一帧画面的处理过程大致可以这样简化描述:引擎首先经过简单的可见性测试,确定摄像机可以看到的物体,然后把这些物体的顶点(包括本地位置、法线、UV等),索引(顶点如何组成三角形),变换(就是物体的位置、旋转、缩放、以及摄像机位置等),相关光源,纹理,渲染方式(由材质/Shader决定)等数据准备好,然后通知图形API——或者就简单地看作是通知GPU——开始绘制,GPU基于这些数据,经过一系列运算,在屏幕上画出成千上万的三角形,最终构成一幅图像。
在Unity中,每次引擎准备数据并通知GPU的过程称为一次Draw Call。这一过程是逐个物体进行的,对于每个物体,不只GPU的渲染,引擎重新设置材质/Shader也是一项非常耗时的操作。因此每帧的Draw Call次数是一项非常重要的性能指标,对于iOS来说应尽量控制在20次以内,这个值可以在编辑器的Statistic窗口看到。 Unity内置了Draw Call Batching技术,从名字就可以看出,它的主要目标就是在一次Draw Call中批量处理多个物体。只要物体的变换和材质相同,GPU就可以按完全相同的方式进行处理,即可以把它们放在一个Draw Call中。Draw Call Batching技术的核心就是在可见性测试之后,检查所有要绘制的物体的材质,把相同材质的分为一组(一个Batch),然后把它们组合成一个物体(统一变换),这样就可以在一个Draw Call中处理多个物体了(实际上是组合后的一个物体)。
但Draw Call Batching存在一个缺陷,就是它需要把一个Batch中的所有物体组合到一起,相当于创建了一个与这些物体加起来一样大的物体,与此同时就需要分配相应大小的内存。这不仅会消耗更多内存,还需要消耗CPU时间。特别是对于移动的物体,每一帧都得重新进行组合,这就需要进行一些权衡,否则得不偿失。但对于静止不动的物体来说,只需要进行一次组合,之后就可以一直使用,效率要高得多。 - See more at: http://ravenw.com/blog/2011/10/14/unity-optimization-of-draw-call/#sthash.0WfH4KnX.dpuf
***********

输出设置相关:
1:最终输出的时候,在unity - edit - project setting - player 里, 把 other settings - script call optimization 改成 快速, 但没有例外. fast but no exceptions
2: unity - edit - project setting - time 里, 把 maximum allowed timestep 改成0.1
3:

常规优化
1: 联结(combine)优化
显卡对于一个含100个面片的物体的和含1500个面片的物体的渲染消耗几乎是等价的。所以如果你有N个同一材质的东西,那么把他们联成同一个物体再统一用一个material那么对于显卡的渲染消耗就要降低N倍。
在unity里再联结,这个要怎么做呢,其实也挺简单的,经常看Island Demo项目的人应该很早就注意到里面的石头这些都是连在一起的,原因就在这里,他提供了现成就脚本实现联结。
先到Island Demo的Assets/Script下找到CombineChildren.cs和MeshCombineUtility.cs两个脚本复制到自己的项目文件(我们要用的只是前者,但他会调用后者,没有后者unity会报错,所以把后者扔到项目里不管就好)
然后把你项目里那些用同一Materials的东西扔到一个空物体里面去,再把CombineChildren.cs贴到那个空物体上,搞定!
2: 模型
(1)只用一个mesh renderer, 少用多materials, 最多3个
每个角色尽量使用一个 Skinned Mesh Renderer
这是因为当角色仅有一个 Skinned Mesh Renderer 时, Unity 会 使用可见性裁剪和包围体更新的方法来优化角色的运动,而这种优化只有在角色仅含有一个 Skinned Mesh Renderer 时才会启动。
(2)模型骨骼不超过30个.
(3)尽量减少面 300-1500
(4)模型尽量不要分开, 如果多个模块, 会多次调用dc
(5)一般角色应该没有 IK 结点
这是因为角色的动作大多数都是事先设定好的,并不需要经过 IK 操作来进行实时计算( Rogdoll 除外),所以在模型导入时,不要将 IK 结点一起导入。
(6) 不要附加 Animation Component 在静态实体上附加 Animation 部件虽然对结果没有影响,但却会增加一定的 CPU 开销来调用这一组件,所以尽量去掉该组件。

3:尽量不用像素光(pixels Lights)
4:不用 软阴影(soft shadow), 或者不用阴影(No Shadows)
灯光能不用就不用, 阴影可以用面来代替.
5:少用实时灯光, 尽量使用lightmap
http://blog.sina.com.cn/s/blog_409cc4b00100no8y.html
动态实时灯光相比静态灯光,非常耗费资源。所以除了能动的角色和物体(比如可以被打的到处乱飞的油桶)静态的地形和建筑,通通使用Lightmap。
强大的Unity内置了一个强大的光照图烘焙工具Beast,这个东东是Autodesk公司的产品
6:transform和OnGUI (运算上的优化远比不上 绘制效率上的优化,少个dc可能就比得上这些了)
http://fredxxx123.wordpress.com/2013/05/22/unity%E6%80%A7%E8%83%BD%E5%84%AA%E5%8C%96%E4%B9%8B%E5%B0%8F%E6%B8%AC%E8%A9%A6/
// transfrom
少用transform, 多用 myCachedTransform
頻繁使用該物件的地方,就是先把該物件cache起來,理論上就會避免這種不必的開銷。
※這也可延伸至其他是property的變數。例如:transform.position。
***直接使用的版本:
public class TestUnit : MonoBehaviour
{
void Update()
{
var t = this.transform;
t = this.transform;
t = this.transform;
t = this.transform;
t = this.transform;
}
}
***cache 使用的版本:
public class TestUnit : MonoBehaviour
{
Transform myTransform;
void Start()
{
myTransform = transform;
}

void Update ()
{
var t = this.myTransform;
t = this.myTransform;
t = this.myTransform;
t = this.myTransform;
t = this.myTransform;
}
}
// OnGUI
空物件版本:
public class TestUnit : MonoBehaviour
{
}
外加一個空白OnGUI的版本:
public class TestUnit : MonoBehaviour
{
void OnGUI()
{ }
}
實際上是被GUI.Begin()和GUI.End()所佔據,function本身是無辜的~~
非必要避免使用OnGUI(),即使它裡面甚麼事情都沒做!
如需使用,請盡可能集中到同一個OnGUI()底下執行繪製,好避免Begin End的開銷。

7:动态物体的相关优化

优化主要分为两个方向,一个是资源相关优化和引擎相关的优化。资源相关的优化,大概分为动态物体、静态物体、纹理数据、音频数据、程序包数据。对于动态物体比如NPC、怪物等,需要对面片数量的控制,大概在300到2000面。1500面就可以体现人物细节,但如果是人物比较多,可能要降低面数,不要低于300。另外,一方面是控制Skinned Mesh Renderer的数量;另一方面是控制材质数量在1到3种。人物最好用小于30根骨骼,如果你用的骨骼越多,耗费的CPU就更多,所以在移动平台上尽量少于30根。现在我们看其他动态物体,利用Dynamic Batching进行合批。这个下雨特效并不是系统做的,是包含很多雨点的网格进行重复拷贝,然后错乱移动实现的。每一个雨点并不是一个粒子,这样能减少很多CPU的消耗,每一个整体网格都会有一个顶点的控制,通过控制顶点数量,对系统实现雨点效果来说,这是一个相当省时省力的方法。

8:静态物体的相关优化

下面我们来看静态物体,静态物体也是要控制面数和顶点数,顶点数少于500个。static是不会进行移动缩放、旋转的,把它标记为static,当然他们的材质是一样的。不要添加animation组建,对于静态物体来说,这个组件毫无意义,能把他丢掉就丢掉,因为这对CPU的消耗是非常客观的。
9:音频程序的优化
关于音频时间的播放,比如背景音乐,建议使用MP3压缩格式,比如音效,要求数据尽快加载,这些数据比较小就可以,使用WAV和AIF未压缩音频格式。关于程序包的优化,很多开发者会埋怨说打出来的包太大,现在介绍减少程序包的方法,首先使用压缩格式的纹理,以显卡的压缩格式保存,使用压缩网格和动画数据。网格压缩是先采用量化处理,当然这个压缩是保证在包里面的数据小,但运行时占用的内存没有减少,因为我们并没有把顶点删除,但是对动画数据来说,动画数据经过压缩处理后降低,可以减少游戏列层。

关于代码尽量不要使用System.xml,我们建议使用Mono.xml。启用Stripping来减少库的大小,使用剥离方式。

10:引擎相关优化和物理相关优化
下来是引擎相关的优化,例如光照设置、相继设置、粒子特效、物理特效等。那拿光照设置来说,光源全部的实时光照这是很恐怖的,每一次实施光照代表着每一次使用消耗,怎么优化?有人使用LightMapping来制作静态场景,他的好处是不需要用多张实施光照,而给场景很好的光照效果。有人使用Light Probes代替实时光照,好处是完全不用怎么消耗,而且运作性能也非常高。在有些时候使用Light Probes代替光照,他能跟场景很好的融合,在一个角落里,这个任务会被阴影打得暗一些。如果说场景中确实需要一些实时光源,那么肯定是需要做过优化设置的实时光源,控制important的光源个数。如果说光源有些地方产生了交叉光,这个时候你可以通过设置Pxel Light,控制每一个光源都只接受一个动态光照,数目大概是1—2个。对于关闭光源的实时阴影,并不是所有平台都支持实时阴影,消耗也非常大,不建议大家使用。关于相机方面的设置,平面越近,渲染越少。我们更建议使用分层,比如远处的建筑,对于建筑物的裁减平面远一些,如果是花草,就可以使用平面就近一些。现在看一下粒子特效,粒子也是游戏中需要优化的东西,建议屏幕中最大的粒子数不要超过200,同时每个发射器发射的最大粒子数不要超过50。粒子尺寸也要尽可能小,最终在屏幕有多少像素。他们中间的像素可能会被渲染很多次,至少四五次,这时发现粒子系统仅像素就填充了更多屏幕,这时候对游戏来说非常耗费,对游戏的其他功能性能也有所影响。另外一方面,对于非常小的粒子,尽量不要开启粒子碰撞功能。

现在我们看一下物理相关优化,物理尽可能使用Sphere Coillider、Box Coillider等,尽量避免使用Meh Colllider等。渲染设置,避免使用Alpha Test,因为非常耗时,性价比很低。关于Sttic Batching,对静态物体进行Batch,对几何数据的大小没有限制。物体被合并后会带来一些内存消耗,比如说有控制网格的物体,用Batch会合并成大物体。Dynamic Batching目前仅支持小于900顶点的网格物体。如何理解900呢,其实就相当于900个顶点数据大小的物体,如果说使用Position、Normal和UV三种属性,那么你只能Batch300个顶点。整体缩放的物体不能被Batch,除非他们的缩放值相同。之前有一个客户做特效,使用Batch机制把面片合并,最终让所有面片共享一个纹理,这时候发现这些面片没有被Batch出来,导致运行游戏时大概放三个技能就10多个招套。对于非整体用户体,他们的Batch是需要很好利用到。

11:纹理合并优化
现在来看纹理合并,纹理合并就是为了特到Batch数量,合并物体首先需要合并工具,还要修改使用纹理的网格的UV,使他们使用纹理。合并纹理主要是参照Batch,提高渲染性能。但在合并材质后需要注意的是脚本访问Renderer被拷贝。/*安挡剔除,建议使用PVS技术。建议大家使用自定义shader,例如高光效果,高光效果可能不需要做一些入射线的检测,只是简单把他的值放大也可以模拟高光效果,从而减少一些消耗。
另外一个是用profiler,通过他给的数据进行针对性的优化。以上是跟大家介绍优化的内容,如何作出良好优化,一定要做好良好的规划,到后期就不会很麻烦,如果规划没有做好有可能会给程序带来很大压力,结果可能很不乐观。*/最后,要不断实验不断总结才能达到自己满意的效果。

12:
要想降低Drawcal的话,有如下两点小建议
(1)不要用Unity自带UI或者iGUI, 用NUI 或者EZ GUI
(2)创建好的GameObject不用了就最好及时 删除 / 设置active为false/移出屏幕 。 这几种方法都可以去掉该物体导致增加的Drawcall

13:

*********************************
*********************************
*********************************
最近一段时间一直在做Unity 在IOS设备上的资源优化,结合Unity的官方文档以及自己遇到的实际问题,我把自己认为一些重要的信息罗列在下面,并尽可能对将其量化,以方便更多需要做优化的朋友。
1、 角色
每个角色尽量使用一个 Skinned Mesh Renderer
这是因为当角色仅有一个 Skinned Mesh Renderer 时, Unity 会 使用可见性裁剪和包围体更新的方法来优化角色的运动,而这种优化只有在角色仅含有一个 Skinned Mesh Renderer 时才会启动。
角色 Material 数量
2-3 个
骨骼数量
小于 30 个
面片数量
300-1500
一般角色应该没有 IK 结点
这是因为角色的动作大多数都是事先设定好的,并不需要经过 IK 操作来进行实时计算( Rogdoll 除外),所以在模型导入时,不要将 IK 结点一起导入。
2、 静态实体
不要附加 Animation Component
在静态实体上附加 Animation 部件虽然对结果没有影响,但却会增加一定的 CPU 开销来调用这一组件,所以尽量去掉该组件。
网格顶点数
小于 500
UV 值范围尽量不要超过( 0, 1 )区间
尽量保证 UV 值不越界,这对于将来的纹理拼合优化很有帮助。
3、 地形
地形的分辨率大小
长宽均尽量小于 257 。这是因为地形太大,会造成大量顶点数据,给你的内存带宽造成一定的影响,在目前的 ios 设备中,内存带宽是非常有限的,需要尽量节省。同时,如果用 Unity 自带的地形,一定也要使用 Occlusion Culling ,因为 Unity 的刷地形工具虽然方便,但却是 framekiller ,刷过之后,你会发现 drawcall 增加的非常多。
混合纹理数量
不要超过 4 。地形的混合操作是很耗时的,应该尽量避免。能合并的纹理尽量合并。
4、 纹理
纹理格式
建议 png 或 tga 。不用转成 ios 硬件支持的 PVRTC 格式,因为 Unity 在发布时会帮你自动转的。
纹理尺寸
长宽小于 1024 。同时应该尽可能地小,够用就好,以保证纹理对内存带宽的影响达到最小。
支持 Mipmap
建议生成 Mipmap 。虽然这种做法会增加一些应用程序的大小,但在游戏运行时,系统会根据需求应用 Mipmap 来渲染,从而减少内存带宽。
检查 Alpha 值
如果纹理的 alpha 通道均为 1 ,则用 RGB 的 24 位纹理来代替 RGBA 的 32 位纹理。(据说 Unity 内部会进行自动检测)
5、 光源
光源“ Important ”个数
建议 1 个,一般为方向光。“ Important ”个数应该越小越少。个数越多, drawcall 越多。
Pixel Light 数目
1-2 个。
6、 粒子特效
屏幕上的最大粒子数
建议小于 200 个粒子。
每个粒子发射器发射的最大粒子数
建议不超过 50 个。
粒子大小
如果可以的话,粒子的 size 应该尽可能地小。因为 Unity 的粒子系统的 shader 无论是 alpha test 还是 alpha blending 都是一笔不小的开销。同时,对于非常小的粒子,建议粒子纹理去掉 alpha 通道。
尽量不要开启粒子的碰撞功能。
非常耗时。
7、 音频
游戏中播放时间较长的音乐(如背景音乐)
使用 .ogg 或 .mp3 的压缩格式。
较短音乐(如枪声)
使用 .wav 和 .aif 的未压缩音频格式。
8、 相机
裁剪平面
将远平面设置成合适的距离。远平面过大会将一些不必要的物体加入渲染,降低效率。
根据不同的物体设置不同的远裁剪平面
Unity 提供了可以根据不同的 layer 来设置不同的 view distance ,所以我们可以实现将物体进行分层,大物体层设置的可视距离大些,而小物体层可以设置地小些,另外,一些开销比较大的实体(如粒子系统)可以设置得更小些等等。
9、 碰撞
尽量不用 MeshCollider
如果可以的话,尽量不用 MeshCollider ,以节省不必要的开销。如果不能避免的话,尽量用减少 Mesh 的面片数,或用较少面片的代理体来代替。
10、 其他
Drawcall
尽可能地减少 Drawcall 的数量。
iOS 设备上建议不超过 100 。
减少的方法主要有如下几种: Frustum Culling , Occlusion Culling , Texture Packing 。
Frustum Culling 是 Unity 内建的,我们需要做的就是寻求一个合适的远裁剪平面; Occlusion Culling ,遮挡剔除, Unity 内嵌了 Umbra ,一个非常好 OC 库。但 Occlusion Culling 也并不是放之四海而皆准的,有时候进行 OC 反而比不进行还要慢,建议在 OC 之前先确定自己的场景是否适合利用 OC 来优化;
Texture Packing ,或者叫 Texture Atlasing ,是将同种 shader 的纹理进行拼合,根据 Unity 的 static batching 的特性来减少 draw call 。建议使用,但也有弊端,那就是一定要将场景中距离相近的实体纹理进行拼合,否则,拼合后很可能会增加每帧渲染所需的纹理大小,加大内存带宽的负担。
这也就是为什么会出现“ DrawCall 降了,渲染速度也变慢了”的原因。

非运动物体尽量打上 Static 标签
Unity 在运行时会对 static 物体进行自动优化处理,所以应该尽可能将非运行实体勾上 static 标签。

场景中尽可能地使用 prefab
尽可能地使用 prefab 的实例化物体,以降低内存带宽的负担。检查实体的 PrefabType ,尽量将其变成 PrefabInstance ,而不是 ModelPrefabInstance 。