本文首发公众号洪流学堂。洪流学堂,让你快人几步。
本文主要是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
- Incremental GC(渐进式 GC)
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