浅谈 Unity 内存管理
🐶

浅谈 Unity 内存管理

Tags
演讲
Published
May 11, 2022
Author
💡
我的博客:萤火之森 ,所有的公开笔记放在:公开笔记

什么是内存

  • 物理内存
  • 虚拟内存
    • 内存交换
    • 移动设备不支持内存交换
    • iOS 可以进行内存压缩
    • Android 没有内存压缩能力

内存杀手 low memory killer(AKA lmk)

notion image
  • 内存不足时,killer 会出现,从上图底层一层一层地向上杀。(Cached-Previous-Home...)

Unity 内存管理

  • Unity 是一个 C++ 引擎
    • 底层代码完全由 C++ 写成
    • 通过 Wrapper 提供给用户 API
    • 用户代码会转换为 CPP 代码 (il2cpp)
      • VM 仍然存在(il2cpp vm)
  • Unity 内存按照分配方式分为:
    • Native Memory
    • Managed Memory
    • Editor & Runtime 是不同的
      • 不止是统计看到的内存大小不同,甚至是内存分配时机和方式也不同
      • Asset 在 Runtime 中如果不读取,是不会进内存的,但 Editor 打开就占内存。因为 Editor 不注重 Runtime 的表现,更注重编辑器中编辑时的流畅。
        • 但如果游戏庞大到几十个 G,如果第一次打开项目,会消耗很多时间,有的大的会几天,甚至到一周。
  • Unity 内存按照管理者分为:
    • 引擎管理内存
    • 用户管理内存(应优先考虑)
  • Unity 检测不到的内存
    • 用户分配的 native 内存
      • 自己写的 Native 插件(C++ 插件), Unity 无法分析已经编译过的 C++ 是如何去分配和使用内存的。
      • Lua 完全由自己管理内存,Unity 无法统计到内部的使用情况。

Unity Native Memory 管理

Unity 重载了所有分配内存的操作符(C++ alloc、new),使用这些重载的时候,会需要一个额外的 memory label (Profiler-shaderlab-object-memory-detail-snapshot,里面的名字就是 label:指当前内存要分配到哪一个类型池里面)
  • 使用重载过的分配符去分配内存时,Allocator 会根据你的 memory label 分配到不同 Allocator 池里面,每个 Allocator 池 单独做自己的跟踪。因此当我们去 Runtime get memory label 下面的池时就可以问 Allocator,里面有多少东西 多少兆。
  • Allocator 在 NewAsRoot (Memory “island”(没听清)) 中生成。在这个 Memory Root 下面会有很多子内存:shader:当我们加载一个 Shader 进内存的时候,会生成一个 Shader 的 root。Shader 底下有很多数据:sub shader、Pass 等会作为 memory “island” (root) 的成员去依次分配。因此当我们最后统计 Runtime 的时候,我们会统计 Root,而不会统计成员,因为太多了没法统计。
  • 因为是 C++ 的,因此当我们 delete、free 一个内存的时候会立刻返回内存给系统,与托管内存堆不一样。

最佳实践 Native 内存

  • Scene
    • Unity 是一个 C++ 引擎,所有实体最终都会反映在 C++ 上,而不是托管堆里面。因此当我们实例化一个 GameObject 的时候,在 Unity 底层会构建一个或多个 Object 来存储这个 GameObject 的信息,例如很多 Components。因此当 Scene 有过多 GameObject 的时候,Native 内存就会显著上升。
    • 当我们看 Profiler,发现 Native 内存大量上升的时候,应先去检查 Scene。
  • Code Size
    • C++ 模板泛型的滥用会影响到 Code Size、打包的速度。
  • Resource 文件夹(Do not use it. 除非在 debug 的时候)
    • Resource 和 AssetBundle 一样,也有头来索引。Resource 在打进包的时候会做一个红黑树,来帮助 Resource 来检索资源在什么位置,
    • 如果 Resource 非常大,那么红黑树也会非常大。
    • 红黑树是不可卸载的。在刚开始游戏的时候就会加载进内存中,会持续对游戏造成内存压力。
    • 会极大拖慢游戏的启动时间。因为红黑树没加载完,游戏不能启动。

