企业官网建设流程全解析

1. 为什么Unity内存管理值得你花时间搞透

做Unity项目这些年，我见过太多团队在项目后期被内存问题拖垮。美术资源越堆越多，场景越做越大，手机跑着跑着就闪退，编辑器里Profiler一开，GC Alloc那一栏红得刺眼。更让人头疼的是，有些问题在高端机上完全看不出来，一到中低端设备就原形毕露。说到底，Unity的内存管理不像传统C++那样需要手动malloc和free，但它也绝不是“不用管”的。它有一套自己的规则，托管堆、原生内存、资源内存各管各的，你不理解这套规则，就只能在出问题的时候瞎猜。

这篇文章我想把Unity内存管理这件事从头到尾讲清楚。不管你是刚入行的新人，还是做了几年但一直没系统梳理过这块的开发者，我都希望能让你看完之后有一个完整的认知框架。我会从内存的基本分类讲起，然后深入到托管堆和GC的运作机制，再讲到资源内存的管理策略，最后给出实际项目中的优化手段和排查方法。中间会穿插大量我在实际项目中踩过的坑和总结出来的经验，这些内容你在官方文档里不一定找得到，但都是真金白银换来的。

先明确一个核心认知：Unity的内存大致可以分成三块——托管内存、原生内存和资源内存。托管内存由Mono或IL2CPP的运行时管理，受GC控制；原生内存是引擎底层和第三方库申请的，不受GC管辖；资源内存则是你加载的Texture、Mesh、AudioClip这些资源占用的空间。这三块互有关联，但管理方式完全不同。很多人一提到内存优化就只盯着GC，其实资源内存往往才是大头。搞清楚这个分类，是做好内存管理的第一步。

2. Unity内存的核心分类与底层逻辑

2.1 托管内存与GC的运行机制

托管内存是C#脚本运行时申请的内存，由Mono或IL2CPP的垃圾回收器负责回收。你在代码里new一个对象、创建一个字符串、装箱一个值类型，这些都会在托管堆上分配内存。托管堆又分为小对象堆和大对象堆，一般来说超过85KB的对象会进入大对象堆。小对象堆的分配和回收效率高，大对象堆的回收代价大且容易产生碎片。

GC的工作方式是标记-清除或者标记-压缩。Mono的GC是分代式的，分为第0代、第1代和第2代。新分配的对象在第0代，第0代满了就触发一次GC，存活的对象晋升到第1代，以此类推。第2代GC也就是Full GC，会扫描整个堆，代价最高。IL2CPP使用的是Boehm GC，不分代，每次GC都是全堆扫描，这也是为什么IL2CPP下GC卡顿往往更明显的原因。

这里有一个关键点很多人忽略：GC的触发时机不完全由你控制。你没法手动调用GC.Collect()来精确管理（虽然可以调用，但不建议频繁使用），GC会在堆内存不足时自动触发。这意味着如果你的代码每帧都在产生大量垃圾，GC就会频繁触发，造成帧率波动。我见过一个项目，每帧在Update里拼接字符串做UI显示，结果GC每几秒就触发一次，帧率像心电图一样跳。

注意：GC.Alloc这个指标在Profiler里代表的是每帧分配的托管内存量，不是GC触发的次数。优化目标是把这个值降到尽可能低，理想情况是每帧0B。

2.2 原生内存的构成与排查手段

原生内存是Unity引擎底层、图形API、音频系统、物理系统以及第三方插件申请的内存。这部分内存不受GC管理，你也没法直接控制它的分配和释放。常见的原生内存包括：图形驱动分配的显存、物理引擎的碰撞体数据、音频解码缓冲区、以及各种插件的内部数据结构。

原生内存的问题在于它不透明。你在Profiler里看到的Native内存只是一个总数，具体分配到哪了，需要更细粒度的工具来查。Unity的Memory Profiler可以抓取快照，看到每一块原生内存的归属。我一般会在怀疑有原生内存泄漏的时候，连续抓几次快照做对比，看哪一块在持续增长。

一个典型的原生内存泄漏场景是：你加载了一个AssetBundle，用完之后调用了Unload(false)，但AssetBundle内部的某些资源还被引用着，导致整个Bundle的原生内存无法释放。这种问题在编辑器里往往看不出来，因为编辑器的资源加载走的是另一套路径。只有真机测试才能暴露。

2.3 资源内存：真正的大头

资源内存是你加载的Texture、Mesh、AudioClip、AnimationClip、Material等资源占用的内存。这部分内存的大小取决于资源的导入设置和加载方式。一张4096x4096的RGBA32纹理，未压缩的情况下占用64MB内存。你项目里有十张这样的纹理，就是640MB。手机上显存和内存是共享的，这么大的占用直接就把设备压垮了。

