关于 Unity 项目中的 Mono 堆内存泄露

题记：这是补一篇应该在将近一年前就应该写的记录，今天终于补上。

内存泄露是一个老话题了，之前我专门写过一篇 排查 Lua 虚拟机内存泄露 的文章，并且附带了一个工具来查找 Lua 中具体的内存泄露。但是这只是整个 Unity 项目中内存泄漏的一小部分，C# 代码中一般内存泄露可能会更加严重。

我们之前发现无论在 Profiler 还是工具测试，随着战斗的增加，总体内存都是一直在增长，很明显是有了内存泄露。为了首先能够彻底检测到底是哪里出现了泄露，找了很多的工具，也参看了很多的文章，最终感觉首要的问题是需要完整的 C# 内存的快照明细，Mono 提供了一个过时的 HeapShot，看起来就是做这件事情的，但是离直接拿到项目里去使用还有不少的距离。在最后快要放弃打算自己 Hook Mono 的 API 编写时，发现了腾讯的 WeTest Cube 工具。其中有一项是专门用来打印详细内存快照的功能，根据自己的需要来选取内存快照，并且给出测试期间的整体内存走势，使用也很简单，在需要测试的手机上安装 WeTest Cube 软件（注意：手机必须要 Root），然后通过 Cube 里面选择设置，然后启动游戏即可。

启动后在想要打印内存快照的地方，点击屏幕上的 "快照" 按钮，就会在后台生成快照，多点几份然后再双击该按钮退出测试，然后上传数据完成，最后生成的快照数据需要再从 Cube 的网页报告端下载。

由于游戏项目较大，下载后的快照解压缩后基本都在 40+Mb，内容是 json 格式的文本，存取了每一项内存数据的地址，类型，引用链：

{"ptr":-1721623792,"type":"Texture2D","size":16,"stack":"|UnityEngine.GUIStyleState:ProduceGUIStyleStateFromDeserialization (UnityEngine.GUIStyle,intptr)|UnityEngine.GUIStyle:InternalOnAfterDeserialize ()|UnityEngine.GUIUtility:GetDefaultSkin ()|UnityEngine.GUI:DoSetSkin (UnityEngine.GUISkin)|UnityEngine.GUI:set_skin (UnityEngine.GUISkin)|UnityEngine.GUIUtility:BeginGUI (int,int,int)","reference":"|-1721577968"}

ptr - 内存地址

type - 数据类型

size - 内存大小

stack - 该内存被分配时的调用堆栈

reference - 被引用的地址，如果这里有多个，就是被多个其它的地址引用了

所以，依然在主城中打印一份快照，进入战斗打印一份快照，再回到主城打印一份快照，自己编写一个小工具解析两份主城的快照，并且将第二份新增的部分输出成一个单独的文件；然后再编写一个小工具将新增部分根据数据类型 type 来归类，将同类型的 size 相加，最后生成一个文件，里面两列：类型 和 大小。然后用 Excel 打开并按照 大小 降序排列，便可以直接看到那些新增的内存，根据项目情况分析新增部分从 类型 和 大小 两个角度来讲是否应该出现就立即分析出潜在的泄露，然后把泄露的 类型 拿到原始的快照(第二次主城快照)中去搜索，然后查看该类型到底被什么地方引用，一直追溯下去，便能找到最终的引用点，说明是因为“它”的引用才造成泄露。

接下来的事情就是去项目中实际分析代码，查看创建和释放的地方是否有纰漏，需要比较耐心的去项目代码中查找和分析，其实这都是苦活，脏活儿，要的都是耐心，你需要从成千上万条数据中揪出可能的泄露。

后来做完这次优化，我再次感受到，出现这些泄露的原因归根结底还是代码不够规范引起的，不注重必要的初始化和释放成对调用等，大致总结起来有以下几点：

• 错误使用了过多的 readonly，并且引用了其他的类型，甚至项目引用，最终形成引用环，并且环的某一个节点又被全局对象引用，造成“蝌蚪的尾巴被拴住”的情况，因此连带了很多的对象无法释放。
• 每一个类应该是有 Initialize 就有 Release，但实际情况大多是有Initialize 而没有 Release。
• 注意 Coroutine，如果使用了全局的 MonoBehaviour 对象 A 去 StartCoroutine 其他对象 B 的函数，那么这时 B 对象会被 A 对象引用，如果协程为正确执行结束在无线等待，那么 B 也会永远被 A 对象引用而不得释放，即使 StopAllCoroutine 也不行。
• 慎用 Delegate，这时大家经常使用的功能，但是也容易造成内存泄露，如果只是 += 而没有在合适的地方 -=，那么代理的方法所属的对象是会被一直引用而无法释放的。

总结起来很简单，这次优化就大致发现这几条，但是都不经意间，日积月累，引起了比较严重的问题，所以不要小看代码规范，和框架的遵守。

下面是项目优化前后的内存走势，总时长相同。

• 优化前：
  
  

• 优化后：
  
  

以上可以看出，经过一轮粗犷优化后内存依然保持小幅的总体增长，但是比优化前的总体大小已经大幅降低，并且涨幅也更加平缓。接下来可能会需要更大的精力和更多的手段去查找剩下的“一点点”内存泄露。