Unity Managed Memory

  • VM 内存池
    • mono 虚拟机的内存池
    • VM 会返还内存给 OS 吗?
    • 返还条件是什么?
      • GC 不会把内存返还给系统
      • 内存也是以 Block 来管理的。当一个 Block 连续六次 GC 没有被访问到,这块内存才会被返还到系统。(mono runtime 基本看不到,IL2cpp runtime 可能会看到多一点)
    • 不会频繁地分配内存,而是一次分配一大块。
  • GC 机制(BOEHM Non-generational 不分代的)
    • GC 机制考量
      • Throughput(回收能力)
        • 一次回收,会回收多少内存
      • Pause times(暂停时长)
        • 进行回收的时候,对主线程的影响有多大
      • Fragmentation(碎片化)
        • 回收内存后,会对整体回收内存池的贡献有多少
      • Mutator overhead(额外消耗)
        • 回收本身有 overhead,要做很多统计、标记的工作
      • Scalability(可扩展性)
        • 扩展到多核、多线程会不会有 bug
      • Protability(可移植性)
        • 不同平台是否可以使用
    • BOEHM
      • Non-generational(不分代的)
        • notion image
        • 分代是指:大块内存、小内存、超小内存是分在不同内存区域来进行管理的。还有长久内存,当有一个内存很久没动的时候会移到长久内存区域中,从而省出内存给更频繁分配的内存。
      • Non-compacting(非压缩式)
        • notion image
        • 当有内存被回收的时候,压缩内存会把上图空的地方重新排布。
        • 但 Unity 的 BOEHM 不会!它是非压缩式的。空着就空着,下次要用了再填进去。
          • 历史原因:Unity 和 Mono 合作上,Mono 并不是一直开源免费的,因此 Unity 选择不升级 Mono,与实际 Mono 版本有差距。
          • 下一代 GC
            • Incremental GC(渐进式 GC)
              • 现在如果我们要进行一次 GC,主线程被迫要停下来,遍历所有 GC Memory “island”(没听清),来决定哪些 GC 可以回收。
              • Incremental GC 把暂停主线程的事分帧做了。一点一点分析,主线程不会有峰值。总体 GC 时间不变,但会改善 GC 对主线程的卡顿影响。
            • SGen 或者升级 Boehm?
              • SGen 是分代的,能避免内存碎片化问题,调动策略,速度较快
            • IL2CPP
              • 现在 IL2CPP 的 GC 机制是 Unity 自己重新写的,是升级版的 Boehm
    • Memory fragmentation 内存碎片化
      • notion image
      • 为什么内存下降了,但总体内存池还是上升了?
        • 因为内存太大了,内存池没地方放它,虽然有很多内存可用。(内存已被严重碎片化)
      • 当开发者大量加载小内存,使用释放*N,例如配置表、巨大数组,GC 会涨一大截。
        • 建议先操作大内存,再操作小内存,以保证内存以最大效率被重复利用。
    • Zombie Memory(僵尸内存)
      • 内存泄露说法是不对的,内存只是没有任何人能够管理到,但实际上内存没有被泄露,一直在内存池中,被 zombie 掉了,这种叫 Zombie 内存。
      • 无用内容
        • Coding 时候或者团队配合的时候有问题,加载了一个东西进来,结果从头到尾只用了一次。
        • 有些开发者写了队列调度策略,但是策略写的不好,导致一些他觉得会被释放的东西,没有被释放掉。
        • 找是否有活跃度实际上并不高的内存。
      • 没有释放
      • 通过代码管理和性能工具分析
    • 最佳实践
      • Don't Null it, but Destroy it(显式用 Destory,别用 Null)
      • Class VS Struct
      • Pool In Pool(池中池)
        • VM 本身有内存池,但建议开发者对高频使用的小部件,自己建一个内存池。例如子弹等。
      • Closures and anonymous methods(闭包和匿名函数)
        • 如果看 IL,所有匿名函数和闭包会 new 成一个 class,因此所有变量和要 new 的东西都是要占内存的。这样会导致协程。
          • 有些开发者会在游戏开始启用一个协程,直到游戏结束才释放,这是错误的。
          • 只要协程不被释放掉,所有内存都会在内存里。
      • Coroutines(协程)
        • 可看做闭包和匿名函数的一个特例
        • 最佳实践:用的时候生产一个,不用的时候 destroy 掉。
      • Configurations(配置表)
        • 不要把整个配置表都扔进去,是否能通过啥来切分下配置表
      • Singleton
        • 慎用
        • 游戏一开始到游戏死掉,一直在内存中。