大概记录遇到的可以优化的点。
1.Mesh.UploadMeshData：预先把网格送到GPU
unity是这样的，它对一个网格，先把它搞到内存，然后在第一次渲染它时把它送到GPU。但送GPU经常是个瓶颈，所以我们可以提前（没渲染前）分帧送，减轻掉帧压力，
并且UpdateMeshData(true)的话，会把内存的网格卸掉，省内存（但这样就不能改变此网格了，因为内存没网格了），不过我们一般很少更新网格，所以可以用来优化内存。
2.纹理压缩
在很多情况下，美术会觉得纹理压缩后效果不理想。我们建议的是：可以把原图的分辨率长宽都扩大一倍，保持原有压缩格式。
这样压缩过后的文件还是比不压缩的文件要小，并且视觉效果可以得到较大的改善。
3.去掉纹理导入设置中的 Read/Write Enabled 勾选状态
4.去掉模型文件导入设置中 Read/Write Enabled 勾选状态
除了需要脚本中访问的网格，作为网格碰撞器中的网格，脚本中用StaticBatchingUtility.Combine静态合批的网格，以及粒子系统发射的网格之外，
其它模型建议不要勾选此项 ，否则会在内存也保留一份网格实例占用内存。
5.勾选模型导入设置［Rig］选项页中Optimize GameObject，建议勾选，而对作为挂点需要保留的骨骼添加为“例外”就不会被优化掉。
6.不要频繁调用的Camera.main
建议脚本做好Main Camera的Cache。Camera.main实际为GameObject.FindGameObjectsWithTag(“MainCamera”)调用，
主要因为引擎无法得知用户通过脚本设置的MainCamera，CPU消耗较高。
7.减少脚本中UnityEngine.Object的判等操作（不是判空）
建议改为用InstanceID来判断即Object. GetInstanceID，运行期间保证唯一。 因为Object的判等还有额外的耗时操作。
同理，使用Object作为key的数据结构也建议改用InstanceID做key，因为作为key一般都有大量判等操作。
8.少用list来存储数据
List线性结构Contains的耗时非常高，建议改为hashset，hashtable之类的查询操作效率高的数据结构。
9.限制加载资源时每帧从Assetbundle加载的Asset数量
在场景内每帧从Assetbundle加载的Asset数建议限制在2到5个，数量高时耗时过长容易造成卡顿。
10.控制静态变量的使用，特别是引用大资源的静态变量
一些内存占用较大的资源如纹理，因为有静态索引而无法在切换场景或者调用UnloadUnusedAssets时被卸载掉，因此内存的泄漏量会随着用户切换场景的次数而增加。
11.因为mono内存池只增不减，所以一下子加载大资源，或者在释放资源之前/GC.Collect之前不断加载资源，会使得内存池变大，所以要挑好时机释放资源和GC.Collect,
memory profiler的Reserved Total/Unity/Mono的大小很大的话就要注意了。
另外一个容易忽视的点是：函数内的内存分配，如果一个函数分配很多内存，就可能使得内存池变大或者引发GC而造成卡顿（mono分配新内存如果池子木有空闲内存就先gc，还是不够就扩张池子），我们可以把临时变量抽取出来，优化里面分配的数据结构，尽量
减少一下子分配大内存的情况，并且分配完记得及时归还等。
12.减少特效渲染的Pass数量
一些特效的渲染可以合并到同一个Pass以节省GPU开销，另外RenderTexture在可以共用的情况下尽量共用
13.同屏顶点不要超过20W个，尽量在10W个以下。
14.大量使用AssetBundle情况下，要及时Unload掉它。
Q:我们项目的资源主要使用AssetBundle动态加载资源，发现Profiler中Detailed模式下PersistentManager.Remapper一项占用时多时少，这一项主要是做什么的呢？
A：Remapper主要提供文件的持久化存储，包括各种序列化的asset，项目的setting文件等，维护文件系统的中的文件与内存中数据的对应关系。那么如果项目大量使用AssetBundle的话，在对AssetBundle进行Unload之前都会需要占用Remapper的内存的。而Remapper本身的实现使用内存池，其数值只会增大，那么为了使Remapper占用的内存保持在一个稳定的数值上，我们需要每次在加载一定数量的AssetBundle之后进行Unload操作，而不要一次性把所有AssetBundle都加载后才调用Unload。（这样的操作对维持整个mono heap的大小也是至关重要的，因为mono heap本身也是只增大不减小的）
15.对于局部数据，使用结构体而不是类。类被存储在堆；而结构体被存储在栈。分配在堆上会被GC。
17.静态合批
1.为何要静态合批？
静态批处理的基本原理，每次渲染，CPU要做SetPass和调用DC，SetPass就算设置渲染状态，属于比较重要的分工，对于加载到游戏中的资源和对象等，CPU需要计算其顶点相关的矩阵，渲染所用的贴图，渲染所用到的材质和shader，渲染所用到的灯光等，即给Shader准备数据。正常情况下，我们需要给每个渲染对象设置渲染状态，这个有点耗，但如果使用静态合批，对许多渲染对象就只需要设置一次渲染状态，但前提是参与合批的渲染对象，他们的渲染状态要一样，即贴图，材质，shader要一致，不然无法合批。其实在unity 引擎内部做了优化，里面先对渲染对象排序，渲染状态一样（贴图/材质/shader一样）的对象相邻，这样在不合批时，也不会太耗（一样的就不用重新setpass了）。但我们不仅要关注setpass，还要关注dc，对于DC，不合批则每个渲染对象一个DC，合批后因为是当成一个对象来渲染，DC就变为1了，。所以在引擎的优化下，静态合批反而是对减少DC有极大提高。
2.静态合批时，Unity引擎做了什么？把合批的对象的网格组合起来，生成一个大网格，并且网格顶点都变换到世界坐标系（所以合批的对象不能移动等，同时也不用CPU上做顶点转换，优化了性能），每个对象，都有一个索引，指向大网格中自己对应的那部分顶点数据。渲染时，即使只渲染一部分对象，也需要把整个网格加载到内存，然后送给GPU，让GPU去裁切（关于这点，是我胡乱总结的，做不得准，但看起来挺合理的，或许CPU也做了一些抛弃处理比如disable的对象的顶点数据不传过去等），所以静态合批会使用更多内存，但却少了SetPass和DC。另外地，除了渲染状态要一致，静态合批对合批后的总顶点也有限制，上限是65536。
3.因为静态合批真的把网格合批了，所以要注意使用，一般合批不同几何外形的网格；而像网格相同的物体，不合批的话内存只有一份网格，合批的话就N份了，这个时候就不要合批了，比如浓密的森林，要是把整个森林合批了，那内存大概会爆了吧。
4.听一位前辈说，静态渲染需要保留一份网格在内存，不好，他经历一个项目是这么做的：把需要静态渲染的所有物件一起烘焙成一个大网格，并且去掉Read/Writeable选项，这样，提交到GPU后，就自动把内存的网格卸载了，挺好，只不过需要额外处理：美术更改场景时需要重新烘焙大网格；注意不同材质的物件烘焙时可能有些问题（可以用meshbaker插件搞定）等。这种方法经过我测试，确实能够把网格从内存卸载掉！
18.动态合批，动态合批是unity自己做的，我们只需在Player setting里开启即可。而我们剩下要做的就是为物体提供动态合批的条件：单个模型顶点属性集数目小于900，材质一样，木有缩放（或者大家都缩放），木有镜像（scale=1,1,1和scale=-1，-1，-1是不能合批的），不使用mutil-pass shader等，不过动态合批虽然少了dc（搞成一个大网格），但只要其中一个变了，其余的也都一起计算顶点变换(在cpu)，一起送到gpu（我猜的），要根据实际性能选择。
19.项目特效优化：
1）图集优化：特效使用了多个贴图，多个材质，优化：像ngui一样把多贴图搞成图集，共用材质，这样，他们就可以动态合批了（ngui则自己生成一个网格，倒有些类似）。
2）动作优化：
3）特效再优化：