1 资源分离打包与加载
游戏中会有很多地方使用同一份资源。比如，有些界面会共用同一份字体、同一张图集，有些场景会共用同一张贴图，有些会怪物使用同一个Animator，等等。可以在制作游戏安装包时将这些公用资源从其它资源中分离出来，单独打包。比如若资源A和B都引用了资源C，则将C分离出来单独打一个bundle。在游戏运行时，如果要加载A，则先加载C；之后如果要加载B，因为C的实例已经在内存，所以只要直接加载B，让B指向C即可。如果打包时不将C从A和B分离出来，那么A的包里会有一份C，B的包里也会有一份C，冗余的C会将安装包撑大；并且在运行时，如果A和B都加载进内存，内存里就会有两个C实例，增大了内存占用。
资源分离打包与加载是最有效的减小安装包体积与运行时内存占用的手段。一般打包粒度越细，这两个指标就越小；而且当两个renderQueue相邻的DrawCall使用了相同的贴图、材质和shader实例时，这两个DrawCall就可以合并。但打包粒度也并不是越细就越好。如果运行时要同时加载大量小bundle，那么加载速度将会非常慢——时间都浪费在协程之间的调度和多批次的小I/O上了；而且DrawCall合并不见得会提高性能，有时反而会降低性能，后文会提到。因此需要有策略地控制打包粒度。一般只分离字体和贴图这种体积较大的公用资源。
可以用AssetDatabase.GetDependencies得知一份资源使用了哪些其它资源。
2 贴图透明通道分离，压缩格式设为ETC/PVRTC
最初我们使用了DXT5作为贴图压缩格式，希望能减小贴图的内存占用，但很快发现移动平台的显卡是不支持硬件解压DXT5的。因此对于一张1024x1024大小的RGBA32贴图，虽然DXT5可将它从4MB压缩到1MB，但系统将它送进显卡之前，会先用CPU在内存里将它解压成4MB的RGBA32格式（软件解压），然后再将这4MB送进显存。于是在这段时间里，这张贴图就占用了5MB内存和4MB显存；而移动平台往往没有独立显存，需要从内存里抠一块作为显存，于是原以为只占1MB内存的贴图实际却占了9MB！
所有不支持硬件解压的压缩格式都有这个问题。经过一番调研，我们发现安卓上硬件支持最广泛的格式是ETC，苹果上则是PVRTC。但这两种格式都是不带透明（Alpha）通道的。因此我们将每张原始贴图的透明通道都分离了出来，写进另一张贴图的红色通道里。这两张贴图都采用ETC/PVRTC压缩。渲染的时候，将两张贴图都送进显存。同时我们修改了NGUI的shader，在渲染时将第二张贴图的红色通道写到第一张贴图的透明通道里，恢复原来的颜色：
- 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。
3 关闭贴图的读写选项
Unity中导入的每张贴图都有一个启用可读可写（Read/Write Enabled）的开关，对应的程序参数是TextureImporter.isReadable。选中贴图后可在Import Setting选项卡中看到这个开关。只有打开这个开关，才可以对贴图使用Texture2D.GetPixel，读取或改写贴图资源的像素，但这就需要系统在内存里保留一份贴图的拷贝，以供CPU访问。一般游戏运行时不会有这样的需求，因此我们对所有贴图都关闭了这个开关，只在编辑中做贴图导入后处理（比如对原始贴图分离透明通道）时打开它。这样，上文提到的1024x1024大小的贴图，其运行时的2MB内存占用又可以少一半，减小到1MB。
4 减少场景中的GameObject数量
有一次我们将场景中的GameObject数量减少了近2万个，游戏在iPhone 3S上的内存占用立马减了20MB。这些GameObject虽然基本是在隐藏状态（activeInHierarchy为false），但仍然会占用不少内存。这些GameObject身上还挂载了不少脚本，每个GameObject中的每个脚本都要实例化，又是一比不菲的内存占用。因此后来我们规定场景中的GameObject数量不得超过1万，并且将GameObject数量列为每周版本的性能监测指标。
5 整理图集
整理图集的主要目的是节省运行时内存（虽然有时也能起到合并DrawCall的作用）。从这个角度讲，显示一个界面时送进显存的图集尺寸之和是越小越好。一般有如下方法可以帮助我们做到这点：
1）在界面设计上，尽量让美术将控件设计为可以做九宫格拉伸，即UISprite的类型为Sliced。这样美术就可以只切出一张小图，我们在Unity中将它拉大。当然，一个控件做九宫格也就意味着其顶点数量从4个增加到至少16个（九宫格的中心格子采用Tiled做平铺类型的话，顶点数会更多），构建DrawCall的开销会更大（见第6点），但一般只要DrawCall安排合理（同样见第6点）就不会有问题。
2）同样是在界面设计上，尽量让美术将图案设计成对称的形式。这样切图的时候，美术就可以只切一部分，我们在Unity中将完整的图案拼出来。比如对一个圆形图案，美术可以只切出四分之一；对一张脸，美术可以只切出一半。不过，与第1）点类似，这个方法同样有其它性能代价——一个图案所对应的顶点数和GameObject数量都增多了。第4点已经提到，GameObject数量的增多有时也会显著占用更多内存。因此一般只对尺寸较大的图案采用这个方法。
3）确保不要让不必要的贴图素材驻留内存，更不要在渲染时将无关的贴图素材送进显存。为此需要将图集按照界面分开，一般一张图集只放一个界面的素材，一个界面中的UISprite也不要使用别的界面的图集。假设界面A和界面B上都有一个小小的一模一样的金币图标，不要因为在制作时贪图方便，就让界面A的UISprite直接引用界面B中的金币素材；否则界面A显示的时候，会将整个界面B的图集也送进显存，而且只要A还在内存中，B的图集也会驻留内存。对于这种情况，应该在A和B的图集中各放一个一模一样的金币图标，A中的UISprite只使用A的图集，B中的UISprite只使用B的图集。
不过，如果两个界面之间存在大量相同的素材，那么这两个界面就可以共用同一张图集。这样可以减少所有界面的总内存占用量。具体操作时需要根据美术的设计进行权衡。一般界面之间相同的通用的素材越多，程序的内存负担就越小。但界面之间相同的东西太多的话，美术效果可能就不生动，这是美术和程序之间又一个需要寻求平衡的地方。
另外，数量庞大的图标资源（如物品图标）不要做在图集里，而应该采用UITexture。
4）减少图集中的空白地方。图集中完全透明的像素和不透名的像素所占的内存空间其实是一样的。因此在素材量不变的情况下，要尽量减少图集中的空白。有时一张1024x1024的图集中，素材所占的面积还没超过一半，这时可以考虑将这张图集切成两张512x512的图集。（可能有人会问为什么不能做成一张1024x512的图集，这是因为iOS平台似乎要求送进显存的贴图一定是方形。）当然，两张不同图集的DrawCall是无法合并的，但这并不是什么问题（见第6点）。
应该说，图集的整理在具体操作时并没有一成不变的标准，很多时候需要权衡利弊来最终决定如何整理，因为不管哪种措施都会有别的性能代价。
6 根据各个UI控件的设计安放Panel，隔开DrawCall
有一次我们发现NGUI的UIPanel.LateUpdate函数的CPU开销非常大。仔细研究之后，发现是合并了太多的DrawCall所致，尤其是将运行时会运动变化的UI控件和静止不变的UI控件的DrawCall合在了一起。当一个UI控件（UIWidget）的位置、大小或颜色等属性发生变化时，UIPanel就需要重建这个控件所用的DrawCall，某些情况下还要重建Panel上的所有DrawCall。有时重建一个DrawCall会消耗不少CPU开销，它需要重新计算这个DrawCall上所有控件的顶点信息，包括顶点位置、UV和颜色等。如果很多控件都集中在同一个DrawCall上，那么只要一个控件有一点点变化，这个DrawCall上的所有控件的顶点就都要重新遍历一边；而我们的UI又大量采用了九宫格拉伸，使控件的顶点数量变得更多，因此重建一个DrawCall的开销就更大。
因此我们将UI控件分组，将一段时间内会发生变化的控件——比如怪物头顶的血条和伤害跳字放在同一个Panel上，并且这个Panel上只有这些控件，其余基本不变化的控件就放在别的Panel上。这样两类控件就被隔开到不同的DrawCall不同的Panel中，当一个控件发生变化而导致DrawCall重建时，就不需要遍历那些没有变化的控件。因为在美术设计上，一段时间内在变化的控件总是少数，所以优化效果十分明显，节省的CPU占用率能达到25%。
这种方法会增加一些DrawCall，但不会有什么影响。我们项目中前期曾经过于重视DrawCall数量的压缩，但后来发现增加几个DrawCall并不是那么可怕的事情。主程有一次甚至用Cocos2d-x做过试验，即使在500个DrawCall的情况下，动画依然可以跑得很流畅，相比之下贴图大小对流畅度的影响要大得多。
7 优化锚点内部逻辑，使其只在必要时更新
在上一点优化了Panel的DrawCall重建效率之后，我们发现NGUI锚点自身的更新逻辑也会消耗不少CPU开销。即使是在控件静止不动的情况下，控件的锚点也会每帧更新（见UIWidget.OnUpdate函数），而且它的更新是递归式的，使CPU占用率更高。因此我们修改了NGUI的内部代码，使锚点只在必要时更新。一般只在控件初始化和屏幕大小发生变化时更新即可。不过这个优化的代价是控件的顶点位置发生变化的时候（比如控件在运动，或控件大小改变等），上层逻辑需要自己负责更新锚点。
8 降低贴图素材分辨率
这一招说白了其实就是减小贴图素材的尺寸。比如对一张在原画里尺寸是100x80的贴图，我们将它导入Unity后会把它缩小到50x40，即缩小两倍。游戏实际使用的是缩小后的贴图。不过这一招是必然会显著降低美术品质的，美术立马会发现画面变得更模糊，因此一般不到程序撑不住的时候不会采用。
9 界面的延迟加载和定时卸载策略（暂未实施）
如果一些界面的重要性较低，并且不常被使用，可以等到界面需要打开显示的时候才从bundle加载资源，并且在关闭时将自己卸载出内存，或者等过一段时间再卸载。不过这个方法有两个代价：一是会影响体验，玩家要求打开界面时，界面的显示会有延迟；二是更容易出bug，上层写逻辑时要考虑异步情况，当程序员要访问一个界面时，这个界面未必会在内存里。因此目前为止我们仍未实施该方案。目前只是进入一个新场景时，卸载上一个场景用到但新场景不会用到的界面。
以上的9个方法中，4、5、6需要在一定程度上从策划和美术的角度考虑问题，并且需要持续保持监控以维护优化状态（因为在设计上总是会有新界面的需求或改动老界面的需求）；其它都是一劳永逸的解决方案，只要实施稳定后，就不需要再在上面花费精力。不过2和8都是会降低美术品质的方法，尤其是8。如果美术对品质的降低程度实在忍不了的话，也可能不会允许采用这两个方法。
后记
后来又学到一招：
我们游戏的某些逻辑会在一帧内频繁调用GameObject.SetActive，显示或隐藏一些对象，数量达到一百多次之多。这类操作的CPU开销很大（尤其是NGUI的UIWidget在激活的时候会做很多初始化工作），而且会触发大量GC。后来我们改变了显示和隐藏对象的方法——让对象一直保持激活状态（activeInHierarchy为true），而原来的SetActive(false)改为将对象移到屏幕外，SetActive(true)改为将对象移回屏幕内。这样性能就好多了。
一、程序方面
01、务必删除脚本中为空或不需要的默认方法；
02、只在一个脚本中使用OnGUI方法；
03、避免在OnGUI中对变量、方法进行更新、赋值，输出变量建议在Update内；
04、同一脚本中频繁使用的变量建议声明其为全局变量，脚本之间频繁调用的变量或方法建议声明为全局静态变量或方法；
05、不要去频繁获取组件，将其声明为全局变量；
06、数组、集合类元素优先使用Array，其次是List；
07、脚本在不使用时脚本禁用之，需要时再启用；
08、可以使用Ray来代替OnMouseXXX类方法；
09、需要隐藏/显示或实例化来回切换的对象，尽量不要使用SetActiveRecursively或active，而使用将对象远远移出相机范围和移回原位的做法；
10、尽量少用模运算和除法运算，比如a/5f，一定要写成a*0.2f。
11、对于不经常调用或更改的变量或方法建议使用Coroutines & Yield；
12、尽量直接声明脚本变量，而不使用GetComponent来获取脚本； iPhone
13、尽量使用整数数字，因为iPhone的浮点数计算能力很差；
14、不要使用原生的GUI方法；
15、不要实例化（Instantiate）对象，事先建好对象池，并使用Translate“生成”对象；
二、模型方面
01、合并使用同贴图的材质球，合并使用相同材质球的Mesh；
02、角色的贴图和材质球只要一个，若必须多个则将模型离分离为多个部分；
02、骨骼系统不要使用太多；
03、当使用多角色时，将动画单独分离出来；
04、使用层距离来控制模型的显示距离；
05、阴影其实包含两方面阴暗和影子，建议使用实时影子时把阴暗效果烘焙出来，不要使用灯光来调节光线阴暗。
06、少用像素灯和使用像素灯的Shader；
08、如果硬阴影可以解决问题就不要用软阴影，并且使用不影响效果的低分辨率阴影；
08、实时阴影很耗性能，尽量减小产生阴影的距离；
09、允许的话在大场景中使用线性雾，这样可以使远距离对象或阴影不易察觉，因此可以通过减小相机和阴影距离来提高性能；
10、使用圆滑组来尽量减少模型的面数；
11、项目中如果没有灯光或对象在移动那么就不要使用实时灯光；
12、水面、镜子等实时反射/折射的效果单独放在Water图层中，并且根据其实时反射/折射的范围来调整；
13、碰撞对效率的影响很小，但碰撞还是建议使用Box、Sphere碰撞体；
14、建材质球时尽量考虑使用Substance；
15、尽量将所有的实时反射/折射（如水面、镜子、地板等等）都集合成一个面；
16、假反射/折射没有必要使用过大分辨率，一般64*64就可以，不建议超过256*256；
17、需要更改的材质球，建议实例化一个，而不是使用公共的材质球；
18、将不须射线或碰撞事件的对象置于IgnoreRaycast图层；
19、将水面或类似效果置于Water图层
20、将透明通道的对象置于TransparentFX图层；
21、养成良好的标签（Tags）、层次（Hieratchy）和图层（Layer）的条理化习惯，将不同的对象置于不同的标签或图层，三者有效的结合将很方便的按名称、类别和属性来查找；
22、通过Stats和Profile查看对效率影响最大的方面或对象，或者使用禁用部分模型的方式查看问题到底在哪儿；
23、使用遮挡剔除（Occlusion Culling）处理大场景，一种较原生的类LOD技术，并且能够“分割”作为整体的一个模型。
三、其它 场景中如果没有使用灯光和像素灯，就不要使用法线贴图，因为法线效果只有在有光源（Direct Light/Point Light/Angle Light/Pixel Light）的情况下才有效果。
2.1渲染
1.不使用或少使用动态光照，使用light mapping和light probes（光照探头）
2.不使用法线贴图（或者只在主角身上使用），静态物体尽量将法线渲染到贴图
3．不适用稠密的粒子，尽量使用UV动画
4.不使用fog，使用渐变的面片（参考shadow gun）
5.不要使用alpha –test（如那些cutout shader），使用alpha-blend代替
6．使用尽量少的material，使用尽量少的pass和render次数，如反射、阴影这些操作
7.如有必要，使用Per-Layer Cull Distances，Camera.layerCullDistances
8.只使用mobile组里面的那些预置shader
9.使用occlusion culling
11.远处的物体绘制在skybox上
12.使用drawcall batching： 对于相邻动态物体：如果使用相同的shader，将texture合并 对于静态物体，batching要求很高，详见Unity Manual>Advanced>Optimizing Graphics Performance>Draw Call Batching 规格上限
1. 每个模型只使用一个skinned mesh renderer
2. 每个mesh不要超过3个material
3. 骨骼数量不要超过30
4. 面数在1500以内将得到好的效率
2.2物理
1.真实的物理（刚体）很消耗，不要轻易使用，尽量使用自己的代码模仿假的物理
2.对于投射物不要使用真实物理的碰撞和刚体，用自己的代码处理
3.不要使用mesh collider
4.在edit->project setting->time中调大FixedTimestep（真实物理的帧率）来减少cpu损耗
2.3脚本编写
1.尽量不要动态的instantiate和destroy object，使用object pool
2.尽量不要再update函数中做复杂计算，如有需要，可以隔N帧计算一次
3.不要动态的产生字符串，如Debug.Log("boo" + "hoo")，尽量预先创建好这些字符串资源
4.cache一些东西，在update里面尽量避免search，如GameObject.FindWithTag("")、GetComponent这样的调用，可以在start中预先存起来
5.尽量减少函数调用栈，用x = (x > 0 ? x : -x);代替x = Mathf.Abs(x)
6.String的相加操作，会频繁申请内存并释放，导致gc频繁，使用System.Text.StringBuilder代替
2.4 shader编写
1.数据类型 fixed / lowp - for colors, lighting information and normals, half / mediump - for texture UV coordinates, float / highp - avoid in pixel shaders, fine to use in vertex shader for position calculations.
2.少使用的函数：pow,sin,cos等
2.4 GUI
1.不要使用内置的onGUii函数处理gui，使用其他方案，如NGUI
3.格式
1.贴图压缩格式：ios上尽量使用PVRTC，Android上使用ETC