资源内存的管理核心在于两点：什么时候加载和什么时候卸载。Unity提供了Resources、AssetBundle、Addressables等多种加载方式，每种方式对内存的影响都不一样。Resources文件夹里的资源会在游戏启动时全部加载到内存中，不管你有没有用到。这是最粗暴的方式，也是内存占用最高的方式。AssetBundle可以按需加载和卸载，但需要你自己管理引用计数和依赖关系。Addressables是在AssetBundle之上封装的一套更高级的系统，提供了引用计数和自动卸载的能力。

我个人的经验是：新项目一律用Addressables，老项目如果已经在用AssetBundle且运行稳定，不必强行迁移。Resources文件夹只用来放极少量必须常驻内存的资源，比如全局配置、字体等。

3. 托管堆优化的实操要点

3.1 哪些操作在偷偷分配内存

要优化托管堆，首先得知道内存是怎么被分配的。很多看似无害的代码，实际上每帧都在产生垃圾。我整理了一份常见的内存分配场景清单，你可以对照自己的代码排查：

• 字符串拼接：每次用+拼接字符串都会创建新的字符串对象。在Update里做这件事就是灾难。
• 装箱：把值类型赋值给object类型，或者把值类型放进非泛型集合里，都会触发装箱。
• 闭包和lambda：lambda表达式捕获外部变量时会创建闭包对象。
• 数组和List的创建：每次new一个数组或List都会在堆上分配。
• foreach遍历非泛型集合：某些情况下foreach会产生装箱。
• 协程的yield return new WaitForSeconds：每次都会创建一个新的WaitForSeconds对象。
• LINQ查询：LINQ的每个操作符都会创建中间对象。
• GetComponents系列方法：这些方法每次调用都会返回一个新数组。

我见过最夸张的一个案例是：一个项目在Update里用GetComponentsInChildren遍历子物体做状态同步，每帧分配几KB的托管内存，GC每隔十几秒就触发一次，每次触发造成几十毫秒的卡顿。后来改成在Start里缓存组件引用，GC Alloc直接降到0。

3.2 用对象池替代频繁创建销毁

对象池是减少托管内存分配最有效的手段之一。核心思想是：不再频繁地new和销毁对象，而是预先创建一批对象放在池子里，用的时候取，用完还回去。这样就把分配和回收的成本摊薄到了初始化阶段。

Unity自己也有对象池，在UnityEngine.Pool命名空间下，提供了ObjectPool、ListPool、DictionaryPool等。我一般会自己封装一个泛型的对象池，因为Unity自带的池在某些场景下不够灵活。下面是一个简化的实现思路：

public class ObjectPool<T> where T : class, new() { private Stack<T> pool = new Stack<T>(); private Func<T> createFunc; private Action<T> resetAction; public ObjectPool(Func<T> createFunc, Action<T> resetAction, int prewarmCount = 0) { this.createFunc = createFunc; this.resetAction = resetAction; for (int i = 0; i < prewarmCount; i++) { pool.Push(createFunc()); } } public T Get() { T item = pool.Count > 0 ? pool.Pop() : createFunc(); return item; } public void Return(T item) { resetAction?.Invoke(item); pool.Push(item); } }

这个池子的关键在于resetAction，它负责把对象恢复到初始状态。比如一个子弹对象，归还时需要重置位置、速度、生命周期等属性。如果忘了重置，下次取出来就会带着上次的状态，产生难以排查的bug。

提示：对象池不是万能的。如果对象的创建频率很低，比如几秒才创建一个，那用不用池子差别不大。池子主要用在每帧或高频创建的场景，比如子弹、特效、飘字、伤害数字等。

3.3 结构体与类的选择策略

在C#里，结构体是值类型，分配在栈上（或者作为类的字段时内联在堆对象里），类是引用类型，分配在堆上。这意味着使用结构体可以减少托管堆的分配。但结构体也不是随便用的，它有几个限制：不能继承、默认不能为null、赋值时是拷贝语义。

我的一般原则是：如果一个数据结构很小（小于16字节）、生命周期短、不需要多态，就优先用结构体。比如Vector3、Color、RaycastHit这些Unity内置的类型都是结构体。你自己定义的数据结构，比如一个伤害信息、一个配置项，如果满足上述条件，也可以考虑用结构体。

