Unity内存管理你应该知道的底层原理

Posted 大智_Unity玩家

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Unity内存管理你应该知道的底层原理相关的知识,希望对你有一定的参考价值。

本文首发公众号洪流学堂。洪流学堂,让你快人几步。

本文主要是Unity官方川哥的视频《浅谈Unity内存管理》的笔记及相关知识点补充,如果有时间强烈建议学习原视频:
https://www.bilibili.com/video/BV1aJ411t7N6

正文

1、什么是内存

内存分为物理内存、虚拟内存。

关于物理内存:

CPU访问内存是一个慢速过程。

CPU在需要访问内存时,先是访问自己的缓存(L1Cache、L2Cache……),当全部Miss之后,CPU会去主内存拿一段完整的指令到CPU的缓存中。因此,我们需要尽可能保证CPU的指令是连续的,防止CPU过多地与主内存之间的内存交换产生IO。

Unity为了处理上述问题,减少Cache Miss ,推出了ECS和DOTS,把分散的内存数据变成整块、连续的数据。(但DOTS目前20210513还不稳定,版本之间的API可能有很大变化且不兼容,产品级项目使用有风险)

关于虚拟内存:

电脑在物理内存不够的时候,操作系统会把一些不用的数据(DeadMemory)交换到硬盘上,称之为内存交换。

但是手机是不做内存交换的,一是因为移动设备的硬盘IO速度比PC慢很多,二是因为移动设备的硬盘可擦写次数更少;因此手机如果做内存交换一是慢,而是减少设备寿命看,所以android机上没有做内存交换。ios可以把不活跃的内存进行压缩,使得实际可用的内存更多,而安卓没有这个能力。

关于移动设备和PC:

移动设备(手机)与PC的区别在于,手机没有独立显卡、独立显存。手机上无论是CPU还是GPU都是共用一个缓存,而且手机的内存更小、缓存级数更少、大小更小。台式机的三级缓存大约8~16M,而手机只有2M。

综上,手机上的内存,不论从哪个角度看,都是比PC要小很多的。所以,手机上更容易出现内存不够的问题。

2、Android 内存管理

Android是基于Linux开发的,所以Android的内存管理和Linux很相似。

Android的内存管理基本单位是Page(页),一般是4k 一个Page。内存的回收和分配都是以 Page为单位进行操作,也就是4k。Android内存分用户态和内核态两个部分,内核态的内存是用户严格不能访问的。

关于内存杀手:Low Memory Killer (LMK)

当手机的内存使用量过多时,就会出现LMK,对当前手机的各种App、服务进行关停。安卓的各种应用、服务分为以下一些类别:

0、Native:系统内核

1、System:系统服务

2、Persistent: 用户服务,比如电话、蓝牙、Wifi等。

3、Foreground:前台应用,当前正在使用的Activity

4、Perceptible:辅助应用,音乐、搜索、键盘等;

5、Service:驻后台线程的服务,云同步、垃圾回收等;

6、Home键;

7、Previous:上一个使用的应用;

8、Cached:后台,之前使用过的各种应用。

这个也是Android系统的应用优先度排序,编号越小优先级越高。当LMK开始工作的时候,会从优先度最低的应用开始Kill。即最先中断各种Cached,最后才会到Native。

例如当Cached被杀掉之后,现象就是当你切换到后台的那些应用时,你会发现那些应用重启了。

当Home被杀死的时候,你发现当你回到桌面时,桌面会重启,你的桌面图标会重建,或者壁纸没了。

到Perceptible的时候,可能你的音乐、键盘不见了。

再往上进行,到Foreground时,当前前台应用就会被杀死,这个时候就会出现应用闪退。

在往上手机就开始重启了。

3、Android内存指标

RSS:Resident Set Size

你当前的APP所应用到的所有内存。除了你自己的APP所使用的内存之外,你调用的各种服务、共用库所产生的内存都会统计到RSS之中。

PSS:Proportional Set Size

与RSS不同的是,PSS会把公共库所使用的内存平摊到所有调用这个库的APP上。(可能你自己的应用没有申请很多内存,但是你的调用的某个公共库已经有了很大的内存分配,平摊下来就会导致你自己的APP的PSS虚高。)

USS:Unique Set Size

只有此APP所使用的内存,剔除掉公共库的内存分配。

