mac上用MarsEdit写博文很难改成和windows live writer上格式一样,也就将就了，以后都当笔记来做博文，坚持手写，杜绝慵懒的复制
几乎我们所有的优化概念都告诉我们
第一条，要想程序运行更流畅就要牺牲更多的内存，作为代价，用内存换流畅，比方说 近处的贴图质量高，远处使用低质量的贴图(mipmap),近处使用高模远处使用低模(Lod)
第二条，用CPU换内存，例如在资源不使用的情况下Destory掉，然后用诸如：Resource.UnloadUnUsedAsserts或者是gc释放，但是这个调用可能很频繁，增加CPU负担
第三条，合理使用看项目需求而定，优化是有条目的，作为开发人员可以抓住最基本优化套路，然后遵循项目的具体需要酌情考虑
简单考虑从三个方面入手 资源方面，引擎方面，代码方面
美术资源方面
动态物体{
控制面片数量 300 － 2000控制skinned mesh为一个控制材质数量1-3个控制骨骼数量小于30根
}
静态物体{
控制网格的顶点数小于500个
标记为static，static batching内部会优化，例如三个物体标记static会在一个drawcall渲染 注意：即使使用了static，不同的shader还是会增加drawcall，增加一种不同类型的材质(即使材质使用的都是同一个shader)，增加一个drawcall
animation组件 尽量不要附加
}
纹理{
自带地形 控制分辨率 地图高度尺寸小于257
地形纹理中使用更少的混合纹理数目 不要超过四个
纹理格式采用压缩格式
纹理尺寸小于1024
建议使用mipmap，虽然会真增加程序的大小但是会提高渲染效率，文件大小会增加到133%，所以做个取舍吧
(一张图理解mipmap) }
音频{
播放时间长的音乐使用 .ogg .mp3时间比较短的 用 .wav .aif
}
引擎方面优化
光源设置{
满足效果的前提下控制灯数量
控制important光源的数目(在light选项render mode下可选 )
尽量1个或者干脆没有
个数越多drawcall越多
pixel light count可以控制受影响的灯光的数量(选项在 Quality Setting > Pixel Light Count)
使用Lod(多细节层次)
}
相机设置 {
设置合理的裁切范围
遮挡剔除
}
粒子优化{
屏幕上的粒子总数不超过200个
建议每个粒子发射器发射的总数不超过20个
粒子的size尽可能小，对于非常小的粒子可以去除粒子贴图中的alpha
}
物理引擎优化{
碰撞体优化尽量使用球形盒子碰撞 避免使用mesh collider
}
渲染优化{
避免使用alpha test与alpth blend,如果使用使用alpth代替alpha test，如果无法代替将alpth test的像素降低到最小
DrawCall Batching unity在渲染时可以将一些物体合并，从而使用一个drawcall
static batching 对静态物体batching 对几何数据没有大小限制，原理 静态verterx＋动态index buffer 将同种材质合并 在一个大的vetexbuffer中，注意 使用stati cbatching会增加内存开销来储存batch后的数据
dynamic batching 对于动态物体unity会对其自动batching，原理 动态vertexbuffer＋indexbuffer 注意，目前仅支持小 于900顶点的网格物体，如果shader里使用position，narmal，uv三种属性，则智能batch 300顶点以下的物体，如果使 用position，normal，uv，uv1，tangent等属性则只能batch180顶点以下的物体
缩放物体无法与非缩放物体进行batch
纹理合并texture batching
}
代码优化方面
1.如每隔x帧数调用一次 Time.frameCount%x==0
2.使用invokeRepeating函数，在启动.5秒后每隔1秒执行一次InvokeRepeating("DoSometing",.5f,1f)
3.尽量使用乘法而不是除法
4.合理使用gc，频繁的gc调用会增加cpu的负担，不手动调用只有当内存到达一定阀值gc才会被运行时调用，也就是说在我们做切换场景之列的动作时手动调用即可
来源：https://www.cnblogs.com/Keyle/p/4593580.html