但要注意结构体的拷贝开销。如果一个结构体很大，比如包含十几个字段，那每次传参和赋值都会产生拷贝，反而影响性能。一般来说，结构体的大小控制在16到32字节以内比较合适。超过这个范围，就该考虑用类了。

还有一个坑是：结构体作为接口的实现或者放在List里时，可能会被装箱。比如你把一个结构体放进List

3.4 字符串处理的避坑指南

字符串是托管内存分配的重灾区。C#的字符串是不可变的，任何修改操作都会创建新的字符串对象。在游戏循环里做字符串操作，几乎必然导致GC压力。

我总结了几个字符串处理的实用技巧：

• 避免在Update里拼接字符串。如果UI需要显示变化的数值，用TextMeshPro的SetText方法配合格式化参数，或者用StringBuilder缓存。
• 用StringBuilder替代频繁的字符串拼接。StringBuilder内部维护一个字符数组，拼接时不会创建新对象。但要注意StringBuilder本身也要缓存复用，不要每次用都new一个。
• 用字符串比较时避免不必要的分配。比如string.Equals(a, b)比a == b在某些情况下更高效，因为后者可能会调用string.Concat。
• 用HashCode替代字符串做字典键。如果你的字典键是字符串，考虑在初始化时把字符串转成int类型的哈希值，用int做键。
• 避免使用string.Format。string.Format内部会装箱参数并创建新字符串。可以用C#的字符串插值替代，但插值在底层也是string.Format，所以最好的方式还是用StringBuilder或者TextMeshPro的格式化功能。

我实测过一个案例：一个伤害飘字系统，原本每帧用string.Format拼接伤害数值，GC Alloc在高峰期达到每帧2KB。改成用TextMeshPro的SetText配合预缓存的StringBuilder之后，GC Alloc降到0。

4. 资源内存的管理与优化

4.1 纹理资源的导入设置与内存占用

纹理通常是资源内存中占用最大的一块。一张纹理占用的内存大小可以用这个公式估算：宽度 × 高度 × 每像素字节数 × Mipmap层级数。每像素字节数取决于纹理格式，RGBA32是4字节，RGB24是3字节，RGBA16是2字节，等等。

纹理格式的选择直接决定了内存占用和画质。我的经验是：

• UI纹理：用RGBA32或者RGBA16，关闭Mipmap，因为UI通常不需要缩放。
• 3D模型纹理：用压缩格式，比如ASTC、ETC2、PVRTC。压缩格式的内存占用是未压缩的1/4到1/8，但画质会有损失。
• 法线贴图：用压缩格式，但要注意压缩算法对法线的精度影响。
• 光照贴图：用RGBM或者Half格式，根据项目需求选择。

Mipmap是一个容易被忽略的点。开启Mipmap后，纹理内存会增加约33%，但渲染性能会提升，因为远处物体使用低级别的Mipmap，减少了纹理采样带宽。对于3D场景中的纹理，我一般建议开启Mipmap；对于UI纹理，关闭。

还有一个重要的设置是Read/Write Enabled。开启后，纹理会在内存中保留一份CPU可访问的拷贝，内存占用翻倍。除非你需要在代码里读取纹理像素，否则一律关闭。

4.2 AssetBundle的加载与卸载策略

AssetBundle是Unity资源管理的核心机制。它的内存管理有几个关键点：

加载方式：AssetBundle.LoadFromFile是最高效的方式，它直接从磁盘加载，不需要经过托管堆。LoadFromMemory和LoadFromStream会占用额外的托管内存，一般不推荐。

卸载方式：AssetBundle.Unload(false)只卸载AssetBundle对象本身，不卸载已经加载的资源。Unload(true)会卸载AssetBundle和所有已加载的资源，但如果还有引用指向这些资源，就会导致资源丢失。我一般用Unload(false)，然后手动管理资源的卸载。

引用计数：AssetBundle本身不提供引用计数，需要你自己维护。我通常会在加载资源时记录引用，在释放时减少引用，引用为0时才真正卸载。

依赖关系：AssetBundle之间有依赖关系，加载一个Bundle时需要先加载它依赖的所有Bundle。如果依赖的Bundle被卸载了，就会导致资源丢失。我一般会在打包时生成依赖关系表，加载时按表加载。

一个常见的坑是：同一个资源被多个Bundle引用。比如一个材质被多个模型使用，如果这个材质被打进了多个Bundle，就会在内存中存在多份拷贝。解决方法是把共享资源单独打成一个Bundle，其他Bundle依赖它。

4.3 Addressables系统的实战经验

Addressables是Unity官方推荐的资源管理系统，它在AssetBundle之上封装了引用计数、依赖管理、异步加载等功能。我用Addressables做过几个项目，总结了一些经验：