我们在实际工作中更多要做的是对USS的优化,有时也会注意一下PSS。

4、关于Unity内存

Unity内存的分类

Unity内存分为 Native Memory和 Managed Memory (托管内存)。值得注意的是,在Editor下和在Runtime下Unity的内存分配是完全不同的。不但分配内存的大小会有不同,统计看到的内存大小不同,甚至是内存分配时机和方式也不同。

比如一个AssetBundle,在编辑器下是你一打开Unity就开始加载进内存,而在Runtime下则是你使用时才会加载,如果不读取,是不会进内存的。(Unity2019之后做了一些Asset导入优化,不使用的资源就不会导入)。 因为 Editor 不注重 Runtime 的表现,更注重编辑器中编辑时的流畅。

但如果游戏庞大到几十个 G,如果第一次打开项目,会消耗很多时间,有的大的会几天,甚至到一周。

Unity的内存还可以分为引擎管理的内存和用户管理器的内存两类。引擎管理的内存一般开发者是访问不到的,而用户管理的内存才是使用者需要关系和优先考虑的。

还有一个Unity监测不到的内存:用户分配的 Native 内存内存是Unity的Profile工具监测不到。例如:

  • 自己写的 Native 插件(C++ 插件), Unity 无法分析已经编译过的 C++ 是如何去分配和使用内存的。
  • Lua 完全由自己管理内存,Unity 无法统计到内部的使用情况。

5、最佳实践 Native 内存

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 一个内存的时候会立刻返回内存给系统,与托管内存堆不一样。

Scene

  • Unity 是一个 C++ 引擎,所有实体最终都会反映在 C++ 上,而不是托管堆里面。因此当我们实例化一个 GameObject 的时候,在 Unity 底层会构建一个或多个 Object 来存储这个 GameObject 的信息,例如很多 Components。因此当 Scene 有过多 GameObject 的时候,Native 内存就会显著上升。
  • 当我们看 Profiler,发现 Native 内存大量上升的时候,应先去检查 Scene。

Audio(音频):

DSP Buffer :相当于音频的缓冲。

  • 当一个声音要播放的时候,它需要向 CPU 去发送指令——我要播放声音。但如果声音的数据量非常小,就会造成频繁地向 CPU 发送指令,会造成 I\\O。

  • 当 Unity 用到 FMOD 声音引擎时(Unity 底层也用到 FMOD),会有一个 Buffer,当 Buffer 填充满了,才会向 CPU 发送“我要播放声音”的指令。

  • DSP buffer 会导致两种问题:

    • 如果(设置的) buffer 过大,会导致声音的延迟。要填充满 buffer 是要很多声音数据的,但声音数据又没这么大,因此会导致一定的声音延迟
    • 如果 DSP buffer 太小,会导致 CPU 负担上升,满了就发,消耗增加。

Foce to Mono : 强制单声道

当两个声道完全相同时可以Force To Mono,可以节省一半的内存。
在导入声音的时候有一个设置,很多音效师为了声音质量,会把声音设为双声道。但 95% 的声音,左右声道放的是完全一样的数据。这导致了 1M 的声音会变成 2M,体现在包体里和内存里。因此一般对于声音不是很敏感的游戏,会建议改成 Force to mono,强制单声道。

Format

例如IOS对MP3有硬解支持的,所以MP3的解析会快很多(Android 没有)。

Compressiont Format

声音文件在内存的存在形态(解压的、压缩的等)。

Code Size

代码也是需要加载进内存的,使用时要注意减少模板泛型的滥用。因为模板泛型在编译成C++时,会把同样的代码排列组合都编译一边,导致Code Size 大幅上升。

可以参考 Memory Management in Unity:https://learn.unity.com/tutorial/memory-management-in-unity 3.IL2CPP & Mono 的 Generic Sharing 部分。

AssetBundle

