第一篇：Unity之工作总结
图片格式
----------1 DrawCall
-----------2
图片格式：
NGUI生成的图集的图片格式是PNG格式，但是无论是什么格式的图片 Unity都会自己生成一套格式，并且打包的时候不会用文件夹下面的格式，而是Unity自己格式。
如果你用的UITexture 你可以对每一张图来修改格式，比如颜色数比较少的图片可以使用16bit，如果没有透明，可以使用pvr或者etc 这样图片会小很多。如果是UISprite 只要有透明的 就必须使用RGBA32 要不然UI会很难看。
除去 UITextuer和Atlas的图片之外（因为有透明），其余的贴图必须是2的幂次方。因为只有2的幂次方图片，并且没有透明通道的才会被压缩。Ios会被压缩成pvr格式，Andriod会压缩成etc格式。压缩之后会小很多。
人物贴图 场景题图 特效贴图 一定要是2的幂次方。
贴图透明通道分离，压缩格式设为ETC/PVRTC 最初我们使用了DXT5作为贴图压缩格式，希望能减小贴图的内存占用，但很快发现移动平台的显卡是不支持硬件解压DXT5的。因此对于一张1024x1024大小的RGBA32贴图，虽然DXT5可将它从4MB压缩到1MB，但系统将它送进显卡之前，会先用CPU在内存里将它解压成4MB的RGBA32格式（软件解压），然后再将这4MB送进显存。于是在这段时间里，这张贴图就占用了5MB内存和4MB显存；而移动平台往往没有独立显存，需要从内存里抠一块作为显存，于是原以为只占1MB内存的贴图实际却占了9MB！
所有不支持硬件压缩格式都有相同的问题。解决方案：
现在Andriod硬件最广泛支持的时Etc ,IOS上支持的时PVRTC。但这两种格式都是不带透明（Alpha）通道的，因此我们需要将每张原始贴图的透明通道分离出来，写进另一张贴图的红色通道里，这两张特图都采用Etc/Pvrtc压缩。渲染的时候 将两张贴图都送进显存。同时 我们修改了NGUI的shader 在渲染时第二张贴图的红色通道写入到第一张贴图的透明通道里恢复原来的颜色：
1.2.3.4.5.6.} fixed4 frag(v2f i): COLOR {
fixed4 col;
col.rgb = tex2D(_MainTex, i.texcoord).rgb;col.a = tex2D(_AlphaTex, i.texcoord).r;return col * i.color;
这样，一张4MB的1024x1024大小的RGBA32原始贴图，会被分离并压缩成两张0.5MB的ETC/PVRTC贴图（我们用的是ETC/PVRTC 4 bits）。它们渲染时的内存占用则是2x0.5+2x0.5=2MB。
DrawCall 当两个renderQueue相邻的DrawCall使用了相同的贴图、材质和shader实例时，这两个DrawCall就可以合并。但需要注意的是DrawCall合并不见得会提高性能，有时反而会降低性能
如果是UIGeometry为了渲染绘制准备数据，那么UIDrawCall其实是定义了渲染绘制需要的基本组件。这里拿煮菜做个比喻帮助理 解：UIGeometry好比为煮菜准备食材，UIDrawCall好比是煮菜的工具（锅，炉子等），UIPanel就是大厨了决定着什么时候该煮 菜，UIWidget（UILabel，UISprite和UITexture）是这道菜怎么样的最终呈现。
UIWidget分别用UpdateGeometry和WriteToBuffers对UIGeometry的ApplyTransform和 WriteToBuffers进行封装调用，ApplyTransform是根据UIPanel的坐标调整Vertices的坐 标，WriteToBuffers将UIGeometry的Vertices，UVs和Colors添加进UIPanel的Vertices，UVs和 Colors的BetterList中。
这里还有一个细节就是：UIGeometry中的Vertices，UVs和Colors的BetterList的buffer什么时候得到，因为这些都 是UIWidget或其子类的信息，所以在UIWidget的子类UILabel，UISprite和UITexture中OnFill函数生成 UIGeometry的BetterList的buffer。
UIWidget这个脚本中的两个函数：WriteToBuffers，OnFill，UpdateGeometry。
WriteToBuffers和OnFill这两个函数都是将Vertices，UVs和Colors等add进参数的List中去，查看 WriteToBuffers的调用出发现其参数是UIPanel的Vertices，UVs和Colors，而OnFill的参数是 UIGeometry的Vertices，UVs和Colors。
WriteToBuffers只是对UIGeometry的封装调用，也就是说将UIGeometry的Vertices，UVs和Colors等信息add进UIPanel的对应List中。
UIGeometry的脚本，一直有一个疑问：UIGeometry的Vertices，UVs和Colors的List没有看到add方法的执行，只有在WriteToBuffers被add。直到看到了OnFill才恍然大悟，虽然UIWidget的OnFill是虚函数，没有具体实现，看了下 UISprite重写的OnFill函数，就是把Vertices，UVs和Colors 添加到UIGeometry的Vertices，UVs和Colors中。所有UI组件的Vertices，UVs和Colors都汇集到UIPanel的Vertices，UVs和Colors去了，然后 UIPanel指定给UIDrawCall渲染就行了
UIWidget的一些实现细节，MakePixelPerfect():对gameObject的localPosition和locaScale进行微调和纠正。SetDirty():调用UIPanel的SetDirty()对组件的变更进行重建（rebuilt)。Uiwidge UIGeometry& UIDrawCall 的关系：
UIWidget 中有两个变量UiDrawCall mDrawcall 和UIGeometry mGeo 的verts uvs cols 的BetterList,然后UiWidget 的UpdateGeometry函数对UIGeometry 的ApplyTransform()和WriteToBuffer()调用进行更新.每一个UIwidget都有一个UIGeometry 但是不都有一个UIDrawCall,而是通过Batch合并达到减少DrawCall的数量，UiDrawCall是有UiPanel生成的。
DrawCall的数量优化
根据上述描述可以得出一个结论：使用相同material的连续的Uiwidget(UILable UiSprite)公用一个UIDrawcall。通过这个结论我们可以得到一个解决DrawCall过多的问题，UIPanel生成DrawCall时是Fill()方法。Fill 方法对UiWidget.list进行检测把使用相同Material的连续的Uiwidget合并生成一个DrawCall ,UIWidget.List 的排序是根据UiWidget的Depth进行的。所以解决方案有两种：
1.修改UiWidget(UiLable UIwidget)的Depth,限定UIwidget.List的排序 2.重写Uiwidget的CompareFunc()方法。（重写UIWidget的CompareFunc也是可以的，按照Material的name优先排序，只有当material一样是才考虑depth进行排序：）
3.无重叠时自动重排。绘制顺序按照Hierarchy
采用第二种方式减少DrawCall: Material leftMat = left.material;Material rightMat = right.material;if(leftMat == rightMat){ if(left.mDepth < right.mDepth)return-1;else if(left.mDepth > right.mDepth)return 1;else return 0;} if(leftMat!=null & rightMat!= null)return string.Compare(leftMat.name,rightMat.name);if(leftMat!= null)return-1;if(rightMat!= null)return 1;
return(leftMat.GetInstanceID()< rightMat.GetInstanceID())?-1 : 1;
夹层问题：
因为Material使用的Shader使用了透明，这样就不能做深度测试，也就是Mesh的“深度”是不影响的，这样最终的显示就跟Shader的 renderQueue有关了，即renderQueue越大，显示的越靠前面（重叠的图层，renderQueue越大，越靠前）。当然现在只有增加一 个DrawCall（如多使用一个UIPanel或用另外一个Material)来做到Material的夹层效果。
特效层级：
粒子系统的渲染顺序列默认为3000 而NGUI的渲染顺序默认是从3000开始，当有嵌套的Panel或者Deoth更高的panel时，NGUI的渲染顺序会高于3000
解决方案：
1.修改Ngui中的panel脚本中的默认RenderQueue 调整到3000以下，这样就不会挡住粒子特效。当窗口显示在特效上面时把窗口的RenderQueue调整到3000以上，就解决了。
2.使用另外一个摄像机显示特效，但是Ui窗口切换时不太好控制
3.修改例子特效的shader中的RenderQueue的值（需要考虑特效中的层级关系）一级界面 二级界面..浮动窗口
1.不同图集
项目中做到复杂一些的界面，经常会用到多个图集，以技能界面为例，项目中常用的图片放到共用图集中，这是一个图集，技能界面本身独有的元素，比如跟技能职业相关的背景，算作第二个图集，还有一些技能图标，图标单独归类到一个图集中，再一个就是字体的图集。基本一个界面如此分法，最多需要4个图集。NGUI的图集之间的 处理，默认是靠调整控件的Z值来区分的，但是这里他可以调整同一个图集每个一个控件的Z值，其实不是很好。经常会出现图层相互遮挡的情况，尤其对于控件比较多的界面，一段时间回过来再修改界面的时候，整个要崩溃。
解决方案：在UIPanel中，为每一个Material添加一个layer的变量，当同一图层靠depth来决定前后关系，不同图层靠 layer来决定前后关系，在绘制UIDrawCall的时候，根据layer对跟节点做一定偏移。这样就能从Z值中解放出来。如果大家也有碰到图层的问题，可以参考这样的做法，以此种方法来处理图层关系，简单，做过项目的圈套UI，还未有不能解决的情况。
UI自适应
Scaling Style 的作用是制定UiRoot的缩放类型，如果是PixelPerfect ,Minimum Height 和Maximum Height 才起作用，scaling style 选择的是
Pixelperfect 要对Minimum Height和Maximum Height进行设置。(如果是PixelPerfect缩放类型，当屏幕的分辨率大于Maximum Height，则以Maximum Height 为基础缩放，反之，如果屏幕分辨率小于Minimum Height 则以Minimum Height为基础进行缩放。例如，如果屏幕高度为1000，而设置的Maximum Height值为800，则UI界面整体放大为原来的1000/800=1.25倍。)FixedSize : 跟Manual Height有关
FixedSizeOnMobiles :跟Manual Height有关
只是针对IOS和Android上的判断，也就是说只有IOS和Android平台下FixedSizeOnMobiles才起作用.FixedSize或FixedSizeOnMobiles，则缩放只以Manual Height为参考，屏幕分辨率的高度值不同于此设置值时，则根据其比例（即Screen Height / Manual Height）对整棵UI树的进行“等比”缩放（宽度的缩放比也是此比例值）。
注释：如果设置FixedSize,UIWidget.height（以UiRoot默认值进行高度缩放）是不会改变的，不管实际屏幕分辨率的像素是多少，Anchor Stretch的背景图片高度始终是manualHeight.UIRoot下的UIWidget的height参数一直都是实际的值
UIRoot 是基于高度进行缩放的如何做以宽度适配。
UIRoot是基于高度放缩的，即放缩的比例是以高度为参考的，所以UIRoot有一个manualHeight的参数。那么对于横版游戏显然不行，要是 能实现基于宽度放缩。所以可以通过设置一个“manualWidth”的参数来做。比如我们项目中使用的是 1024 作为UI的宽屏尺寸，通过换算设置manualHeight的值：
int height = Mathf.Max(2, Screen.height);manualHeight = Screen.height * 1024 / Screen.width;//基于宽度的屏幕分辨率自适应
注释：UIRoot其实就做了一件事情：根据Screen.height和UIRoot.activeHeight的比例来调整UIRoot的 loaclScal，从而保证UIWidget（UISprite，UILabel）可以按照其本身的大小进行设置，而不用经过复杂的换算过程。
资源分离打包与加载
资源分离打包与加载是最有效的减小安装包体积与运行时内存占用的手段。一般打包粒度越细，这两个指标就越小。但打包粒度也并不是越细就越好。如果运行时要同时加载大量小bundle，那么加载速度将会非常慢——时间都浪费在协程之间的调度和多批次的小I/O上了。此需要有策略地控制打包粒度。一般只分离字体和贴图这种体积较大的公用资源。
关闭贴图的读写选项
Unity中导入的每张贴图都有一个启用可读可写（Read/Write Enable）的开关，对应的参数是TextureImporter.isReadable。选中贴图后可在Import Setting选项卡中看到这个开关。只有打开这个开关才可以对贴图使用Textuer2D.GetPixel，读取或改写贴图资源的像素，但这就需要系统在内存中保留一份贴图的拷贝，以供Cpu访问，但是一般游戏运行过程中不会有这样的需求，因此我们对所有贴图都关闭这个开关，只在中做贴图导入后处理（比如对原始提贴图分离透明通道）时需要打开这个选项。这样，上文提到的1024x1024大小的贴图，其运行时的2MB内存占用又可以少一半，减小到1MB。Texture图片空间和内存占用分析
纹理大小影响：
可以将其他（非二的幂-“NPOT”）纹理大小用于 Unity非二的幂纹理大小通常占用的内存稍多一点，由 GPU 进行读取的速度可能较慢，因此考虑到性能，最好尽可能使用二的幂大小。如果平台或 GPU 不支持 NPOT 纹理大小，则 Unity 会缩放纹理并将其填补为下一个二的幂大小，这甚至会使用更多内存并使加载更慢
Iphone：
空项目
空间占用量42.3M
ipa包10M 10张1200*520 无压缩Texture 单张图占用量2.8M
空间占用两70.2M ipa包 22.9M 10张1200*520压缩成1024*1024 PVRTC4 单图占用量0.5M 空间占用量47.3M ipa包 13.2M 10张1024*1024 无压缩Texture
单图占用量4M
空间占用量82.M
ipa包14.6M 10张1024*1024压缩为PVRTVC4格式
单张图占用量0.5M 空间占用量 47.3M ipa包 11.6M
综上所述：
1.2的N次方大小的图片会得到引擎更大的支持，包括压缩比率，内存消耗 打包压缩大小，而且支持的力度非常大。
2.减小图片的占用大小和内存方式有：图片大小变化（Maxsize）,色彩位数变化（16位色 32位色），压缩PVRC格式
3.U3D对于图片的格式是自己生成的，而并不是你给它什么它用什么格式。一张1024*1024图在无压缩的格式下，他会被U3D无压缩文件像是存放，也就是说U3D 里的Texture Perview 里显示的占用大小**M 不只是内存占用的大小，还是空间占用大小。
Unity 图片压缩格式介绍：
U3D 的内部机制为自动生成图片类型来替代我们的图片在图片的压缩方式需要进行谨慎的选择。几种比较主要的压缩格式：
RGBA32 BIT/AutomaticTurecolor(256*256 256k)
格式为无压缩最保真格式，最消耗内存和空间的格式。RGBA16 BIT/
格式为无压缩16位格式，比32位节省一半的空间和内存，与Automatic16 相同。RGBA Compressed PVRTC 4bits格式为PVRTC 图片格式，它相当于把图片更改了压缩方式新生成了一个图片来替换原来的图片格式
贴图格式：
3D游戏中贴图的的分类：
UI贴图
ui是按照 1280*853比例出的图
3D场景贴图 主要是因为多重采样的缘故。3D游戏一般来说都是受摄像机远近大小改变而采取不同的采样大小，如果不设置多重采样的话，在远处有非常多的白色噪点。
2D游戏
所有都不需要勾选多重采样，具有3D性质的贴图，我们都需要勾选上GENERATE MIP MAPS，这样会使贴图大小增加25%这样。
正方贴图与非正方贴图也要区分: 非正方贴图只有16位的压缩（相当于真彩色减半），所以最好游戏中都是正方的贴图。正方贴图： IOS：
普通不透明： RGB PVRTC 4 BITS
普通透明： RGBA PVRTC 4 BITS(256*256 32kb)Androis:
普通不透明： RGB ETC 4 BITS(256*256 32kb)
普通透明：因为没有通用的兼容模式，所以一般情况是用RGBA 16 BITS 或是针对不同的GPU选择 DXT5/ATC8 BITS/ETC2 8BITS。如果技术支持，可以采用 RGB ETC 4 BITS 加一张Alpha 8的贴图来实现透明效果。
非正方形：
一般采用16位压缩，16位色会带来颜色损失，如果本来美术就按16位色画的话，就不会带来损失。日本的很多2D游戏都是采用那个16位来画的。少渐变 和艳色。
不透明贴图： RGB 16 BIT（256*256 128KB）
透明贴图： RGBA 16 BIT（256*256 128KB）
高清不压缩贴图：
RGBA 32 BIT(256*256 256kb)
对于不重要的贴图，模糊度低的贴图，建议不仅要采取像素压缩，还要直接压缩其大小。如光照贴图压到512或256。如背景原本1024的图直接压到256。玩家不注意到就可以了。
注意：
U3D所有图片的压缩格式都会以另一种方式存储，不会以你给的方式存储，只有你指定了某种格式，他才会转换成你要的格式。而且在Andriod 里的并不一定有效，因为Andriod的机型多，GPU的渲染方式也不一样，RGBA16 适应于所有机型
GameObject数量
场景中GameObject的数量也是衡量性能的重要指标，频繁的创建 和销毁GameObjec 是非常耗时，场景中存在的GameObject会占用内存，如果GameObject上挂有物体的话，每个GameOject的脚本都需要实力化。
整理图集
整理图集的主要目的是节省运行时内存（虽然有时也能起到合并DrawCall的作用）。从这个角度讲，显示一个界面时送进显存的图集尺寸之和是越小越好。一般有如下方法可以帮助我们做到这点： 1)在界面设计上，尽量让美术控件设计成九宫格拉伸，即UiSprite的类型是Sliced.这样美术素材可以切出一张很小的图片在unity中做拉伸。当然一个九宫格也就意味着其定点数量会从4个增加到16个（如果九宫格的中心格子采用Tiled做平铺类型的话，定点数会更多），构建DrawCall的开销会更大。但一般只要DrawCall安排合理就不会出问题 2)同样在界面设计上 尽量设计成对称的形式，这样在切图的时候美术切图的时候就可以只切一部分，我们在Untiy中将完整的图案拼出来，比如一个圆形图案我们可以只切四分之一，不过与上述第一点类似这样会增加定点个数，同时也会增加场景中GameObject的个数，因为GameObject的数量增多时会占用跟多的内存，所以只对尺寸较大的图案采用这种方法。3)4)确保不要让不必要的贴图素材驻留内存，更不要在渲染时将无关的贴图素材送进显存。为此需要将图集按照界面分开，按模块划分图集，一个界面中的UISprite也不要使用别的界面的图集。数量庞大 且数量不固定的物品不要使用图集 要采用UITexture 减少图集中的空白地方。完全透明的像素和不透明的像素所占用的空间是一样的，因此在像素量不变的情况下，要尽量减少图集中的空白。比如有时一张1024x1024的图集中，素材所占的面积还没超过一半，这时可以考虑将这张图集切成两张512x512的图集。（可能有人会问为什么不能做成一张1024x512的图集，这是因为iOS平台似乎要求送进显存的贴图一定是方形。）当然，两张不同图集的DrawCall是无法合并的，但这并不是什么问题。5)
根据各个UI控件的设计安放Panle,隔开DrawCall 在合并DrawCall时需要注意，如果将会移动变化的UI控件和一个静止不变的UI控件的DrawCall合在一起，当其中一个UI控件（UiWeight）的位置 大小 或颜色等属性发生变化时，UIPanle就需要重建这个Panle上的所有DrawCall。有时重建一个DrawCall会消耗不少的CPU，它需要计算这个DrawCall上的所有顶点信息，包括顶点位置 UV和颜色等，如果很多的控件都集中在同一个DrawCall上，那么其中一个控件上有一点点变化，这个DrawCall上的所有的顶点就都需要遍历一遍。而如果我们的UI又大量的采用九宫格拉伸，使控件的顶点数量就会变得更多。因此重建一个DrawCall 的开销会更大。
因此需要将UI控件分组，将一段时间内会发生变化的控件----比如怪物头顶的血条和伤害跳字放在同一个Panle上，并且这些Panle上只有这些控件，其余基本不变的控件放在别的控件Panle上，这样两类控件就隔开到不同的DrawCall在不同的Panle中，当一个控件发生变化而导致DrawCall重建时，就不需要遍历那些没有变化的控件。因为在美术设计上，一段时间内在变化的控件总是少数，所以优化效果十分明显，节省的CPU占用率能达到25%。
优化锚点内部逻辑，使其只在必要时更新
在上一点优化了Panel的DrawCall重建效率之后，我们发现NGUI锚点自身的更新逻辑也会消耗不少CPU开销。即使是在控件静止不动的情况下，控件的锚点也会每帧更新（见UIWidget.OnUpdate函数），而且它的更新是递归式的，使CPU占用率更高。因此我们修改了NGUI的内部代码，使锚点只在必要时更新。一般只在控件初始化和屏幕大小发生变化时更新即可。不过这个优化的代价是控件的顶点位置发生变化的时候（比如控件在运动，或控件大小改变等），上层逻辑需要自己负责更新锚点。
降低贴图分辨率
这一招说白了其实就是减小贴图素材的尺寸。比如对一张在原画里尺寸是100x80的贴图，我们将它导入Unity后会把它缩小到50x40，即缩小两倍。游戏实际使用的是缩小后的贴图。不过这一招是必然会显著降低美术品质的，美术立马会发现画面变得更模糊，因此一般不到程序撑不住的时候不会采用。
界面的延迟加载和定时卸载
如果一些界面的重要性较低，并且不常被使用，可以等到界面需要打开显示的时候才从bundle加载资源，并且在关闭时将自己卸载出内存，或者等过一段时间再卸载。不过这个方法有两个代价：一是会影响体验，玩家要求打开界面时，界面的显示会有延迟；二是更容易出bug，上层写逻辑时要考虑异步情况，当程序员要访问一个界面时，这个界面未必会在内存里。因此目前为止我们仍未实施该方案。目前只是进入一个新场景时，卸载上一个场景用到但新场景不会用到的界面。
避免频繁调用GameObject.SetActive 我们游戏的某些逻辑会在一帧内频繁调用GameObject.SetActive，显示或隐藏一些对象，数量达到一百多次之多。这类操作的CPU开销很大（尤其是NGUI的UIWidget在激活的时候会做很多初始化工作），而且会触发大量GC。后来我们改变了显示和隐藏对象的方法——让对象一直保持激活状态（activeInHierarchy为true），而原来的SetActive(false)改为将对象移到屏幕外，SetActive(true)改为将对象移回屏幕内。这样性能就好多了。
NGUI性能消耗点汇总
使用LinkedList
BetterList是一个数组 LinkedList
NGUI节点查找非常耗时。
代码中非必要的堆分配
1)
我们应避免使用foreach循环 ：一般建议是避免使用foreach循环，尽量使用for或者while循环，我在Unity论坛遇到很多人提到这个建议。这背后的原因咋一看似乎是合理的，foreach只是语法封装，因为编译器处理代码的流程大体是下面这样：
foreach（SomeType s in someList）s.DoSomething（）;转换为：
using（SomeType.Enumerator enumerator = this.someList.GetEnumerator（））{
while（enumerator.MoveNext（））{
SomeType s =（SomeType）enumerator.Current;s.DoSomething（）;} } 每次使用foreach时 都会创建一个enumerator 对象，一个System.Collections.IEnumerator的接口实例。但是创建在堆栈上还是堆上是都可能的 几乎所有的System.Collections.Genric(list
2)应该避免使用闭包和LINQ吗？
匿名方法和lambda表达式会引起内存泄露吗？答案是：这取决于C#编译器，有两种区别很大的方式来处理
int result = 0;void Update（）{
for（int i = 0;i < 100;i++）{
System.Func
现在我们在托管定义方式上做一些小小的改变：
System.Func
通过把“p”替换为“i++”，我们已经局部定义方法转变成一个真的闭包（闭包是函数编程的一大支柱。它把数据和函数联系到一起，更准确的说是非局部变量在函数之外定义。）在myFunc中，p是一个局部变量但i是一个非局部变量，属于Update()方法。C#编译器现在不得不将myFunc转换成可访问、甚至是可修改，包含非局部变量的方法。它通过声明一个全新的类表示myFunc创建的引用来实现这一功能。For循环每次执行都要分配一个类的实例，瞬间产生大量的内存泄露（在我的电脑上每帧26KB）闭包概念在C#3.0 的时候被引入主要原因是LINQ。如果闭包回引起内存泄露
3)协程
通过StartCoroutine()运行一个协程，会隐式分配Unity Coroutine类（系统上占用21字节）和Enumerator(占用16个字节)，所以在游戏运行时尽量少用StartCoroutine()
4)字符串
C#和Unity内存问题必须会提到字符串。从内存角度，字符串很奇怪，因为，他们是堆分配且不变的。当你连接两个字符串时（无论是变量还是常量）：运行时不得不分配至少一个新的字符串对象存储新的结果。String.Concat()有效地通过调用FastAllocateString()分配新对象，但是必定会产生多余的堆分配（上面例子在我的系统上占用40字节）。如果你需要在运行时修改或者连接字符串，最好使用 System.Text.StringBuilder
5)装箱
尽量减少装箱
6)库方法
各种库方法也会隐式分配内存。捕捉它们最好的方法是分析。我之前已经写过的 foreach-循环，大多数标准泛型集合不会导致堆分配。Dictionary
查找堆分配的两种方式 1.使用Unity profiler 2.反编译自己的代码
在CIL中查找内存分配
CIL代码的优势在于堆分配代码不会被隐藏。相反，完全可以在反编译的代码中找到堆分配的三种指令。
1)
newobj
2)
newarr <元素类型>：在堆上创建一个数组。元素类型在参数中指定。
3)
box <值类型标记>：装箱（传递数据）专用指令，在第一部分已经介绍过。
Unity脚本执行顺序和编译顺序 1)脚本执行顺序
Unity 在后台会把每个脚本的 Awake、Start、Update、LateUpdate、FixedUpdate 等等，所有的方法合并到一起。然后按照 代码的执行顺序进行执行。
编译顺序
首先从脚本语言类型来看，Unity3d支持3种脚本语言，都会被编译成CLI的DLL 如果项目中包含有C#脚本，那么Unity3d会产生以Assembly-CSharp为前缀的工程，名字中包含”vs”的是产生给Vistual Studio使用的，不包含”vs”的是产生给MonoDevelop使用的。
对于每一种脚本语言，根据脚本放置的位置(其实也部分根据脚本的作用，比如编辑器扩展脚本，就必须放在Editor文件夹下)，Unity会生成4中后缀的工程。其中的firstpass表示先编译，Editor表示放在Editor文件夹下的脚本。
Assembly-CSharp-filepass-vs.csproj Assembly-CSharp-Editor-filepass-vs.csproj Assembly-CSharp-vs.csproj Assembly-CSharp-Editor-vs.csproj 根据官方的解释，它们的编译顺序如下：
(1)所有在Standard Assets、Pro Standard Assets或者Plugins文件夹中的脚本会产生一个Assembly-CSharp-filepass-vs.csproj文件，并且先编译；
(2)所有在Standard Assets/Editor、Pro Standard Assets/Editor或者Plugins/Editor文件夹中的脚本产生Assembly-CSharp-Editor-filepass-vs.csproj工程文件，接着编译；
(3)所有在Assets/Editor外面的，并且不在(1),(2)中的脚本文件(一般这些脚本就是我们自己写的非编辑器扩展脚本)会产生Assembly-CSharp-vs.csproj工程文件，被编译；
(4)所有在Assets/Editor中的脚本产生一个Assembly-CSharp-Editor-vs.csproj工程文件，被编译。
之所以按照这样建立工程并按此顺序编译，也是因为DLL间存在的依赖关系所决定的。好了，到此为止，我们可以很容易地判断出上面举的实例中，脚本的编译顺序(实际上，我已经把顺序写在了脚本的文件名中了)一个Unity3d的工程中，最多可以产生多少个工程文件呢？
4*3*2=24
4个文件 3中编译器 2种平台 1 个工程
IOS平台崩溃的几种情况。
1．在协程中要判断对象是不是为空(list GameObject)在每次调用的时候都学要调用（因 为协程不能保证即使调用如果对象已销毁但是依然使用时会卡死）。
2． Delegate的判断（IOS 尽量使Event）
3． 如果引用静态的static Compent的组件会出现卡死
4． Unity中的OnEnable Start Awake Disable Destory()都回延迟一帧 5． Unity在Ios对反射的支持不完整。
6． Awake 和Start函数执行时机, Awake 函数在这个脚本在场景中加载时就会调用，需要注意的是，Start函数也不是一定立即执行的，它是在该脚本第一次调用Update函数之前调用的，也就是说，如果这个脚本一开始的状态是disable的，那么直到它变成enable状态，在Update函数第一次执行前，才会执行Start函数。
7．Linq TO XML
untiy中配置文件需要注意的点：
pc端不区分文件大小写。
Andriod不区分大小写
Ios移动端区分文件大小写。
需要注意文件名称大小写。
资源优化(内存优化)：
1．代码中申请的内存，一般是New 或者Instantiate操作 Instantiate中也是调用了New 2．及时设置释放标识符 变量设置为Null 超出变量作用域 Destory()3．及时Gc释放内存 需要注意
Gc时会造成游戏短时间的卡顿，影响游戏体验 需要选择合适的时间Gc 4．尽可能的重用资源（贴图 材质 网格）
5．一般图片资源占用的内存最大，优化效果最明显（降低贴图分辨率，在效果和大小之间找一个平横点）
6．程序中的内存池 对象池 必要时主动释放内存
7．做AssetBundle资源的关系以来打包 动态加载
卸载
8．C#中Struct数据在栈上 Class在堆上 局部数据尽量用Struct 减少Gc的频率 9．按C++ 的思想来管理内存，比如使用的内存池，对象池 手工卸载 主动Gc 注意在内存和帧率之间做好平衡。
10．www 下载时需要注意变量声明和要注意申请的内存堆上的无用内存
11． Unity资源（加载/更新）
1.Resources
-打包集成到.asset文件里面及引用的资源as后se一个文件里面面可读不可写无
-只能用WWW类下载
StreamingAssets文件夹也是一个只读的文件夹，但是它和Resources有点区别，Resources文件夹下的资源会进行一次压缩，而且也会加密，不使用点特殊办法是拿不到原始资源的。但是StreamingAssets文件夹就不一样了，它下面的所有资源不会被加密，然后是原封不动的打包到发布包中，这样很容易就拿到 里面的文件。所以StreamingAssets适合放一些二进制文件，而Resources更适合放一些GameObject和Object文件。StreamingAssets 只能用过www类来读取。
最后凡是在Hierarchy视图对象引用过的资源文件也会被无条件打包到发布包中。如果有一部分文件可能没有在Resources文件 夹下也没有在StreamingAssets文件夹下，也没有被Hierarchy视图游戏对象引用，那么这类资源是不会被打包到发布包中的。
3.PersistentDataPath无
-清除手机缓存文件会一并清理这里的东西
-随意弄，可作为本地目录让WWW下载、也可以自己用FileInfo乱整
4.WWW.LoadFromCacheOrDownload
Unity常用目录对应的Android && iOS平台地址
IOS:
Application.dataPath : Application/xxxxx/xxx.app/Data Application.streamingAssetsPath : Application/xxxxx/xxx.app/Data/Raw Application.persistentDataPath : Application/xxxxx/Documents Application.temporaryCachePath : Application/xxxxx/Library/Caches
Android:
Application.dataPath : /data/app/xxx.xxx.xxx.apk Application.streamingAssetsPath : jar:file:///data/app/xxx.xxx.xxx.apk/!/assets Application.persistentDataPath : /data/data/xxx.xxx.xxx/files Application.temporaryCachePath : /data/data/xxx.xxx.xxx/cache
Unity的Android和IOS上相关的目录结构
Android:
-assets 游戏内容相关的都在这里了res 图标之类的
-AndroidManifest.xml Android配置文件resources.arsc Java编译后的二进制文件
IOS:
-level0/level1… Scene
-sharedassets0/shaedassets1/… Scene相关的东西resources.assets Resources里面的东西-Raw StreamingAssets里面的东西
第二篇：Hamlet --- The unity of controverasal
Hamlet
---The combination of contradiction
As the saying goes, one thousand readers, there are one thousand Hamlets.Others may think he is a soldier, a hero or a thinker.However, in my mind, he is an immature teen-age youth who is the combination of contradictions.Firstly, as a prince, he is an idealist.He lives a luxurious life and is educated by humanism.Without knowing the dark aspects of the society, he is favored by his parents and respected by his people.We can see in the play that he believes the true, the good and the beautiful and he is a real perfectionist, which can also explain why he is so shocked by the things happen on him and doesn’t know how to deal with it perfectly.Experiencing the death of his father, the usurping the throne of his uncle and the remarriage of his mother, Hamlet’s dream turns into bubbles.He falls in to hell from the heaven and goes on the trip of revenge.The prince has to have common people’s feeling, sadness, hatred, disappointment, hypocrisy and so on.Secondly, he is definitely a great thinker but also an ordinary people who hesitates to practice his thought.He begins consider himself and his people after he listen to his dead Father King’s words.He even says “To be or not to be, this is a question: was bear the slings and arrows of outrageous fortune, or to take arms against a sea of troubles world, through the clearing their struggle, these two kinds of behavior, which is a more noble.” He falls in to deep thought and condemns himself.His father is murdered and the ghost of his father urges him to take the revenge.He doesn’t do anything.He wonders: how a coward or a indecent woman I am.He not only thinks of his own fate, but also considers everyone’s existence.There is no doubt that he is the great man of mind.“Now I clearly have reason, have the determination and have the strength, have a way of can start to do what I have to do, but I still in touted said: 'it needs to do.'But never expressed in action…” is the evidence for his hesitation.When his enemy is praying and he plans to kill him, he should consider that killing a man who is praying will allows him to go to haven, which makes him lose the chance to kill his uncle and commit the tragedy.Thirdly, he believes the true, the good and the beautiful, but he doesn’t believe his friends and his lover.It is his behavior that makes Ophelia dead.He pretends to be mad and kill her father by accident.Ophelia can’t bear the reality and goes to the place where she dates with her prince madly… His ignorance of others’ care and arrogance kill other four innocent people.Last but not least, he is the combination of the goodness and evil.On the one hand, he is pious to his parents, his girlfriend and his friends in a way.He bears the responsibility to take revenge on his uncle and to save the ordinary people.He tries his best to satisfy everyone but he also hurts many people.He takes his revenge on his uncle by hook or by crook.He kills Rosencrantz and Guildenstern.He is cold when he kills Polonius and heartless to Ophelia.Not merely does he lead to his own tragedy, but also leads to the whole play’s tragedy.All in all, the dejected prince wants to take revenge on his uncle, but he can’t find a proper way and his ability is not equal to his ambition.He is an idealist who has to face the cruel reality.As a great think who believes the true, the good and the beautiful, he hesitates to take the action and doubt everyone around him.He is the saver and also the destroyer.He is a giant and also an ordinary people.He is a noble prince and also an immature teen-age youth.
第三篇：unity烘焙光照贴图
引言: 光影烘焙，英文叫Lightmapping 或 light baking。Unity自带了Lightmapping的功能(是Illuminate Labs出的名为Beast的产品)。本系列教程分为4讲： 第一讲 光影烘焙 第二讲 AreaLight 第三讲 Light Probes 第四讲 脚本控制
其中第三第四讲讲解的是动态物体与烘焙后场景的融合。
光影烘焙
打开方式 Window – Lightmapping 有几点需要注意：
1.所要烘焙物体的mesh 必须要有合适的lightmapping uv。如果不确定的话，就在导入模型设置中勾选 Generate Lightmap UVs 2.任何Mesh Renderer, Skinned Mesh Renderer 或者 Terrain都要标注为static(lightmap static)
界面一：Object 点击Bake Scene即开始烘焙
界面2：Bake 烘焙参数的设置 Mode:(1)Dual Lightmap mode:近景烘焙图(near lightmaps)和远景烘焙图(far lightmaps)都会被烘焙，只有deferred rendering path支持该模式。
(2)Single Lightmap mode:只有远景烘焙图(far lightmaps)会被烘焙，(3)Directional Lightmap mode： Use in forward rendering: 一般可以忽略它。针对Dual lightmaps的设定,只在Mode选的是Dual时才会出现。在forward rendering模式下是否激活dual lightmaps,需要自己写对应的Shader。Quality：
High low 2个选项。决定采集射线的数量，对比界限，以及反锯齿等设置。Bounces：
Global Illumination模拟中 light bounces的数量。0表示只有直接光照会被计算，如果要加入柔软的，真实的间接光照的话，则至少填1。Sky Light Color：
模拟从天空从所有方向射来的光照。对室外场景很重要。
(注意：RenderSettings里的Ambient Light也参与烘焙，并且会覆盖Sky Light。所以使用Sky Light的话，则需要关闭Ambient Light,把Ambient调成（0,0,0,0）即可)Sky Light Intensity：Sky Light的强度。0表示关闭Sky Light.Bounce Boost：加强Bounced light也就是间接光照的效果.Bounce Intensity：间接光照的效果强度。
Final Gather Rays:从所有收集的点发射的射线的数量，最高则效果最好。默认为1000 Contrast Threshold: 越高表示光照越平滑同时细节越低
Interpolation：颜色计算方式。0表示线性插值，1表示基于梯度的高级插值。有时1会产生人工光照的失真效果。
Interpolation Points:越多表示光照越平滑同时细节越低。
Ambient Occlusion：环境闭塞（全局闭塞）在烘焙中的量，和光照无关，仅仅基于距离的效果
Lock Atlas：锁上了，贴图就不会变化，没什么用。Resolution：
通常来说 Resolution设置平均每单位面积对应lightmap的多少色素。该值越高代表单位面积的色素越多即越精细。反之越低越粗糙。默认值为50。如果一个10x10的plane,resolution是50的话，在lightmap里该plane就占用500x500像素尺寸。
当然也可以单调该数值。选中物体后，在lightmapping界面中会有Scale in lightmap的数值，表示的是该物体的烘焙信息在lightmap占的大小，1表示正常尺寸。0表示该物体没有lightmap效果，但会影响其他物体的lightmap运算。2表示正常尺寸的两倍大小。Padding:在lightmap里,不同物体的烘焙图的间距，单位为图素(texel)
界面3:Maps 烘焙好后的map在这里显示。Compressed： 是否压缩lightmap Array Size（0~254）lightmaps array的尺寸
Lightmaps array:即下方的4张贴图，空格会被视为黑图，指数即下方的 0,1对应Mesh Renderer及Terrain里的lightmap index。这个会自动计算。
按下烘焙后，会在右下角有进度条显示。然后你就可以去喝喝咖啡泡泡妹子神马的，放心，它烘焙好了会有Import asset提示并自动切回Unity的。烘焙好之后，会产生与场景名称相同的文件夹，一般来说会有两张.exr贴图，LightmapFar-0和LightmapNear-0(仅在Dual模式下有near图),当物体距离摄像机小于Shadow Distance时，使用的是 实时灯 + LightmapNear-0。当大于是使用的是LightmapFar-0，此时灯光对物体不起作用。
(注意：Shadow Distance的设置
(1)如果是编辑器里运行：Lightmap display设置界面里的Shadow Distance,如下方左图(2)如果实际运行: Quality设置下的Shadow Distance，如下方右图
Lightmap Display界面里的其他设置: Use Lightmaps：是否使用lightmaps,不勾选的话就没有任何烘焙的效果了。
Show Resolution：当勾选Show Resolution时，会有下图所示类似国际象棋黑白相间的格子，一个格子对应lightmap里所占用的一个texel Show Probes:是否显示light probes,后面会讲到。Show Cells:light probes分割形成的空间的数量。
当物体烘焙好之后，不管是复制物体还是把物体做成prefab,都会继承烘焙的效果。但是如果缩放的话，烘焙好的光容易出现问题。
被烘焙的物体并不要求特定的材质或者Shader。只要物体的Shader使用的是Surface Shader,那么就可以被烘焙。
注意：一个场景只能烘焙一次，如果多次烘焙，效果是最后一次烘焙的效果。
最后推荐ShadowGun里的烘焙配置，如下图，供大家参考。烘焙时间很短，效果也很好。极力建议大家搜下ShadowGun的demo来参考学习。里面无论是场景布局，光影分配，Godrays运用，及烘焙等等都是极高的水准。
第四篇：unity开发游戏的优缺点
Unity做游戏的几个优势：
1、跨平台，平台相关的功能Unity都已经帮你实现好了。即便有些Unity没有实现，也有插件帮你实现。
2、基于Unity的酷炫的粒子光效编辑。Unity本身就是一个功能强大的粒子编辑器。之前我还认为cocos2d-x的粒子系统的功能足够了，但是跟专业的编辑器比起来，远远不够。粒子系统要跟粒子特效编辑器配合起来，其功能远远不是之配置一个粒子系统的几个参数就可以的。cocos2d-x本身的粒子系统是很鸡肋的功能，只能拿来做一些简单的光效，不可能用来做复杂的技能特效。
3、由于框架和架构的优势，Unity的游戏可以极大程度避免崩溃和闪退。由于代码都是c#写的，并且是组件结构，所以即便出了错误也只是个异常而已，而不会影响到系统流程。
4、强大的性能分析工具，可以轻易的找到内存和cpu的瓶颈。支持Android和iOS的真机运行分析。
5、编辑器可以方便的进行扩展，不需要像传统游戏公司一样，有一个专门写编辑器的部门。无论是场景编辑器还是技能编辑器都可以轻松搞定。如果想玩高科技的话，还可以把技能编辑器做成可拖拽的模块化结构，策划可以像搭积木一样来编辑技能。最重要的是，这些都是所见即所得的。
6、方便的资源管理系统。使用Unity，你不用特意维护几份资源（比如原始资源、打包后的资源、iOS版本资源、Android版本资源等等），只要一份资源，然后Unity里面可以设置它的具体参数，比如使用纹理压缩、最大限制在512x512大小等等。Unity发布游戏的时候会自动根据平台相关的导出选项导出正确的资源。
7、丰富的插件。有大量的功能我无论拿cocos2d-x还是Unity都不知道怎么实现。比如一些shader特效、物件碎裂的特效、场景破坏和变形的特效等等，这些在Unity插件中都可以找到对应的实现。而且很多Unity的游戏都可以反编译，无形中又可以学到很多东西。
8、熟悉之后确实感觉Unity很简单。很多功能都是成体系的自然而然的。比如物理、碰撞检测、导航寻路、场景管理、场景烘焙。这些无论拿哪个出来都是相当有技术的功能，但是在Unity中几个按钮、几步操作就可以实现对应的功能。
至于缺点也有一些：
1、最主要的，无论是Unity还是插件都是要收费的。（破解版，等赚钱了再考虑回馈）
2、由于iOS平台的一些限制，Unity很难做动态代码更新。而cocos2d-x有lua这个比较成熟的方案。（如果程序稳定了，需要频繁更新代码的机会不多，更多的是更新配置和资源）
3、可能有些人不熟悉Unity，从而选择了开源的cocos2d-x。适应Unity的框架、工作方式需要一定的时间。（相信我，不会很长，要知道一个8岁的孩子都能拿Unity来做游戏，并且上架，如果有程序员说搞不定Unity，那干脆转行卖烧饼吧）
4、对应上面的第6点，由于Unity中资源对应的配置有很大的重要性，所以一个Unity功能就是资源+代码的整合，你很难分出一个资源包。这样你的Unity项目可能很大。（使用AssetsBundle打包后可能避免这个问题，但是项目初期资源变动大，经常打包很不方便）
5、Unity很多设计都是为可视化编辑考虑的，举个例子，2D的动画可以方便的拖几张图片就可以搞定。但是如果我每张图片都有一定的偏移，那就麻烦了，需要自己重新实现帧动画功能，自己加载配置文件来实现。（这个严格说来不是引擎的问题，毕竟引擎不是为了一家游戏公司设计的，大众化的简易的操作方式是唯一需要考虑的。但是很多时候确实感觉有些不爽）
第五篇：Unity 3D的学习报告
Unity 3D的学习报告
刘卉
数媒0902班
0305090205 学习总结：
刚开始这门课程的时候，其实心里是比较恐惧的，因为对Unity 3D这样的软件完全没有认知，对于这门课程的学习也处于比较茫然的状态，可以说是抱着尝试的心情开始这门课程的学习的。开始使用软件的时候，不知道从何下手，于是试着对照书本操作，渐渐地，我发现其实并没有我想象中那么困难，一般的操作还是能够在书本上学到的，可能最终完全掌握会有难度，但是对于目前的要求，还是比较易于实现的。在学习并实践的过程中，可能在脚本游戏的代码编写上还是出现最多问题的，有的时候就是照搬书本上的代码，也会出错，不仅仅是粗心，也是我对于代码并不熟悉导致的，在一遍遍的修改中，我对代码的编写也更加熟练，相比较之前的生疏，现在算是比较得心应手了。此外，比较困扰我的就是摄像机位置的各方面调整，有的时候很难调整到想要的角度，最后只能将就，这点让我很是纠结。对于这种情况，我试着各种方法达到理想效果，如果说我改变不了摄像机，那我只能改变我设置的场景、对象的位置了，虽然这样的方法比较笨，而且可能会比较繁琐，但是最终也帮助我实现了想要达到的效果。
也许是为了完成这门课的要求，也许是为了交作业，我最终还是自己尝试着学习了Unity 3D的操作，可能我所做所学的都是基础的知识，相对简单的，但是我还是学到了很多，不能说了解但也是熟悉了这个软件。可能我做的东西不是很理想的，希望我能在日后的学习实践中一点一点的去完善。
学习日志：
2012年9月20日
今天在电脑上安装了Unity3D软件，安装的过程有点纠结，但最后还是安装完成了。翻阅《Unity3D游戏开发》这本书，了解了第一章基础知识的内容。
2012年9月21日
打开Unity3D软件，跟着书本试着操作。看书上第二章的内容，一步步学习：创建工程——创建材质——创建游戏对象——赋予材质——调节摄像机位置，初步创建了“正方体”对象。
2012年9月24日
又到了周一，继续学习操作啦。今天学习“移动试图”，通过创建游戏脚本，做了平移、旋转和缩放的调整，并且编写代码，使对象动起来。使用21号做的正方体，最终实现了移动和旋转的效果。
2012年9月27日
今天我照着书中第二章第7小节的内容，完成第一个游戏实例。虽然最终完成了，但实现的过程并不顺利，光摄像机位置的调节就花了很长时间，然后每个对象位置的调整、材质的颜色还算顺利，最后就是创建脚本游戏的时候，按照书上的编写代码，却总是出错，最后发现原来是这些原因：代码位置写错、部分首字母小写却被我写成了大写、空格多加了。
2012年10月9日
放假归来以后，开始书本第三章以后内容的学习。我按照书本的内容先将第三章的每一小节浏览了一遍，了解了大概的内容。试着对照书本完成了一个GUI控件的脚本实例，其中包括各个控件的设置，代码的编写，中间也出现很多错误，最终在同学的帮助下，终于运行成功。
2012年10月10日
今天继续第三章的内容，学习了游戏界面的布局和贴图的绘制。试着完成“人物移动”的实例，各种问题逐渐显露出来：代码出错、摄像机位置摆不好、人物移动方式不如我愿，总之是在挫败中结束了学习。
2012年10月12日
今天又把上次没完成的“人物移动”拿出来继续修改。我回顾了书本第三章的内容，重新创建工程，试着完成各项操作。首先我先再次学习了添加与关闭窗口，又开始了贴图的学习和绘制动画。将贴图以材质的形式绘制在游戏对象中，且在Project视图中需要加载的图片存储在根目录“Resources”中。而动画则是使用程序将动画资源存储在动画数组中，然后设定动画的刷新时间，每次刷新动画时在原有的显示区域绘制下一帧图片，到了最后一帧则从第一帧重复开始，依此类推。相比较而已，这部分会比较有趣的。
2012年10月13日
终于，今天我实现了“人物移动”这个实例。可能是之前太心急，前面部分知识还没学习，就直接做实例，通过昨天的学习，再加上今天的努力，前天的难题都不再是难题，很快，我就做好了。
2012年10月18日
偷懒了很多天，今天我开始第四章的学习。这次我没有急着做案例，我认真的研究了书本。
2012年10月22日
学习了第五章的理论知识。知道了地形的参数包括地形的宽度、高度、长度、分辨率和高度图等。总之，今天学习了创建地形，地形参数，编辑地形和地形贴图的内容。
2012年10月23日
学习了书中实例“摄像机切换镜头”。
2012年10月29日
今天学习了第7章的输入与控制的键盘事件。通过键盘的按下事件、抬起事件、任意键事件和组合键事件等实现交互这样的功能。这部分的内容可能实践更重要，今天先进行理论知识的学习，明天试着操作一下。除此之外，还学习了鼠标事件、自定义按键事件、模型与动画和GL图像库的一部分内容。鼠标事件就是鼠标按下事件、抬起事件、长按事件。自定义按键是在输入管理器中配置，自定义按键可以设置轴向，按键轴的数值默认为0。另外，我尝试模型的载入、设置3D动画和播放动画等内容，可以说忙的不亦乐乎。
2012年10月30日
将昨天所学操作了一下。
2012年11月02日
试着做“运动员踢足球”小游戏，包括场景的构建、人物的构建和移动、球的移动等等。首先我参考书中第五章内容创建地形，添加地形元素，添加天空，导入了3D人物模型，以及创建了一个球形对象。将人物运动控制脚本绑定人物模型，球体运动脚本绑定球。
2012年11月05日
今天将书上8、9、10章没有阅读过的部分看了一遍，了解了一些操作的大概原理，试着学习书上的案例操作部分内容，完善所学知识。
点击咨询 