分组策略：Addressables的分组决定了资源的打包方式。我一般会按功能模块分组，比如UI、角色、场景、特效各一组。同一组内的资源会被打进同一个Bundle，所以要把同时加载的资源放在同一组，避免频繁的Bundle切换。

加载方式：Addressables提供了LoadAssetAsync和LoadSceneAsync等异步加载接口。异步加载不会阻塞主线程，但需要注意加载完成后的回调时机。我一般会用async/await来简化异步代码的编写。

释放方式：Addressables使用引用计数来管理资源。每次LoadAssetAsync会增加引用计数，每次Release会减少引用计数。引用计数为0时，资源会被自动卸载。但要注意，Addressables的卸载是延迟的，不会立即释放内存。

预加载：Addressables支持预加载，可以在游戏启动时预先加载一些常用资源。但预加载会占用内存，需要权衡。

我踩过的一个坑是：Addressables的引用计数和UnityEngine.Object的引用是两回事。你LoadAssetAsync得到一个GameObject，即使你Destroy了这个GameObject，Addressables的引用计数也不会自动减少。你必须显式调用Release。这个坑让我在一个项目里多占了几十MB内存，排查了很久才发现。

5. 内存问题的排查与实战案例

5.1 用Profiler定位内存问题

Unity Profiler是排查内存问题的第一工具。我一般会关注这几个指标：

• Total Allocated：当前帧分配的总内存。
• GC Alloc：当前帧分配的托管内存。
• Total Reserved：托管堆保留的总内存。
• Total Used：托管堆实际使用的内存。
• Texture Memory：纹理占用的内存。
• Mesh Memory：网格占用的内存。
• Audio Memory：音频占用的内存。

在Profiler里，你可以看到每一帧的内存分配情况。如果GC Alloc持续很高，说明代码里有频繁的托管内存分配。如果Texture Memory持续增长，说明有纹理没有被正确卸载。

Memory Profiler是更细粒度的工具，它可以抓取内存快照，看到每一个对象的引用链。我一般会在怀疑有内存泄漏的时候，连续抓几次快照做对比，看哪些对象在持续增长。

5.2 常见内存问题速查表

5.3 一个真实的内存优化案例

我之前接手过一个项目，游戏在低端机上跑几分钟就闪退。用Profiler一查，发现每次切换场景时内存都会增长几十MB，而且不释放。排查后发现几个问题：

第一，场景切换时没有卸载上一个场景的AssetBundle。代码里只调用了SceneManager.LoadScene，但没有调用AssetBundle.Unload。导致上一个场景的资源一直留在内存里。

第二，UI纹理没有压缩，全部是RGBA32格式，而且开启了Read/Write Enabled。几十张UI图加起来占了几百MB内存。

第三，代码里有一个全局的缓存字典，缓存了所有加载过的资源，但从来没有清理过。这个字典本身占用的内存不大，但它持有的资源引用导致这些资源无法被GC回收。

针对这三个问题，我做了以下优化：

• 在场景切换时，先卸载上一个场景的AssetBundle，再加载新场景。
• 把所有UI纹理改成ASTC压缩格式，关闭Read/Write Enabled。
• 把全局缓存字典改成弱引用字典，或者定期清理不再使用的缓存项。

优化之后，游戏在低端机上的内存占用从原来的800MB降到了300MB左右，闪退问题基本解决。

5.4 内存优化的几个原则性建议

做了这么多项目，我总结了几个内存优化的原则：

第一，尽早关注内存。不要等到项目后期才想起来优化内存，那时候资源已经堆成山了，改起来成本极高。我一般会在项目初期就建立内存监控机制，每次提交代码都跑一下内存测试。

第二，用数据说话。不要凭感觉猜哪里占内存，用Profiler和Memory Profiler去测。我见过太多人凭直觉优化，结果优化了不占内存的地方，真正的问题反而没解决。

第三，区分平台。不同平台的内存管理机制不同，编辑器、iOS、Android、PC各有各的特点。编辑器里正常不代表真机正常，高端机正常不代表低端机正常。一定要在目标设备上测试。

第四，留足余量。不要贴着设备的内存上限做优化，要留出至少20%的余量。因为系统本身要占内存，其他应用也可能占内存，你的游戏不是独占设备的。

第五，持续监控。内存问题不是优化一次就一劳永逸的，随着项目迭代，新的资源、新的代码都可能引入新的内存问题。我一般会在CI流程里加入内存测试，每次构建都自动跑一遍，发现异常及时报警。

6. 进阶话题与工具链