TypeTree

  • Unity 的每一种类型都有很多数据结构的改变,为了对此做兼容,Unity 会在生成数据类型序列化的时候,顺便会生成 TypeTree:当前我这一个版本里用到了哪些变量,对应的数据类型是什么。在反序列化的时候,会根据 TypeTree 来进行反序列化。
    • 如果上一个版本的类型在这个版本中没有,TypeTree 就没有它,因此不会碰到它。
    • 如果要用一个新的类型,但在这个版本中不存在,会用一个默认值来序列化,从而保证了不会在不同的版本序列化中出错,这个就是 TypeTree 的作用。
  • Build AssetBundle 中有开关可以关掉 TypeTree。当你确认当前 AssetBundle 的使用和 Build Unity 的版本一模一样,这时候可以把 TypeTree 关掉。
    • 例如如果用同样的 Unity 打出来的 AssetBundle 和 APP,TypeTree 则完全可以关掉。
  • TypeTree 好处:
    • 内存减少。TypeTree 本身是数据,也要占内存。
    • 包大小会减少,因为 TypeTree 会序列化到 AssetBundle 包中,以便读取。
    • Build 和运行时会变快。源代码中可以看到,因为每一次 Serialize 东西的时候,如果发现需要 Serialize TypeTree,则会 Serialize 两次:
      • 第一次先把 TypeTree Serialize 出来
      • 第二次把实际的东西 Serialize 出来
      • 反序列化也会做同样的事情,1. TypeTree 反序列化,2. 实际的东西反序列化。
    • 当你确定你当前的AssetBundle和你的Unity是同一个版本的时候,就可以关掉TypeTree。关掉TypeTree之后可以减少内存大小、包大小、加快运行速度。

