【后篇】游戏测试成长之路 — 游戏客户端性能（内存）

深度内存探索🔰
上篇讲了对应的内存简单介绍后，我们对内存的基本表现有了一定了解，知道一些内存直观上的表现，本篇就针对上篇未提及的内容进行补充

标题内存上涨不一定就是内存泄漏

上篇提到内存泄漏问题的定位，却少了对于内存上涨一定是内存泄漏的佐证了。接下来就来补充下，内存上涨还有可能是什么原因？内存泄漏的原因已经在上篇陈述了，忘记的回顾下。

内存上涨的正常表现

最直接就是缓存，当有一些 RPG 游戏，你在某个地图中活动就会把碰到的所有怪物，人物，等等一系列资源加载出来，内存最直接表现就是内存一直上涨，这种情况是内存泄漏么？不一定，当你更换了其他地图之后，之前加载的内存就正常卸载掉了，并且重新开始加载当前你这张地图的内容，一样会继续增加内存。这属于加载策略上的选择，是合理的，因此后续在测试过程中产生了对应的疑问之后你就可以跟开发聊聊，他们做了什么样的策略，避免产生误判。

内存申请/回收的破事

内存申请的内容也属于老生常谈的内容了，开发在编译脚本的时候，尤其是面向对象编程，大家听到的最多得就是 new 个对象，殊不知 new 对象这个创建变量的操作，底层编译时，是会去申请内存的，向谁申请？向内存的管理者去申请，上篇的内容图中也有提及过，申请内存时的表现。
依然以 Unity 项目举例，mono 是 Unity 用来管理行为数据的统一接口，所有执行行为都继承 mono，因此编写脚本时，每次 new 的时候都会向 mono 堆去申请内存，每次申请 mono 都会进行扩容，后续不使用时再把申请的回收回来。这样就能有个合理的循环。
mono 内存实际上也有内存泄漏的情况，而最骚的是 mono 的内存泄漏会导致内存碎片化，如：每次申请 10M 的内存，结果回收了 8M 回来，始终有 2M 漏在外面，但是堆管理又管不着，这样的话就会出现下次再用该堆去申请时，需要 10M 内存时，人堆管理只回收 8M 回来，而你又不够用，就会重新申请 10M 过来，结果循环往复，就会越来越过分，越申请越多，因为没做出图，可能大家不好理解，就是你借了 10 块，