扫一扫，访问微社区
后使用快捷导航没有帐号？
签到成功!您今天第{todayrank}个签到，签到排名竞争激烈，记得每天都来签到哦！已连续签到:{constant}天，累计签到:{days}天
Unity3D 性能优化
阅读&860 |
一直一来都想发表一篇属于自己的文章，最近在整理unity相关的技术文档，于是针对目前项目的优化查阅了很久前找的资料，针对之前的资料做出新的整理，这里参考了部分大神总结的优化解决方案，但是由于之前都是复制的文本，因此也找不到连接了，在此深表感谢，别怪我盗贴啊，废话不多说，开始正题。Unity性能优化本文主要从三个方面进行说明：CPU、GPU、和内存。一、CPU的方面的优化：CPU优化方向：1、DrawCalls2、物理组件（Physics）3、GC（GC为处理内存，此项为CPU使用GC处理内存时产生的性能损耗）4、程序代码&Drawcalls：Drawcall是啥？其实就是对底层图形程序（比如：OpenGL&ES)接口的调用，以在屏幕上画出东西。如何优化：1）使用Draw&Call&Batching，也就是描绘调用批处理。Unity在运行时可以将一些物体进行合并，从而用一个描绘调用来渲染他们。静态批处理Static&Batching，只要是静态不动的物体且具有相同材质的话就可以使用静态批处理来降低描绘调用（注：shader不同则会增加纹理的拼合降低渲染效率）动态批处理Dynamic&Batching：动态批处理是引擎自动进行，无需设置，当物体共享相同的材质，则引擎就会自动对Drawcall进行优化，也就是动态批处理（如实例化预制件）。动态批处理存在约束，稍有不慎就会增加Drawcall动态批处理的约束：1、批处理动态物体需要在每个顶点上进行一定的开销，所以动态批处理仅支持小于900顶点的网格物体。2、如果你的着色器使用顶点位置，法线和UV值三种属性，那么你只能批处理300顶点以下的物体；如果你的着色器需要使用顶点位置，法线，UV0，UV1和切向量，那你只能批处理180顶点以下的物体。3、不要使用缩放。分别拥有缩放大小(1,1,1)&和(2,2,2)的两个物体将不会进行批处理。4、统一缩放的物体不会与非统一缩放的物体进行批处理。5、使用缩放尺度(1,1,1)&和&(1,2,1)的两个物体将不会进行批处理，但是使用缩放尺度(1,2,1)&和(1,3,1)的两个物体将可以进行批处理。6、使用不同材质的实例化物体（instance）将会导致批处理失败。7、拥有lightmap的物体含有额外（隐藏）的材质属性，比如：lightmap的偏移和缩放系数等。所以，拥有lightmap的物体将不会进行批处理（除非他们指向lightmap的同一部分）。8、多通道的shader会妨碍批处理操作。比如，几乎unity中所有的着色器在前向渲染中都支持多个光源，并为它们有效地开辟多个通道。9、预设体的实例会自动地使用相同的网格模型和材质。所以尽量使用静态批处理。2）NGUI和UGUI需将同一界面的UI元素打包图集。&物理组件：1）设置Fixed&timestep，减少物理计算次数，提高游戏性能。2）减少FPS，在ProjectSetting-&&Quality中的VSync&Count&参数会影响你的FPS，EveryVBlank相当于FPS=60，EverySecondVBlank&=&30；这两种情况都不符合游戏的FPS的话，我们需要手动调整FPS，首先关闭垂直同步这个功能，然后在代码的Awake方法里手动设置FPS（Application.targetFrameRate&=&45;） 降低FPS的好处： 1.省电，减少手机发热的情况； 2.能都稳定游戏FPS，减少出现卡顿的情况。关于垂直同步：什么是垂直同步，简单来说就是显示器上的所有图像都是一线一线扫描上去的，显示器都有两种同步参数，水平和垂直同步，水平同步信号决定画出一条屏幕横线的时间，垂直决定从屏幕顶部画一条线到底部，再返回原位置的时间，垂直同步决定了显示器的刷新水平，如果选择了等待同步信号，但是比较强的显卡会迅速绘制完一屏的图像，但是没有垂直同步信号的到达，显示器无法绘制下一屏，所以操作系统刷新率会制约FPS,如果选择不等待，即关闭垂直同步，那就会提升性能，发挥显卡的最大性能，但是有个弊端，就是正是因为垂直同步的存在才使得游戏进程和显示器刷新率同步，使得画面变得更加平滑和稳定。因此是否关闭垂直同步提升帧数需要酌情考虑。3）尽量不用MeshCollider如果可以的话，尽量不用MeshCollider，以节省不必要的开销。如果不能避免的话，尽量用减少Mesh的面片数，或用较少面片的代理体来代替。4）粒子组件，屏幕上最大粒子数量建议小于200个，粒子应尽可能的小，关闭粒子的碰撞功能。&GC：虽然GC是用来处理内存的，但是却会增加CPU的开销，首先我们要明确所谓的GC是Mono运行时的机制，而非引擎的机制，所以GC也主要是针对Mono的对象来说的，而它管理的也是Mono的托管堆。&搞清楚这一点，你也就明白了GC不是用来处理引擎的assets（纹理啦，音效啦等等）的内存释放的，因为引擎也有自己的内存堆而不是和Mono一起使用所谓的托管堆。其次我们要搞清楚什么东西会被分配到托管堆上？不错咯，就是引用类型咯。比如类的实例，字符串，数组等等。而作为int，float，包括结构体struct其实都是值类型，它们会被分配在堆栈上而非堆上。所以我们关注的对象无外乎就是类实例，字符串，数组这些了。所以GC的优化说白了也就是代码的优化。此部分的代码优化只针对是否会触发GC：1）字符串处理。如频繁操作单个字符串使用StringBuilder2）尽量不要使用foreach，而是使用for。foreach其实会涉及到迭代器的使用，而据传说每一次循环所产生的迭代器会带来24&Bytes的垃圾。那么循环10次就是240Bytes。3）不要直接访问gameobject的tag属性。比如if&(go.tag&==&“human”)最好换成if&(go.CompareTag&(“human”))。因为访问物体的tag属性会在堆上额外的分配空间。如果在循环中这么处理，留下的垃圾就可想而知了。4）使用“池”，以实现空间的重复利用。5）最好不用LINQ的命令，因为它们会分配临时的空间，同样也是GC收集的目标。&代码：1）不要频繁使用GetComponent去频繁获取组件，如使用可在Awake函数中持有引用。2）善于使用OnBecameVisible()和OnBecameVisible()来控制物体的Update()函数的执行以减少开销。3）使用内建数组如使用Vector3.zero而不是new&Vector(0,0,0);4）数组、集合类元素优先使用Array，其次是L5）脚本在不使用时脚本禁用之，需要时再启用;6）可以使用Ray来代替OnMouseXXX类方法7）尽量少用模运算和除法运算，比如a/5f，一定要写成a*0.2f8）不要使用原生的GUI方法&二、GPU的优化：GPU优化方向：1.填充率，可以简单的理解为图形处理单元每秒渲染的像素数量。2.像素的复杂度，比如动态阴影，光照，复杂的shader等等3.几何体的复杂度（顶点数量）4.当然还有GPU的显存带宽针对以上4点，可以发现影响GPU性能的无非就是两个方面，一是定点过多，即模型复杂面数多，另一个就是GPU的显存带宽。&减少绘制数目：1）保持材质的数目尽可能少。这使得Unity更容易进行批处理。2）使用纹理图集（一张大贴图里包含了很多子贴图）来代替一系列单独的小贴图。它们可以更快地被加载，具有很少的状态转换，而且批处理更友好。3）如果使用了纹理图集和共享材质，使用Renderer.sharedMaterial&来代替Renderer.material&。4）使用光照纹理(lightmap)而非实时灯光。5）使用LOD，好处就是对那些离得远，看不清的物体的细节可以忽略。6）遮挡剔除（Occlusion&culling）优化显存带宽：1）压缩图片，减小显存带宽的压力。2）使用mipmap。Mipmap中每一个层级的小图都是主图的一个特定比例的缩小细节的复制品。因为存了主图和它的那些缩小的复制品，所以内存占用会比之前大。但是为何又优化了显存带宽呢？因为可以根据实际情况，选择适合的小图来渲染。所以，虽然会消耗一些内存，但是为了图片渲染的质量（比压缩要好），这种方式也是推荐的。&三、内存的优化：Unity中的内存种类实际上Unity游戏使用的内存一共有三种：程序代码、托管堆（Managed&Heap）以及本机堆（Native&Heap）。程序代码包括了所有的Unity引擎，使用的库，以及你所写的所有的游戏代码。在编译后，得到的运行文件将会被加载到设备中执行，并占用一定内存。这部分内存实际上是没有办法去“管理”的，它们将在内存中从一开始到最后一直存在。一个空的Unity默认场景，什么代码都不放，在iOS设备上占&用内存应该在17MB左右，而加上一些自己的代码很容易就飙到20MB左右。想要减少这部分内存的使用，能做的就是减少使用的库，稍后再说。托管堆是被Mono使用的一部分内存。Mono项目一个开源的.net框架的一种实现，对于Unity开发，其实充当了基本类库的角色。托管堆用来存放类的实例（比如用new生成的列表，实例中的各种声明的变量等）。“托管”的意思是Mono“应该”自动地改变堆的大小来适应你所需要的内存，并且定时地使用垃圾回收（GC）来释放已经不需要的内存。关键在于，有时候你会忘记清除对已经不需要再使用的内存的引用，从而导致Mono认为这块内存一直有用，而无法回收。 本机堆是Unity引擎进行申请和操作的地方，比如贴图，音效，关卡数据等。Unity使用了自己的一套内存管理机制来使这块内存具有和托管堆类似的功能。基本理念是，如果在这个关卡里需要某个资源，那么在需要时就加载，之后在没有任何引用时进行卸载。听起来很美好也和托管堆一样，但是由于Unity有一套自动加载和卸载资源的机制，让两者变得差别很大。自动加载资源可以为开发者省不少事儿，但是同时也意味着开发者失去了手动管理所有加载资源的权力，这非常容易导致大量的内存占用（贴图什么的你懂的），也是Unity给人留下“吃内存”印象的罪魁祸首。&优化程序代码的内存占用这部分的优化相对简单，因为能做的事情并不多：主要就是减少打包时的引用库，改一改build设置即可。对于一个新项目来说不会有太大问题，但是如果是已经存在的项目，可能改变会导致原来所需要的库的缺失（虽说一般来说这种可能性不大），因此有可能无法做到最优。当使用Unity开发时，默认的Mono包含库可以说大部分用不上，在Player&Setting（Edit-&Project&Setting-&Player或者Shift+Ctrl(Command)+B里的Player&Setting按钮）面板里，将最下方的Optimization栏目中“Api&Compatibility&Level”选为.NET&2.0&Subset，表示你只会使用到部分的.NET&2.0&Subset，不需要Unity将全部.NET的Api包含进去。接下来的“Stripping&Level”表示从build的库中剥离的力度，每一个剥离选项都将从打包好的库中去掉一部分内容。你需要保证你的代码没有用到这部分被剥离的功能，选为“Use&micro&mscorlib”的话将使用最小的库（一般来说也没啥问题，不行的话可以试试之前的两个）。库剥离可以极大地降低打包后的程序的尺寸以及程序代码的内存占用，唯一的缺点是这个功能只支持Pro版的Unity。这部分优化的力度需要根据代码所用到的.NET的功能来进行调整，有可能不能使用Subset或者最大的剥离力度。如果超出了限度，很可能会在需要该功能时因为找不到相应的库而crash掉（iOS的话很可能在Xcode编译时就报错了）。比较好地解决方案是仍然用最强的剥离，并辅以较小的第三方的类库来完成所需功能。一个最常见问题是最大剥离时Sysytem.Xml是不被Subset和micro支持的，如果只是为了xml，完全可以导入一个轻量级的xml库来解决依赖（Unity官方推荐这个）。关于每个设定对应支持的库的详细列表，可以在这里找到。关于每个剥离级别到底做了什么，Unity的文档也有说明。实际上，在游戏开发中绝大多数被剥离的功能使用不上的，因此不管如何，库剥离的优化方法都值得一试。&托管堆优化首先需要明确，托管堆中存储的是你在你的代码中申请的内存（不论是用js，还是C#写的）。一般来说，无非是new或者Instantiate两种生成object的方法（事实上Instantiate中也是调用了new）。在接收到请求后，托管堆在其上为要新生成的对象实例以及其实例变量分配内存，如果可用空间不足，则向系统申请更多空间。当你使用完一个实例对象之后，通常来说在脚本中就不会再有对该对象的引用了（这包括将变量设置为null或其他引用，超出了变量的作用域，或者对Unity对象发送Destory()）。在每隔一段时间，Mono的垃圾回收机制将检测内存，将没有再被引用的内存释放回收。总的来说，你要做的就是在尽可能早的时间将不需要的引用去除掉，这样回收机制才能正确地把不需要的内存清理出来。但是需要注意在内存清理时有可能造成游戏的短时间卡顿，这将会很影响游戏体验，因此如果有大量的内存回收工作要进行的话，需要尽量选择合适的时间。如果在你的游戏里，有特别多的类似实例，并需要对它们经常发送Destroy()的话，游戏性能上会相当难看。比如小熊推金币中的金币实例，按理说每枚金币落下台子后都需要对其Destory()，然后新的金币进入台子时又需要Instantiate，这对性能是极大的浪费。一种通常的做法是在不需要时，不摧毁这个GameObject，而只是隐藏它，并将其放入一个重用数组中。之后需要时，再从重用数组中找到可用的实例并显示。这将极大地改善游戏的性能，相应的代价是消耗部分内存，一般来说这是可以接受的。如果不是必要，应该在游戏进行的过程中尽量减少对GameObject的Instantiate()和Destroy()调用，因为对计算资源会有很大消耗。在便携设备上短时间大量生成和摧毁物体的话，很容易造成瞬时卡顿。如果内存没有问题的话，尽量选择先将他们收集起来，然后在合适的时候（比如按暂停键或者是关卡切换），将它们批量地销毁并&且回收内存。Mono的内存回收会在后台自动进行，系统会选择合适的时间进行垃圾回收。在合适的时候，也可以手动地调用&System.GC.Collect()来建议系统进行一次垃圾回收。要注意的是这里的调用真的仅仅只是建议，可能系统会在一段时间后在进行回收，也可能完全不理会这条请求，不过在大部分时间里，这个调用还是靠谱的。&本机堆的优化当你加载完成一个Unity的scene的时候，scene中的所有用到的asset（包括Hierarchy中所有GameObject上以及脚本中赋值了的的材质，贴图，动画，声音等素材），都会被自动加载（这正是Unity的智能之处）。也就是说，当关卡呈现在用户面前的时候，所有Unity编辑器能认识的本关卡的资源都已经被预先加&入内存了，这样在本关卡中，用户将有良好的体验，不论是更换贴图，声音，还是播放动画时，都不会有额外的加载，这样的代价是内存占用将变多。Unity最&初的设计目的还是面向台式机，几乎无限的内存和虚拟内存使得这样的占用似乎不是问题，但是这样的内存策略在之后移动平台的兴起和大量移动设备游戏的制作中出现了弊端，因为移动设&备能使用的资源始终非常有限。因此在面向移动设备游戏的制作时，尽量减少在Hierarchy对资源的直接引用，而是使用Resource.Load的方&法，在需要的时候从硬盘中读取资源，在使用后用Resource.UnloadAsset()和Resources.UnloadUnusedAssets()尽快将其卸载掉。总之，这里是一个处理时间和占用内存空间的trade&off，如何达到最好的效果没有标准答案，需要自己权衡。在关卡结束的时候，这个关卡中所使用的所有资源将会被卸载掉（除非被标记了DontDestroyOnLoad）的资源。注意不仅是DontDestroyOnLoad的资源本身，其相关的所有资源在关卡切换时都不会被卸载。DontDestroyOnLoad一般被用来在关卡之间保存一些玩家的状态，比如分数，级别等偏向文&本的信息。如果DontDestroyOnLoad了一个包含很多资源（比如大量贴图或者声音等大内存占用的东西）的话，这部分资源在场景切换时无法卸&载，将一直占用内存，这种情况应该尽量避免。另外一种需要注意的情况是脚本中对资源的引用。大部分脚本将在场景转换时随之失效并被回收，但是，在场景之间被保持的脚本不在此列（通常情况是被附&着在DontDestroyOnLoad的GameObject上了）。而这些脚本很可能含有对其他物体的Component或者资源的引用，这样相关的&资源就都得不到释放，这绝对是不想要的情况。另外，static的单例（singleton）在场景切换时也不会被摧毁，同样地，如果这种单例含有大量的对资源的引用，也会成为大问题。因此，尽量减少代码的耦合和对其他脚本的依赖是十分有必要的。如果确实无法避免这种情况，那应当手动地对这些不再使用的引用对象调用Destroy()或者将其设置为null。这样在垃圾回收的时候，这些内存将被认为已经无用而被回收。需要注意的是，Unity在一个场景开始时，根据场景构成和引用关系所自动读取的资源，只有在读取一个新的场景或者reset当前场景时，才会得到清理。因此这部分内存占用是不可避免的。在小内存环境中，这部分初始内存的占用十分重要，因为它决定了你的关卡是否能够被正常加载。因此在计算资源充足或是关卡开始之后还有机会进行加载时，尽量减少Hierarchy中的引用，变为手动用Resource.Load，将大大减少内存占用。在&Resource.UnloadAsset()和Resources.UnloadUnusedAssets()时，只有那些真正没有任何引用指向的资源&会被回收，因此请确保在资源不再使用时，将所有对该资源的引用设置为null或者Destroy。同样需要注意，这两个Unload方法仅仅对Resource.Load拿到的资源有效，而不能回收任何场景开始时自动加载的资源。与此类似的还有&AssetBundle的Load和Unload方法，灵活使用这些手动自愿加载和卸载的方法，是优化Unity内存占用的不二法则～
评论 ( 个评论)Unity3d教程之画质与效率适配【unity3d吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：78,323贴子：
Unity3d教程之画质与效率适配收藏
　　今天带给大家的是Unity3d教程之画质与效率适配。众所周知，由于不同的设备配置不同。导致其CPU和GPU处理能力有高有低。同样的游戏想要在所有设备上运行流畅且画面精美，是不可能的。这就需要我们针对不同的设备能力进行画质调节，以保证游戏的流畅运行。　　我们需要控制什么?　　想要得到我们需要控制什么，只需要找出影响游戏运行效率的点即可。 当然在此不能一一列举出所有游戏类型的点。但笔者就个人经验，列出一些能用点。　　*贴图精度　　*渲染面数　　*材质复杂度　　*粒子数目　　*阴影质量　　*水面效果　　*增强性场景交互　　*引擎后期效果　　下面，我们就一个点一个点来说明原因，并给出常见的优化方法。　　贴图精度:SKIP MIPMAP　　贴图精度影响的是tex2D、texCUBE等采样指令的速度。对于显卡较次的机器来说，可能会是一大瓶颈。一般的引擎都提供了SKIP MIPMAP的能力。　　SKIP MIPMAP即在上传贴图数据的时候，跳过指定级数的MIPMAP。 这样在SHADER中进行访问时，使用的就是低级别的贴图精度。 比如，一张的贴图。 SKIP MIPMAP设置为1。表示要跳一级MIPMAP。 那SHADER中采样的时候。最大分辨率将会是512×512。　　渲染面数:裁剪&LOD&DETAIL　　渲染面数与DRAW CALL数目，会受GPU位宽、GPU频率限制。 当超出负载时，帧率会骤然下降。 这就要求我们需要对渲染面数有一个很好的控制。常见的控制手法有3种　　1、减小裁剪距离　　剪裁距离的减小，会将远处的景物裁剪掉。 从而减少DRAW CALL和提交的面数。　　注：这里说的减小裁剪距离，一定是和视锥体裁剪时一起使用，当靠摄像机的FAR CLIP PLANE，作用很小。　　2、模型LOD　　随着距离的增加，景物的细节会看不清。此时我们可以减少细节。　　注：LOD的切换，可以是两个策略分管。 一是距离，二是根据机型配置。 取距离计算结果和机型配置结果中最大的LOD等级。　　3、隐藏细节　　场景中的景物，根据主次关系进行标记。不同的主次关系的景物，受不到同的裁剪距离的影响。 比如，地表可视距离为1000，树木可视距离为800，花草可视距离为500。　　注：主次细节的显示与否，可以是两个策略分管。一是距离，二是根据机型配置。距离计算结果和机型配置结果都需要显示时，才显示。　　材质复杂度：切换SHADER　　材质复杂度是整个画质和效率控制系统中的大头，毕竟大部分的开销都因材质而起。归根结底，材质复杂度的控制，就是切换不同的SHADER。 使得GPU运算复杂度降低。笔者参与的引擎和游戏开发项目中，遇到过两种。　　1、宏控制的SHADER编译　　宏控制的SHADER编译，是指在SHADER中使用一些宏定义。在对SHADER进行编译时，将设备定义的宏开关附加到SHADER代码顶部，编译器根据宏内容进行编译。 这个方案的优点是，一套代码适配多个设备配置。但这个方案也有一个缺点，就是如果要进行实时切换，则会触发SHADER的重新编译。如果是手机项目，一般都是启动的时候进行硬件检测，选择最适合当前机型的编译配置进行材质的初始化。 而对于端游等项目，则需要考虑动态切换问题。　　注：这个方案，汇编级的SHADER不支持。 比如DX ASM、STAGE3D AGAL。　　PS：笔者曾经工作的公司的一个自研手游3D引擎是用的这个方案，十分好用。 前提是中间不要让玩家切换画质。　　PPS：UNITY3D也支持这种方案。　　2、切换Technique　　这是基于一个材质拥有多个Technique，且Technique不是用来区分材质。 也就是说，在这种情况下，Material作为区分一个模型材质的单元。 其内包含的Technique用于做设备的性能适配。这样的方案下，不同的情况下，需要切换高中低配置时，只需要切换Technique即可。　　注：这个方案，常见引擎都支持，如OGRE，UNITY3D。　　粒子数目：禁用发射器　　一个粒子特效可能有一个或者多个发射器构成。这样的话，我们可以为每一个发射器指定一个LOD等级(如果不支持额外添加数据的，可以通过发射器名字加前缀，比如 LOD0_FIRE0，LOD1_FIRE1等)。 我们再根据玩家的选择或者配置禁用发射器。以达到减少粒子计算和渲染的开销。　　阴影质量：SHADOW MAP精度&选择性开关　　阴影无疑是增强画质的一个有利武器。 但是当玩家机器配置无法为阴影质量买单时，就只有选择性关闭了。 比如，可以给NPC，怪物，BOSS，其他玩家，玩家自己都配置一个阴影标记。 一般有 实时阴影、脚底黑圈、关闭 三种。再根据机型配置或者玩家选择进行动态的开关各单位的阴影。　　阴影的效率开销还受另外一些参数的影响。比如SHADOW MAP的分辨率，是否要使用软阴影等。　　水面效果：折射&反射&普通水面　　水面效果一般有以下4种　　1、实时折射 + 实时反射 ( 现在的主流配置)　　2、实时反射(早期一些MMORPG使用)　　3、普通水面+CUBEMAP反射(丝路传说那种)　　4、普通半透明水面(WOW早期那种)　　如果都实现了，那根据玩家选择即可。 和LOD一样，取玩家选择和配置的最大值。　　增强性场景交互　　比如，地上的小鸟在来回走动，玩家跑过时，会惊飞。 又比如，玩家进入草丛时，草丛会因为受玩家力的影响左右晃动。　　这样的一些细节，着实令整个世界显得更加真实。 但CPU和GPU的额外开销，也是一笔不小的账。 因此，提供一个配置，供玩家和机型开关。　　引擎后期效果　　引擎后期效果，如BLOOM,HDR,热力扭曲等，都会带来不小的开销。 提供开关让玩家或者机型配置即可。　　总结　　我们不指望自己的游戏在每一个玩家的机器上，都美仑美奂。 但我们希望自己的游戏，能够流畅的运行在每一个玩家的机器上。 这样至少给了玩家一次体验这个游戏的机会。 如果玩家愿意为这个游戏升级自己的配置，那又何尝不是一件值得让人骄傲的事!
登录百度帐号推荐应用尊敬的用户您好！因系统升级，暂时无法访问，给您带来的不便我们感到万分抱歉。论坛开放时间将另行通知，感谢您的理解与支持！
10 秒后自动跳转页面Unity 3D中的内存管理与优化游戏运行性能的经验 - CSDN博客
Unity 3D中的内存管理与优化游戏运行性能的经验
Unity3D在内存占用上一直被人诟病，特别是对于面向移动设备的游戏开发，动辄内存占用飙上一两百兆，导致内存资源耗尽，从而被系统强退造成极差的体验。类似这种情况并不少见，但是绝大部分都是可以避免的。虽然理论上Unity的内存管理系统应当为开发者分忧解难，让大家投身到更有意义的事情中去，但是对于Unity对内存的管理方式，官方文档中并没有太多的说明，基本需要依靠自己摸索。最近在接手的项目中存在严重的内存问题，在参照文档和Unity Answer众多猜测和证实之后，稍微总结了下Unity中的内存的分配和管理的基本方式，在此共享。
虽然Unity标榜自己的内存使用全都是“Managed Memory”，但是事实上你必须正确地使用内存，以保证回收机制正确运行。如果没有做应当做的事情，那么场景和代码很有可能造成很多非必要内存的占用，这也是很多Unity开发者抱怨内存占用太大的原因。接下来我会介绍Unity使用内存的种类，以及相应每个种类的优化和使用的技巧。遵循使用原则，可以让非必要资源尽快得到释放，从而降低内存占用。
Unity中的内存种类
实际上Unity游戏使用的内存一共有三种：程序代码、托管堆（Managed Heap）以及本机堆（Native Heap）。
程序代码包括了所有的Unity引擎，使用的库，以及你所写的所有的游戏代码。在编译后，得到的运行文件将会被加载到设备中执行，并占用一定内存。这部分内存实际上是没有办法去“管理”的，它们将在内存中从一开始到最后一直存在。一个空的Unity默认场景，什么代码都不放，在iOS设备上占用内存应该在17MB左右，而加上一些自己的代码很容易就飙到20MB左右。想要减少这部分内存的使用，能做的就是减少使用的库，稍后再说。
托管堆是被Mono使用的一部分内存。Mono项目一个开源的.net框架的一种实现，对于Unity开发，其实充当了基本类库的角色。托管堆用来存放类的实例（比如用new生成的列表，实例中的各种声明的变量等）。“托管”的意思是Mono“应该”自动地改变堆的大小来适应你所需要的内存，并且定时地使用垃圾回收（Garbage Collect）来释放已经不需要的内存。关键在于，有时候你会忘记清除对已经不需要再使用的内存的引用，从而导致Mono认为这块内存一直有用，而无法回收。
最后，本机堆是Unity引擎进行申请和操作的地方，比如贴图，音效，关卡数据等。Unity使用了自己的一套内存管理机制来使这块内存具有和托管堆类似的功能。基本理念是，如果在这个关卡里需要某个资源，那么在需要时就加载，之后在没有任何引用时进行卸载。听起来很美好也和托管堆一样，但是由于Unity有一套自动加载和卸载资源的机制，让两者变得差别很大。自动加载资源可以为开发者省不少事儿，但是同时也意味着开发者失去了手动管理所有加载资源的权力，这非常容易导致大量的内存占用（贴图什么的你懂的），也是Unity给人留下“吃内存”印象的罪魁祸首。
优化程序代码的内存占用
这部分的优化相对简单，因为能做的事情并不多：主要就是减少打包时的引用库，改一改build设置即可。对于一个新项目来说不会有太大问题，但是如果是已经存在的项目，可能改变会导致原来所需要的库的缺失（虽说一般来说这种可能性不大），因此有可能无法做到最优。
当使用Unity开发时，默认的Mono包含库可以说大部分用不上，在Player Setting（Edit-&Project Setting-&Player或者Shift+Ctrl(Command)+B里的Player Setting按钮）面板里，将最下方的Optimization栏目中“Api Compatibility Level”选为.NET 2.0 Subset，表示你只会使用到部分的.NET 2.0 Subset，不需要Unity将全部.NET的Api包含进去。接下来的“Stripping Level”表示从build的库中剥离的力度，每一个剥离选项都将从打包好的库中去掉一部分内容。你需要保证你的代码没有用到这部分被剥离的功能，选为“Use
micro mscorlib”的话将使用最小的库（一般来说也没啥问题，不行的话可以试试之前的两个）。库剥离可以极大地降低打包后的程序的尺寸以及程序代码的内存占用，唯一的缺点是这个功能只支持Pro版的Unity。
这部分优化的力度需要根据代码所用到的.NET的功能来进行调整，有可能不能使用Subset或者最大的剥离力度。如果超出了限度，很可能会在需要该功能时因为找不到相应的库而crash掉（iOS的话很可能在Xcode编译时就报错了）。比较好地解决方案是仍然用最强的剥离，并辅以较小的第三方的类库来完成所需功能。一个最常见问题是最大剥离时Sysytem.Xml是不被Subset和micro支持的，如果只是为了xml，完全可以导入一个轻量级的xml库来解决依赖（Unity官方推荐这个）。
关于每个设定对应支持的库的详细列表，可以在这里找到。关于每个剥离级别到底做了什么，Unity的文档也有说明。实际上，在游戏开发中绝大多数被剥离的功能使用不上的，因此不管如何，库剥离的优化方法都值得一试。
托管堆优化
Unity有一篇不错的关于托管堆代码如何写比较好的说明，在此基础上我个人有一些补充。
首先需要明确，托管堆中存储的是你在你的代码中申请的内存（不论是用js，C#还是Boo写的）。一般来说，无非是new或者Instantiate两种生成object的方法（事实上Instantiate中也是调用了new）。在接收到alloc请求后，托管堆在其上为要新生成的对象实例以及其实例变量分配内存，如果可用空间不足，则向系统申请更多空间。
当你使用完一个实例对象之后，通常来说在脚本中就不会再有对该对象的引用了（这包括将变量设置为null或其他引用，超出了变量的作用域，或者对Unity对象发送Destory()）。在每隔一段时间，Mono的垃圾回收机制将检测内存，将没有再被引用的内存释放回收。总的来说，你要做的就是在尽可能早的时间将不需要的引用去除掉，这样回收机制才能正确地把不需要的内存清理出来。但是需要注意在内存清理时有可能造成游戏的短时间卡顿，这将会很影响游戏体验，因此如果有大量的内存回收工作要进行的话，需要尽量选择合适的时间。
如果在你的游戏里，有特别多的类似实例，并需要对它们经常发送Destroy()的话，游戏性能上会相当难看。比如小熊推金币中的金币实例，按理说每枚金币落下台子后都需要对其Destory()，然后新的金币进入台子时又需要Instantiate，这对性能是极大的浪费。一种通常的做法是在不需要时，不摧毁这个GameObject，而只是隐藏它，并将其放入一个重用数组中。之后需要时，再从重用数组中找到可用的实例并显示。这将极大地改善游戏的性能，相应的代价是消耗部分内存，一般来说这是可以接受的。关于对象重用，可以参考Unity关于内存方面的文档中Reusable
Object Pools部分，或者Prime31有一个是用Linq来建立重用池的视频教程（Youtube，需要翻墙，上，下）。
如果不是必要，应该在游戏进行的过程中尽量减少对GameObject的Instantiate()和Destroy()调用，因为对计算资源会有很大消耗。在便携设备上短时间大量生成和摧毁物体的话，很容易造成瞬时卡顿。如果内存没有问题的话，尽量选择先将他们收集起来，然后在合适的时候（比如按暂停键或者是关卡切换），将它们批量地销毁并且回收内存。Mono的内存回收会在后台自动进行，系统会选择合适的时间进行垃圾回收。在合适的时候，也可以手动地调用System.GC.Collect()来建议系统进行一次垃圾回收。要注意的是这里的调用真的仅仅只是建议，可能系统会在一段时间后在进行回收，也可能完全不理会这条请求，不过在大部分时间里，这个调用还是靠谱的。
本机堆的优化
当你加载完成一个Unity的scene的时候，scene中的所有用到的asset（包括Hierarchy中所有GameObject上以及脚本中赋值了的的材质，贴图，动画，声音等素材），都会被自动加载（这正是Unity的智能之处）。也就是说，当关卡呈现在用户面前的时候，所有Unity编辑器能认识的本关卡的资源都已经被预先加入内存了，这样在本关卡中，用户将有良好的体验，不论是更换贴图，声音，还是播放动画时，都不会有额外的加载，这样的代价是内存占用将变多。Unity最初的设计目的还是面向台式机，几乎无限的内存和虚拟内存使得这样的占用似乎不是问题，但是这样的内存策略在之后移动平台的兴起和大量移动设备游戏的制作中出现了弊端，因为移动设备能使用的资源始终非常有限。因此在面向移动设备游戏的制作时，尽量减少在Hierarchy对资源的直接引用，而是使用Resource.Load的方法，在需要的时候从硬盘中读取资源，在使用后用Resource.UnloadAsset()和Resources.UnloadUnusedAssets()尽快将其卸载掉。总之，这里是一个处理时间和占用内存空间的trade
off，如何达到最好的效果没有标准答案，需要自己权衡。
在关卡结束的时候，这个关卡中所使用的所有资源将会被卸载掉（除非被标记了DontDestroyOnLoad）的资源。注意不仅是DontDestroyOnLoad的资源本身，其相关的所有资源在关卡切换时都不会被卸载。DontDestroyOnLoad一般被用来在关卡之间保存一些玩家的状态，比如分数，级别等偏向文本的信息。如果DontDestroyOnLoad了一个包含很多资源（比如大量贴图或者声音等大内存占用的东西）的话，这部分资源在场景切换时无法卸载，将一直占用内存，这种情况应该尽量避免。
另外一种需要注意的情况是脚本中对资源的引用。大部分脚本将在场景转换时随之失效并被回收，但是，在场景之间被保持的脚本不在此列（通常情况是被附着在DontDestroyOnLoad的GameObject上了）。而这些脚本很可能含有对其他物体的Component或者资源的引用，这样相关的资源就都得不到释放，这绝对是不想要的情况。另外，static的单例（singleton）在场景切换时也不会被摧毁，同样地，如果这种单例含有大量的对资源的引用，也会成为大问题。因此，尽量减少代码的耦合和对其他脚本的依赖是十分有必要的。如果确实无法避免这种情况，那应当手动地对这些不再使用的引用对象调用Destroy()或者将其设置为null。这样在垃圾回收的时候，这些内存将被认为已经无用而被回收。
需要注意的是，Unity在一个场景开始时，根据场景构成和引用关系所自动读取的资源，只有在读取一个新的场景或者reset当前场景时，才会得到清理。因此这部分内存占用是不可避免的。在小内存环境中，这部分初始内存的占用十分重要，因为它决定了你的关卡是否能够被正常加载。因此在计算资源充足或是关卡开始之后还有机会进行加载时，尽量减少Hierarchy中的引用，变为手动用Resource.Load，将大大减少内存占用。在Resource.UnloadAsset()和Resources.UnloadUnusedAssets()时，只有那些真正没有任何引用指向的资源会被回收，因此请确保在资源不再使用时，将所有对该资源的引用设置为null或者Destroy。同样需要注意，这两个Unload方法仅仅对Resource.Load拿到的资源有效，而不能回收任何场景开始时自动加载的资源。与此类似的还有AssetBundle的Load和Unload方法，灵活使用这些手动自愿加载和卸载的方法，是优化Unity内存占用的不二法则～
/archives/76214
总结使用Unity 3D优化游戏运行性能的经验
作者：Amir Fasshihi
流畅的游戏玩法来自流畅的帧率，而我们即将推出的动作平台游戏《Shadow Blade》已经将在标准iPhone和iPad设备上实现每秒60帧视为一个重要目标。
以下是我们在紧凑的优化过程中提升游戏运行性能，并实现目标帧率时需要考虑的事项。
当基本游戏功能到位时，就要确保游戏运行表现能够达标。我们衡量游戏运行表现的一个基本工具是Unity内置分析器以及Xcode分析工具。使用Unity分析器来分析设备上的运行代码真是一项宝贵的功能。
我们总结了这种为将目标设备的帧率控制在60fps而进行衡量、调整、再衡量过程的中相关经验。
shadow blade()
一、遇到麻烦时要调用“垃圾回收器”（Garbage Collector，无用单元收集程序，以下简称GC）
由于具有C/C++游戏编程背景，我们并不习惯无用单元收集程序的特定行为。确保自动清理你不用的内存，这种做法在刚开始时很好，但很快你就公发现自己的分析器经常显示CPU负荷过大，原因是垃圾回收器正在收集垃圾内存。这对移动设备来说尤其是个大问题。要跟进内存分配，并尽量避免它们成为优先数，以下是我们应该采取的主要操作：
1.移除代码中的任何字符串连接，因为这会给GC留下大量垃圾。
2.用简单的“for”循环代替“foreach”循环。由于某些原因，每个“foreach”循环的每次迭代会生成24字节的垃圾内存。一个简单的循环迭代10次就可以留下240字节的垃圾内存。
3.更改我们检查游戏对象标签的方法。用“if (go.CompareTag (“Enemy”)”来代替“if (go.tag == “Enemy”)” 。在一个内部循环调用对象分配的标签属性以及拷贝额外内存，这是一个非常糟糕的做法。
4.对象库很棒，我们为所有动态游戏对象制作和使用库，这样在游戏运行时间内不会动态分配任何东西，不需要的时候所有东西反向循环到库中。
5.不使用LINQ命令，因为它们一般会分配中间缓器，而这很容易生成垃圾内存。
二、谨慎处理高级脚本和本地引擎C++代码之间的通信开销。
所有使用Unity3D编写的游戏玩法代码都是脚本代码，在我们的项目中是使用Mono执行时间处理的C#代码。任何与引擎数据的通信需求都要有一个进入高级脚本语言的本地引擎代码的调用。这当然会产生它自己的开销，而尽量减少游戏代码中的这些调用则要排在第二位。
1.在这一情景中四处移动对象要求来自脚本代码的调用进入引擎代码，这样我们就会在游戏玩法代码的一个帧中缓存某一对象的转换需求，并一次仅向引擎发送一个请求，以便减少调用开销。这种模式也适用于其他相似的地方，而不仅局限于移动和旋转对象。
2.将引用本地缓存到元件中会减少每次在一个游戏对象中使用 “GetComponent” 获取一个元件引用的需求，这是调用本地引擎代码的另一个例子。
三、物理效果
1.将物理模拟时间步设置到最小化状态。在我们的项目中就不可以将让它低于16毫秒。
2.减少角色控制器移动命令的调用。移动角色控制器会同步发生，每次调用都会耗损极大的性能。我们的做法是缓存每帧的移动请求，并且仅运用一次。
3.修改代码以免依赖“ControllerColliderHit” 回调函数。这证明这些回调函数处理得并不十分迅速。
4.面对性能更弱的设备，要用skinned mesh代替physics cloth。cloth参数在运行表现中发挥重要作用，如果你肯花些时间找到美学与运行表现之间的平衡点，就可以获得理想的结果。
5.在物理模拟过程中不要使用ragdolls，只有在必要时才让它生效。
6.要谨慎评估触发器的“onInside”回调函数，在我们的项目中，我们尽量在不依赖它们的情况下模拟逻辑。
7.使用层次而不是标签。我们可以轻松为对象分配层次和标签，并查询特定对象，但是涉及碰撞逻辑时，层次至少在运行表现上会更有明显优势。更快的物理计算和更少的无用分配内存是使用层次的基本原因。
8.千万不要使用Mesh对撞机。
9.最小化碰撞检测请求（例如ray casts和sphere checks），尽量从每次检查中获得更多信息。
四、让AI代码更迅速
我们使用AI敌人来阻拦忍者英雄，并同其过招。以下是与AI性能问题有关的一些建议：
1.AI逻辑（例如能见度检查等）会生成大量物理查询。可以让AI更新循环设置低于图像更新循环，以减少CPU负荷。
五、最佳性能表现根本就不是来自代码！
没有发生什么情况的时候，就说明性能良好。这是我们关闭一切不必要之物的基本原则。我们的项目是一个侧边横向卷轴动作游戏，所以如果不具有可视性时，就可以关闭许多动态关卡物体。
1.使用细节层次的定制关卡将远处的敌人AI关闭。
2.移动平台和障碍，当它们远去时其物理碰撞机也会关闭。
3.Unity内置的“动画挑选”系统可以用来关闭未被渲染对象的动画。
4.所有关卡内的粒子系统也可以使用同样的禁用机制。
六、回调函数！那么空白的回调函数呢？
要尽量减少Unity回调函数。即使敌人回调函数存在性能损失。没有必要将空白的回调函数留在代码库中（有时候介于大量代码重写和重构之间）。
七、让美术人员来救场
在程序员抓耳挠腮，绞尽脑汁去想该如何让每秒运行更多帧时，美术人员总能神奇地派上大用场。
1.共享游戏对象材料，令其在Unity中处于静止状态，可以让它们绑定在一起，由此产生的简化绘图调用是呈现良好移动运行性能的重要元素。
2.纹理地图集对UI元素来说尤其有用。
3.方形纹理以及两者功率的合理压缩是必不可少的步骤。
4.我们的美术人员移除了所有远处背景的网格，并将其转化为简单的2D位面。
5.光照图非常有价值。
6.我们的美术人员在一些关口移除了额外顶点。
7.使用合理的纹理mip标准是一个好主意（游戏邦注：要让不同分辨率的设备呈现良好的帧率时尤其如此）。
8.结合网格是美术人员可以发挥作用的另一个操作。
9.我们的动画师尽力让不同角色共享动画。
10.要找到美学/性能之间的平衡，就免不了许多粒子效果的迭代。减少发射器数量并尽量减少透明度需求也是一大挑战。
八、要减少内存使用
使用大内存当然会对性能产生负面影响，但在我们的项目中，我们的iPod由于超过内存上限而遭遇了多次崩溃事件。我们的游戏中最耗内存的是纹理。
1.不同设备要使用不同的纹理大小，尤其是UI和大型背景中的纹理。《Shadow Blade》使用的是通用型模板，但如果在启动时检测到设备大小和分辨率，就会载入不同资产。
2.我们要确保未使用的资产不会载入内存。我们必须迟一点在项目中找到仅被一个预制件实例引用，并且从未完全载入内存中实例化的资产。
3.去除网格中的额外多边形也能实现这一点。
4.我们应该重建一些资产的生周期管理。例如，调整主菜单资产的加载/卸载时间，或者关卡资产、游戏音乐的有效期限。
5.每个关卡都要有根据其动态对象需求而量身定制的特定对象库，并根据最小内存需求来优化。对象库可以灵活一点，在开发过程中包含大量对象，但知道游戏对象需求后就要具体一点。
6.保持声音文件在内存的压缩状态也是必要之举。
加强游戏运行性能是一个漫长而具有挑战性的过程，游戏开发社区所分享的大量知识，以及Unity提供的出色分析工具为《Shadow Blade》实现目标运行性能提供了极大帮助。（本文为游戏邦/编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
“0 – 60 fps in 14 days!” What we learned trying to optimize our game using Unity3D.
by Amir Fassihi
The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
A smooth gameplay is built upon the foundations of a smooth frame rate and hitting the 60 frames per second target on the standard iPhone and iPad devices was a significant goal during the development of our upcoming action platformer game, Shadow Blade.
The following is a summary from the things we had to consider and change in the game in order to increase the performance and reach the targeted frame rate during the intense optimization sessions.
Once the basic game functionalities were in place, it was time to make sure the game performance would meet its target. Our main tool for measuring the performance was the built-in Unity profiler and the Xcode profiling tools. Being able to profile the running
code on the device using the Unity profiler proved to be an invaluable feature.
So here goes our summary and what we learned about the results of this intense measuring, tweaking and re-measuring journey which paid out well at the end and resulted in a fixed 60fps for our target devices.
1 – Head to head with a ferocious monster called the Garbage Collector.
Coming from a C/C++ game programming background, we were not used to the specific behaviors of the garbage collector. Making sure your unused memory is cleaned up automatically for you is nice at first but soon the reality kicks in and you witness regular
spikes in your profiler showing the CPU load caused by the garbage collector doing what it is supposed to do, collecting the garbage memory. This proved to be a huge issue specifically for the mobile devices. Chasing down memory allocations and trying to eliminate
them became priority number one and here are some of the main actions we took:
Remove any string concatenation in code since this leaves a lot of garbage for the GC to collect.
Replace the “foreach” loops with simple “for” loops. For some reason, every iteration of every “foreach” loop generated 24 Bytes of garbage memory. A simple loop iterating 10 times left 240 Bytes of memory ready to be collected which was just unacceptable
Replace the way we checked for game object tags. Instead of “if (go.tag == “Enemy”)” we used “if (go.CompareTag (“Enemy”)”. Calling the tag property on an object allocates and copies additional memory and this is really bad if such a check resides in an
inner loop.
Object pools are great, we made and used pools for all dynamic game objects so that nothing is ever allocated dynamically during the game runtime in the middle of the levels and everything is recycled back to the pool when not needed.
Not using LINQ commands since they tended to allocate intermediate buffers, food for the GC.
2 – Careful with the communication overhead between high level scripts and native engine C++ code.
All gameplay code written for a game using Unity3D is script code which in our case was C# that was handled using the Mono runtime. Any requirements to communicate with the engine data would require a call into the native engine code from the high level
scripting language. This of course has its own overhead and trying to reduce such calls in game code was the second priority.
Moving objects around in the scene requires calls from the script code to the engine code and we ended up caching the transformation requirements for an object during a frame in the gameplay code and sending the request to the engine only once to reduce
the call overhead. This pattern was used in other similar places other than the needs to move and rotate an object.
Caching references to components locally would eliminate the need to fetch a component reference using the “GetComponent” method on a game object every time which is another example for a call into the native engine code.
3 – Physics, Physics and more Physics.
Setting the physics simulation timestep to the minimum possible. For our case we could not set it lower than 16 milliseconds.
Reducing calls to character controller move commands. Moving the character controller happens synchronously and every call can have a significant performance cost. What we did was to cache the movement requests per frame and apply them only once.
Modifying code to not rely on the “ControllerColliderHit” callbacks. It proved that these callbacks are not handled very quickly.
Replacing the physics cloth with a skinned mesh for the weaker devices. The cloth parameters can play important roles in performance also and it pays off to spend some time to find the appropriate balance between aesthetics and performance.
Ragdolls were disabled so that they were not part of the physics simulation loop and only enabled when necessary.
“OnInside” callbacks of the triggers need to be assessed carefully and in our case we tried to model the logic without relying on them if possible.
Layers instead of tags! Layers and tags can be assigned to objects easily and used for querying specific objects, however, layers have a definite advantage at least performance wise when it comes to working with collision logic. Quicker physics calculations
and less unwanted newly allocated memory are the basic reasons.
Mesh colliders are definitely a no-no.
Minimize collision detection requests like ray casts and sphere checks in general and try to get as much information from each check.
4 – Let’s make the AI code faster!
We use artificial intelligence for the enemies that try to block our main ninja hero and fight with him. The following topics needed to be covered regarding AI performance issues:
A lot of physical queries are generated from AI logic like visibility checks. The AI update loop could be set to something much lower than the graphics update loop to reduce CPU load.
5 – Best performance is achieved from no code at ALL!
When nothing happens, performance is good. This was the base philosophy for us to try and turn anything not necessary at the moment off. Our game is a side scroller action game and so a lot of the dynamic level objects can be turned off when they are not
visible in the scene.
Enemy AI was turned off when far away using a custom level of detail scheme.
Moving platforms and hazards and their physics colliders were turned off when far away.
Built in Unity “animation culling” system was used to turn off animations on objects not being rendered.
Same disabling mechanism used for all in level particle systems.
6 – Callback! How about empty callbacks?
The Unity callbacks needed to be reduced as much as possible. Even the empty callbacks had performance penalties. There is no reason for having empty callbacks but they just get left in the code base sometimes in between a lot of code rewrite and refactoring.
7 – The mighty Artists to the rescue.
Artists can always magically help out the hair-pulling programmer trying to go for a few more frames per second.
Sharing materials for game objects and making them static in Unity causes them to be batched together and the resulting reduced draw calls are critical for good mobile performance.
Texture atlases helped a lot especially for the UI elements.
Square textures and power of two with proper compression was a must.
Being a side-scroller enabled our artists to remove all far background meshes and convert them to simple 2D planes instead.
Light maps were highly valuable.
Our artists removed extra vertices during a few passes.
Proper texture mip levels were a good decision especially for having a good frame rate on devices with different resolutions.
Combining meshes was another performance friendly action by the artists.
Our animator tried to share animations between different characters if it was possible.
A lot of iterations on the particles were necessary to find the aesthetic/performance balance. Reducing number of emitters and trying to reduce transparency requirements were among the major challenges.
8 – The memory usage needs to be reduced, now!
Using a lot of memory of course has negative performance related effects but in our case we experienced a lot of crashes on iPods due to exceeding memory limits which was a much more critical problem. The biggest memory consumers in our game were the textures.
Different texture sizes were used for different devices, especially textures used in UI and large backgrounds. Shadow Blade uses a universal build but different assets get loaded when the device size and resolution is detected upon startup.
We needed to make sure un-used assets were not loaded in memory. We had to find out a little late in the project that any asset that was only referenced by an instance of a prefab and never instantiated was fully loaded in memory.
Stripping out extra polygons from meshes helped.
We needed to re-architect the lifecycle management of some assets a few times. For example tweaking the load/unload time for the main menu assets or end of level assets or game music.
Each level needed to have its specific object pool tailored to its dynamic object requirements and optimized for the least memory needs. Object pools can be flexible and contain a lot of objects during development, however, they need to be specific once
the game object requirements are known.
Keeping the sound files compressed in memory was necessary.
Game performance enhancement is a long and challenging journey and we had a fun time experiencing a small part of this voyage. The vast amount of knowledge shared by the game development community and very good profiling tools provided by Unity were what
made us reach our performance targets for Shadow Blade.（source：）
本文已收录于以下专栏：
相关文章推荐
参考：/archives/76214
其中翻译有些有误，所以我做了些修正。
A smooth gameplay is built upon the fou...
流畅的游戏玩法来自流畅的帧率，而我们即将推出的动作平台游戏《Shadow Blade》已经将在标准iPhone和iPad设备上实现每秒60帧视为一个重要目标。
以下是我们在紧凑的优化过程中提升游...
总结使用Unity 3D优化游戏运行性能的经验
发布时间： 17:44:42 Tags：内存使用率,帧率,游戏运行性能,物理效果,美术人员
作者：Ami...
原作者：Amir Fasshihi
流畅的游戏玩法来自流畅的帧率，而我们即将推出的动作平台游戏《Shadow Blade》已经将在标准iPhone和iPad设备上实现每秒60帧视为一个重要目标。...
流畅的游戏玩法来自流畅的帧率，而我们即将推出的动作平台游戏《Shadow Blade》已经将在标准iPhone和iPad设备上实现每秒60帧视为一个重要目标。
以下是我们在紧凑的优化过程中提升游...
转自：/msg_221889.html
总结使用Unity 3D优化游戏运行性能的经验
发布者: sea_bug | 发布时间:
01:33| 评论数: 0
流畅的游戏玩法来自流畅的帧率，而我们即将推出的动作平台游戏《Shadow Blade》已经将在标准iPhone和iPad设备上实现每秒60帧视为一个重要目标。
以下是我们在紧凑的优化过程中提升游...
流畅的游戏玩法来自流畅的帧率，而我们即将推出的动作平台游戏《Shadow Blade》已经将在标准iPhone和iPad设备上实现每秒60帧视为一个重要目标。
以下是我们在紧凑的优化过程中提升游...
WeTest导读
内存是游戏的硬伤，如果没有做好内存的管理问题，游戏极有可能会出现卡顿，闪退等影响用户体验的现象。本文介绍了在腾讯游戏在Unity游戏开发过程中常见的Mono内存管理问题，并介绍了一...
他的最新文章
讲师：宋宝华
讲师：何宇健
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)