压缩方式:使用Lz4,而不是Lzma

  • Lz4 (https://docs.unity3d.com/Documentation/ScriptReference/BuildCompression.LZ4.html)
    • LZ4HC “Chunk Based” Compression. 非常快
    • 和 Lzma 相比,平均压缩比率差 30%。也就是说会导致包体大一点,但是(作者说)速度能快 10 倍以上。
  • Lzma (https://docs.unity3d.com/2019.3/Documentation/ScriptReference/BuildCompression.LZMA.html)
    • Lzma 基本上就不要用了,因为解压和读取速度上都会比较慢。
    • 还会占大量内存
      • 因为是 Steam based 而不是 Chunk Based 的,因此需要一次全解压
      • Chunk Based 可以一块一块解压
        • 如果发现一个文件在第 5-10 块,那么 LZ4 会依次将 第 5 6 7 8 9 10 块分别解压出来,每次(chunk 的)解压会重用之前的内存,来减少内存的峰值。
  • 中国版 Unity 中有基于 LZ4 的Addressables( AssetBundle) 加密,只支持 LZ4。https://mp.weixin.qq.com/s/s9lQyunpRPJZnnaLSb9qOQ

Size & Count

  • AssetBundle 包打多大是很玄学的问题,但每一个 Asset 打一个 Bundle 这样不太好。
    • 有一种减图片大小的方式,把 png 的头都剔除出来。因为头的色板是通用的,而数据不通用。AssetBundle 也一样,一部分是它的头,一部分是实际打包的部分。因此如果每个 Asset 都打 Bundle 会导致 AssetBundle 的头比数据还要大。
  • 官方的建议是每个 AssetBundle 包大概 1M~2M 左右大小,考虑的是网络带宽。但现在 5G 的时候,可以考虑适当把包体加大。还是要看实际用户的情况。

Resources文件夹

不要使用,除非在 debug 的时候

  • Resource 和 AssetBundle 一样,也有头来索引。Resource 在打进包的时候会做一个红黑树,来帮助 Resource 来检索资源在什么位置,
  • 如果 Resource 非常大,那么红黑树也会非常大。
  • 红黑树是不可卸载的。在刚开始游戏的时候就会加载进内存中,会持续对游戏造成内存压力。
  • 会极大拖慢游戏的启动时间。因为红黑树没加载完,游戏不能启动。

Texture

Upload Buffer:和声音的DSP Buffer很像,设置填充满多大之后再推向CPU/GPU。

Read/Write : 不使用就关闭它。

  • Texture 没必要就不要开 read and write。正常 Texture 读进内存,解析完了,放到 upload buffer 里后,内存里的就会 delete 掉。
  • 但如果检测到你开了 r/w 就不会 delete 了,就会在显存和内存中各一份。

Mip Map : 像UI这些不需要的就关闭它,可以省大量内存。。

Mesh:

Read/Write :同上Texture

Compression:虽然写的是压缩,但实际效果并不一定有用,有些版本 Compression 开了不如不开,内存占用可能更严重,具体需要自己试。

6、Unity Managed Memory (托管内存):

VM内存池

Mono虚拟机的内存池,实际上VM是会返回给操作系统。

  • 返还条件是什么?
    • GC 不会把内存直接返还给系统
    • 内存也是以 Block 来管理的。当一个 Block 连续六次 GC 没有被访问到,这块内存才会被返还到系统。(mono runtime 基本看不到,IL2cpp runtime 可能会看到多一点)
  • 不会频繁地分配内存,而是一次分配一大块。

GC机制

Unity的GC机制是Boehm内存回收,是不分代的,非压缩式的。(之所以是使用Boehm是因为Unity和Mono的一些历史原因,以及目前Unity主要精力放在IL2CPP上面)

GC机制考量

  • Throughput((回收能力)
    • 一次回收,会回收多少内存
  • Pause times(暂停时长)
    • 进行回收的时候,对主线程的影响有多大
  • Fragmentation(碎片化)
    • 回收内存后,会对整体回收内存池的贡献有多少
  • Mutator overhead(额外消耗)
    • 回收本身有 overhead,要做很多统计、标记的工作
  • Scalability(可扩展性)
    • 扩展到多核、多线程会不会有 bug
  • Protability(可移植性)
    • 不同平台是否可以使用

BOEHM

  • Non-generational(不分代的)

分代是指:大块内存、小内存、超小内存是分在不同内存区域来进行管理的。还有长久内存,当有一个内存很久没动的时候会移到长久内存区域中,从而省出内存给更频繁分配的内存。

  • Non-compacting(非压缩式)

  • 当有内存被回收的时候,压缩内存会把上图空的地方重新排布。
  • 但 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 内存碎片化

为了防止内存碎片化(Memory Fragmentation),在做加载的时候,应先加载大内存的资源,再加载小内存的资源(因为Bohem没有内存压缩),这样可以保证最大限度地利用内存。

  • 为什么内存下降了,但总体内存池还是上升了?
    • 因为内存太大了,内存池没地方放它,虽然有很多内存可用。(内存已被严重碎片化)
  • 当开发者大量加载小内存,使用释放*N,例如配置表、巨大数组,GC 会涨一大截。
    • 建议先操作大内存,再操作小内存,以保证内存以最大效率被重复利用。

Zombie Memory(僵尸内存)

  • 内存泄露说法是不对的,内存只是没有任何人能够管理到,但实际上内存没有被泄露,一直在内存池中,被 zombie 掉了,这种叫 Zombie 内存。
  • 无用内容
    • Coding 时候或者团队配合的时候有问题,加载了一个东西进来,结果从头到尾只用了一次。
    • 有些开发者写了队列调度策略,但是策略写的不好,导致一些他觉得会被释放的东西,没有被释放掉。
    • 找是否有活跃度实际上并不高的内存。
  • 没有释放
  • 通过代码管理和性能工具分析,查看各个资源的引用

最佳实践

1、用Destory而不是NULL 。

2、多使用Struct。

3、使用内存池:VM 本身有内存池,但建议开发者对高频使用的小部件,自己建一个内存池。例如UI、粒子系统、子弹等。

4、闭包和匿名函数:减少使用。所有的闭包和匿名函数最后都会变成一个Class。

5、协程:只要不被释放,里面所有引用的所有内存都会存在。(用的时候生产一个,不用的时候扔掉)。

6、配置表:减少一次性使用的配置表数量;不要把整个配置表都扔进去,是否能切分下配置表。

7、单例:慎用,游戏一开始到游戏死掉,一直在内存中。

8、Unity性能分析工具UPR:https://mp.weixin.qq.com/s/n0ERE93QQZ499Xz79eTqKA

后记:

建议各位Unity开发者去看看原视频,会收获更多更详细~
https://www.bilibili.com/video/BV1aJ411t7N6

以上是关于Unity内存管理你应该知道的底层原理的主要内容,如果未能解决你的问题,请参考以下文章

Unity内存管理你应该知道的底层原理

iOS之深入解析内存管理的引用计数retainCount的底层原理

seo底层原理第2课:如果是你怎么设计搜索引擎

转Unity资源管理原理知识(干货不嫌长)

Unity内存管理的原理

Swift之深入解析内存管理的底层原理