Unity3D为我们提供了一个强大的性能分析工具Profiler。今天我们就使用Profiler来具体分析一下官方样例AngryBots的内存使用信息数据。
首先打开Profiler选择Memory选项。在游戏执行的某一帧查看Detailed选项数据（Simple模式的数据非常直观。能够知道内存大体被哪部分占用了，网上也有非常多相关介绍，我就不再啰嗦了）。例如以下图所看到的：
选中后，unity会自己主动获取这一帧的内存占用数据项，主要分为：Other、Assets、BuiltinResources、Scene Memory、NotSaved这五大部分，以下我们就来一一分析。
- Other
记录数据项非常多，篇幅时间有限，我们就专挑占用大小排行榜靠前的几项来具体分析吧。
- System.ExecutableAndDlls：系统可运行程序和DLL。是仅仅读的内存，用来运行全部的脚本和DLL引用。不同平台和不同硬件得到的值会不一样，能够通过改动Player Setting的Stripping Level来调节大小。
Ricky：我试着改动了一下Stripping Level似乎没什么改变，感觉虽占用内存大但不会影响游戏执行。
我们临时忽略它吧(- -)!
- GfxClientDevice：GFX（图形加速图形加速器显卡 (GraphicsForce Express)）client设备。
Ricky：虽占用较大内存。但这也是必备项。没办法优化。继续忽略吧(- -)!!
- ManagedHeap.UsedSize：托管堆使用大小。
Ricky：重点监控对象，不要让它超过20MB。否则可能会有性能问题！
- ShaderLab：Unity自带的着色器语言工具相关资源。
Ricky：这个东西大家都比較熟悉了，忽略它吧。
- SerializedFile：序列化文件，把显示中的Prefab、Atlas和metadata等资源载入进内存。
Ricky：重点监控对象。这里就是你要监控的哪些预设在序列化中在内存中占用大小，依据需求进行优化。
- PersistentManager.Remapper：持久化数据重映射管理相关
Ricky：与持久化数据相关，比方AssetBundle之类的。注意监控相关的文件。
- ManagedHeap.ReservedUnusedSize：托管堆预留不使用内存大小。仅仅由Mono使用。
Ricky：无法优化。
- Assets
- Texture2D： 2D贴图及纹理。
Ricky：重点优化对象，有下面几点能够优化：
- 很多贴图採用的Format格式是ARGB 32 bit所以保真度非常高但占用的内存也非常大。
在不失真的前提下。适当压缩贴图，使用ARGB 16 bit就会降低一倍，假设继续Android採用RGBA Compressed ETC2 8 bits（iOS採用RGBA Compressed PVRTC 4 bits），又能够再降低一倍。把不须要透贴但有alpha通道的贴图，全都转换格式Android：RGB Compressed ETC 4 bits，iOS：RGB Compressed PVRTC 4 bits。
- 当载入一个新的Prefab或贴图，不及时回收，它就会永驻在内存中，就算切换场景也不会销毁。
应该确定物体不再使用或长时间不使用就先把物体制空(null)，然后调用Resources.UnloadUnusedAssets()，才干真正释放内存。
- 有大量空白的图集贴图，能够用TexturePacker等工具进行优化或考虑合并到其它图集中。
- AudioManager：音频管理器
Ricky：随着音频文件的增多而增大。
- AudioClip：音效及声音文件
Ricky：重点优化对象，播放时长较长的音乐文件须要进行压缩成.mp3或.ogg格式。时长较短的音效文件能够使用.wav 或.aiff格式。
- Cubemap：立方图纹理
Ricky：这个一般在天空盒中比較常见，我也不知道怎样优化这个。。。
- Mesh：模型网格
Ricky：主要检查是否有反复的资源。还有尽量降低点面数。
- Scene Memory
- Mesh：场景中使用的网格模型
Ricky：注意网格模型的点面数。能合并的mesh尽量合并。
- Builtin Resources
Ricky：这些都是Unity的一些内部资源，对于项目内存没有什么分析价值，所以我就临时不正确其进行分析了。
- Profiler内存重点关注优化项目
1）ManagedHeap.UsedSize: 移动游戏建议不要超过20MB.
2）SerializedFile: 通过异步载入(LoadFromCache、WWW等)的时候留下的序列化文件,可监视是否被卸载.
3）WebStream: 通过异步WWW下载的资源文件在内存中的解压版本号，比SerializedFile大几倍或几十倍。只是我们如今项目中展示没有。
4）Texture2D: 重点检查是否有反复资源和超大Memory是否须要压缩等.
5）AnimationClip: 重点检查是否有反复资源.
6）Mesh： 重点检查是否有反复资源.
- 项目中可能遇到的问题
1.Device.Present:
1）GPU的presentdevice确实很耗时，一般出如今使用了很复杂的shader.
2）GPU执行的很快，而因为Vsync的原因，使得它须要等待较长的时间.
3）相同是Vsync的原因，但其它线程非常耗时，所以导致该等待时间非常长，比方：过量AssetBundle载入时easy出现该问题.
4）Shader.CreateGPUProgram:Shader在runtime阶段（非预载入）会出现卡顿(华为K3V2芯片).
5）StackTraceUtility.PostprocessStacktrace()和StackTraceUtility.ExtractStackTrace(): 通常是由Debug.Log或类似API造成，游戏公布后需将Debug API进行屏蔽。
2.Overhead:
1）普通情况为Vsync所致.
2）通常出如今Android设备上.
3.GC.Collect:
原因：
1）代码分配内存过量(恶性的)
2）一定时间间隔由系统调用(良性的).
占用时间：
1）与现有Garbage size相关
2）与剩余内存使用颗粒相关（比方场景物件过多。利用率低的情况下，GC释放后须要做内存重排)
4.GarbageCollectAssetsProfile:
1）引擎在运行UnloadUnusedAssets操作（该操作是比較耗时的,建议在切场景的时候进行）。
2）尽可能地避免使用Unity内建GUI。避免GUI.Repaint过渡GCAllow.
3）if(other.tag == a.tag)改为other.CompareTag(a.tag).由于other.tag为产生180B的GC Allow.
4）少用foreach，由于每次foreach为产生一个enumerator(约16B的内存分配)。尽量改为for.
5）Lambda表达式，使用不当会产生内存泄漏.
5.尽量少用LINQ：
1）部分功能无法在某些平台使用.
2）会分配大量GC Allow.
6.控制StartCoroutine的次数：
1）开启一个Coroutine(协程)，至少分配37B的内存.
2）Coroutine类的实例 -> 21B.
3）Enumerator -> 16B.
7.使用StringBuilder替代字符串直接连接.
8.缓存组件:
1）每次GetComponent均会分配一定的GC Allow.
2）每次Object.name都会分配39B的堆内存.
Ricky Yang个人原创，版权全部，转载注明，谢谢。
http://blog.csdn.net/yangyy753