🚀
猫冬的学习笔记/
🐶
浅谈 Unity 内存管理
Search
浅谈 Unity 内存管理
🐶

浅谈 Unity 内存管理

Tags
演讲
Published
May 11, 2022
Author
💡
我的博客：萤火之森 ，所有的公开笔记放在：公开笔记
www.bilibili.com
https://www.bilibili.com/video/av79798486/
Best practice guides
Learn production-tested best practices from our Enterprise Support engineers and the Unity R&D Content team.
Best practice guides
https://docs.unity3d.com/Manual/BestPracticeGuides.html
Best practice guides
什么是内存内存杀手 low memory killer（AKA lmk）Unity 内存管理Unity Native Memory 管理最佳实践 Native 内存Unity Managed Memory

什么是内存

  • 物理内存
  • 虚拟内存
    • 内存交换
    • 移动设备不支持内存交换
    • 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

Understanding the managed heap
Another common problem faced by many Unity developers is the unexpected expansion of the managed heap. In Unity, the managed heap expands much more readily than it shrinks. Furthermore, Unity's garbage collection strategy tends to fragment memory, which can prevent a large heap from shrinking.
Understanding the managed heap
https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity4-1.html
Understanding the managed heap
  • 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
        • 慎用
        • 游戏一开始到游戏死掉，一直在内存中。
Copyright 2022 猫冬