6.1 托管堆碎片化与压缩

托管堆碎片化是一个比较隐蔽的问题。当你在堆上分配和释放不同大小的对象时，堆里会出现很多空洞。这些空洞虽然总大小够用，但可能没有一个连续的空间能容纳一个大对象，导致GC频繁触发或者分配失败。

Mono的GC有压缩功能，可以在GC时移动对象来消除碎片。但压缩的代价很高，会暂停所有线程。IL2CPP的Boehm GC默认不压缩，碎片化问题更严重。

减少碎片化的方法主要有两个：一是尽量分配大小一致的对象，二是用对象池复用对象。我一般会避免在运行时频繁创建和销毁大对象，如果确实需要，就用池子管理。

6.2 用Unsafe代码和NativeArray绕过GC

对于性能敏感的场景，Unity提供了NativeArray和Unsafe代码来绕过托管堆。NativeArray是Unity.Collections命名空间下的一个结构体，它分配在原生内存中，不受GC管理。你可以用NativeArray来存储大量数据，比如顶点数据、粒子数据、路径点等。

使用NativeArray需要注意几点：一是需要手动释放，用Dispose方法；二是不能直接访问，需要通过索引；三是不能作为类的字段长期持有，因为它是结构体，拷贝时会出问题。

Unsafe代码需要开启Allow 'unsafe' Code选项，可以用指针直接操作内存。但Unsafe代码容易出错，我一般只在性能瓶颈非常明确的情况下才用。

6.3 内存监控与自动化测试

在团队协作中，内存监控需要自动化。我一般会做这几件事：

• 在CI流程里加入内存测试：每次构建后自动运行游戏，加载所有场景，记录内存峰值，超过阈值就报警。
• 在游戏里加入内存监控面板：开发阶段可以实时查看内存占用，方便定位问题。
• 定期做内存快照对比：每周或每个版本做一次内存快照，和上一个版本对比，看有没有异常增长。

这些措施看起来麻烦，但长期来看能省下大量排查时间。我经历过一个项目，因为没有内存监控，上线后才发现内存泄漏，紧急修复导致延期了两周。如果早点做监控，这个问题在开发阶段就能发现。

6.4 不同平台的内存管理差异

不同平台的内存管理机制差异很大，我简单说一下几个主要平台的特点：

iOS：使用ARC（自动引用计数）管理原生内存，托管内存由IL2CPP的Boehm GC管理。iOS对内存的限制比较严格，超过一定阈值就会被系统杀掉。iOS的纹理压缩格式是PVRTC和ASTC。

Android：托管内存由Mono或IL2CPP管理，原生内存由系统管理。Android设备碎片化严重，不同厂商的内存管理策略不同。Android的纹理压缩格式是ETC2和ASTC。

PC：内存相对充裕，但也不能无限制使用。PC平台的纹理压缩格式是DXT和BC系列。

主机：内存管理最严格，需要精确控制每一MB内存。主机平台的纹理压缩格式是平台专用的。

跨平台项目需要针对不同平台做不同的内存策略。我一般会在代码里用预处理指令区分平台，针对不同平台设置不同的纹理质量、加载策略和缓存大小。

7. 我个人的一些经验体会

写了这么多，最后分享几个我在实际项目中总结出来的、文档里不会写的经验。

关于GC：不要试图完全消除GC，那不现实。目标是让GC的频率和影响降到可接受的范围。我一般会把GC Alloc控制在每帧200B以内，这样GC可能几分钟才触发一次，玩家基本感知不到。

关于资源加载：异步加载不一定比同步加载好。异步加载虽然不阻塞主线程，但它会增加代码复杂度，而且异步加载的资源在加载完成前会占用额外的内存。对于小资源，同步加载可能更合适。

关于内存泄漏：大部分内存泄漏不是真正的泄漏，而是引用没有及时释放。我排查内存泄漏的第一步永远是检查引用链，看是谁在持有不该持有的引用。

关于工具：Profiler和Memory Profiler是基础工具，但有时候你需要更专业的工具。比如Xcode Instruments、Android Studio Profiler、RenderDoc等。不要局限于Unity自带的工具。

关于优化顺序：先优化大头，再优化小头。纹理占内存最多就先优化纹理，GC占CPU最多就先优化GC。不要一上来就抠那些只占几KB的小对象，投入产出比太低。

内存管理这件事，说到底是经验和意识的积累。你做得越多，对内存的敏感度就越高，写代码的时候自然就会避开那些会产生垃圾的写法。希望这篇文章能帮你建立起一个完整的认知框架，在实际项目中少踩一些坑。