做了几年Unity开发最让我头疼的不是玩法逻辑也不是渲染效果而是Unity资源管理。内存峰值、加载卡顿、包体膨胀、版本更新失败这些问题追根溯源大半都出在资源管理上。这篇笔记把我这些年整理资源、规划目录、处理AssetBundle和内存泄漏的经验做了个汇总适合刚接触Unity资源管理的开发者也适合项目已经跑起来但总觉得卡顿、内存不对劲的团队参考。内容全部来自实际项目踩坑没有那种只会讲概念的泛泛之谈。1. 资源管理的整体规划1.1 为什么资源管理决定项目质量上限很多团队立项时想的是玩法、美术风格、运营活动资源管理基本靠开发过程中临时抱佛脚。等游戏做到中后期你会发现资源问题变成了一颗不知道什么时候会炸的雷某次版本更新后启动变慢因为热更包把原本该拆分的资源全打进了主包某个关卡切换时掉帧因为场景里加载了一堆从不复用的大贴图某台低配手机上闪退因为内存峰值超出了设备上限。我见过最典型的情况是项目初期图省事把所有UI资源、角色模型、音频全丢进Resources目录用Resources.Load随手加载。前期没问题打包速度也快但项目大了之后Resources目录里的所有东西都会无条件打进最终包体启动时还要做索引加载包体翻倍不说内存里还会残留大量无用资源。更严重的是Resources目录无法参与增量更新每次发版都要全量替换运营活动根本没法做。所以资源管理不是技术债而是项目的骨架。骨架歪了后面所有模块都会歪。资源管理的目标其实很清楚让资源按需加载、及时释放、可控更新、结构清晰。围绕这四点去规划后面的细节才有意义。1.2 目录结构先把家底盘清楚动手写代码之前第一件事是整理Assets目录。我见过太多项目Assets下平铺三层文件夹叫NewFolder 1temp2资源名像碎纸片一样散着。这种目录别说团队协作自己隔一个月回去都找不到东西。我的习惯是按下述结构来组织Scenes只放场景文件按关卡或者流程再建子目录Scripts代码按模块分但注意不要把编辑器的辅助脚本和运行时脚本混在一起Art美术原始资源下面再分Models、Textures、Materials、Shaders等子目录Audio音频资源分为BGM、SFX、Voice子目录Prefabs预制体按模块与场景粒度区分Resources这个目录保留但严格限制只放启动时必须同步加载的配置型资源数量控制在个位数级别Bundles需要打进AssetBundle或交给Addressables管理的动态资源与Resources隔离命名规范也值得在一开始就定死。资源前缀我习惯用类型标识比如纹理用tex_开头、音频用sfx_或bgm_开头、预制体用prefab_或ui_开头、材质用mat_开头。配合小驼峰命名文件名就不会乱成一锅粥。例如tex_player_sword_blade、sfx_ui_button_click、prefab_enemy_guard_01。这样配合搜索、筛选资源效率和准确性都会高不少。目录和命名规范不需要多花哨关键是统一执行。只要项目里有一个人乱建文件夹后面所有人都会跟着乱。团队里最好在项目初期就把这个规范写进文档里并在Code Review时顺手检查。1.3 资源分类方案按模块还是按更新频率整理资源时先要回答一个问题一个资源到底属于什么维度按功能模块分还是按类型分这是两种完全不同的思路。按类型分理解起来很直观就是纹理放一堆、模型放一堆。但对于一个角色资源来说模型、贴图、材质、动画、音效甚至技能特效都有关联拆开放在不同类型目录下就会造成管理困难。所以我更推荐按功能模块为主、类型为嵌套来组织。比如角色目录下面再拆分Models、Textures、Materials等二级目录Assets/Art/Characters/Knight/Models、Assets/Art/Characters/Knight/Textures。还有一个维度很容易被忽略按更新频率分类。这是做热更新方案时必须考虑的。启动必需资源、场景内高频资源、版本更新资源、活动临时资源它们的加载时机和存储位置完全不一样。启动必需资源应该留在本地包内高频场景资源可以做成常驻内存版本更新资源通过AssetBundle下载运营活动资源走后端动态下发。把这些资源按更新频率拆开后面搭建更新流程才会顺手。我的经验是多问自己一个问题这个资源如果做成可下载的下载失败时玩家还能不能正常玩答案决定它的存储与加载方案。规划阶段宁可多花两天把分类想清楚也不要在项目中期推倒重来。2. 资源加载方案怎么选2.1 References、Resources与AssetBundle到底怎么取舍很多初学者对加载方式的理解是想要某个资源用Resources.Load最方便或者干脆做成全局静态引用。这种思路在Demo里没问题但到了正式项目里就是灾难。先看三种常见方案的适用场景直接引用在Inspector面板把资源拖到脚本字段里。优点是非常直观、加载速度最快因为资源是随场景一起加载的缺点是会导致资源被场景持有如果场景之间共享大资源要么预先加载好要么就只能反复加载。适合UI图集、场景固定物件这类确定存在的资源。Resources.Load优点是代码里随手就可以取到资源适合配置表、初始化素材缺点是Resources目录下所有资源都会打进主包无法增量更新且运行时对资源索引、加载解析有额外的内存开销。适合数量极少的启动配置不适合游戏内容资源。AssetBundle与Addressables优点是支持独立打包、运行时下载、按需加载和卸载是目前游戏项目做更新、做内存控制的主流方案缺点是引入复杂度需要处理依赖、引用计数、下载失败等场景。适合正式运营项目里的核心内容资源。很多团队会有一个误区就是把Resources当成省事加载器后面又因为包体、内存问题被迫迁移到AssetBundle迁移成本高到让人崩溃。除非项目非常小且不做更新否则我建议从一开始就选择动态加载方案。2.2 Addressables实操从接入到首次加载Addressables是Unity官方推荐的资源管理方案底层封装了AssetBundle提供了按地址加载、自动管理依赖、引用计数、远程分组等能力。对大部分项目来说直接用Addressables会比手工拼AssetBundle省心得多。接入流程其实很清晰打开Package Manager安装Addressables包。打开Window Asset Management Addressables Groups创建分组把需要动态加载的资源拖进组里并设置Addressable名称。名称就是加载时的key。给资源设置加载类型Addressable表示动态加载Packed AssetBundle表示打进包里Local和Remote决定存放位置。代码加载时用Addressables.LoadAssetAsync (key)或直接给字段声明AssetReference在Inspector里拖资源。我用AssetReference的场景比较多它有一个天然的好处Prefab上关联的资源是强引用关系编辑器里能直观看到引用的资源对象构建时Addressables会自动把依赖资源打进对应Bundle不会出现手工管理依赖时漏打包的情况。举个例子一个加载角色预制体并实例化的逻辑可以这样写using UnityEngine; using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; using UnityEngine.ResourceManagement.ResourceProviders; public class SpawnManager : MonoBehaviour { public AssetReference playerPrefabRef; private GameObject currentInstance; public void SpawnPlayer() { if (currentInstance ! null) { playerPrefabRef.ReleaseInstance(currentInstance); } playerPrefabRef.InstantiateAsync().Completed handle { if (handle.Status AsyncOperationStatus.Succeeded) { currentInstance handle.Result; } }; } }这里最关键的是释放操作。加载一个资源并实例化后如果只调用Destroy而不调用Release资源仍驻留在内存中。Addressables用引用计数管理生命周期每加载一次计数加一实例化出的对象销毁时应当调用ReleaseInstance而不是直接Destroy否则计数永远不会归零最终内存泄漏。这一段我踩过不只一次每次排查漏资源最后定位都是这里。2.3 纹理、音频、模型导入设置的隐藏坑资源导入设置看起来属于美术那边的事但恰恰是资源管理中最容易爆内存和卡顿的环节。开发阶段用默认设置、用原图直接跑到了提测阶段才发现内存爆表再去优化已经晚了。纹理方面最重要的是贴图格式与Max Size。移动端常见压缩格式有ASTC和ETC2ASTC在带宽与画质上的综合表现更好Android与iOS主流设备都支持。iOS上可用ASTC 6x6起手Android设备兼容性稍好推荐ASTC 4x4作为底线必要时对UI贴图单独做不同压缩策略。Max Size要按实际使用尺寸来控制一张1024规格的UI图就不要让它以4096的尺寸存在。另外如果贴图用在UI上Generate Mip Maps通常是不需要的这个选项开着会白白多出三分之一的内存空间。音频的三种加载类型要分清Decompress on Load适合短小音效加载时会直接解码播放延迟低Compressed in Memory适合BGM解码播放减少内存Streaming适合长音频邊下邊播但必须注意流式播放对I/O的占用。很多音效卡顿、切换缓慢的问题根源就是全部音频都选了Decompress on Load启动时一次性解码几千个音频文件。模型的Read/Write Enabled选项默认可能是打开的但正式包必须关闭否则Mesh数据会同时留一份在CPU端和GPU端内存翻倍又毫无收益。顺便可以打开Mesh Compression来压缩顶点数据静态网格收益明显。动画文件与骨骼模型尽量用压缩动画格式。导入设置的规律总结起来就是先确认资源真正的使用上限再按上限去设置导入参数不要让Unity帮你做最保守、浪费内存的决定。3. 生命周期与内存管理实操3.1 引用计数与卸载机制的核心资源管理的核心不是加载而是释放。我观察过很多团队他们能花一整周搞定资源加载方案但是卸载策略基本没有设计过。结果资源越加载越多最后进程被系统杀掉玩家在微信后台看到的是闪退两个字。想要释放准确必须先理解Unity资源的内存归属。总体上看资源进入内存后有几类场景中的GameObject由场景管理资源对象Texture、Mesh、AudioClip则有对应的引用来源。如果你用Resources.Load或者AssetBundle加载资源实例化出的对象销毁不代表资源本身可以被回收必须调用对应的卸载接口。AssetBundle里最典型的坑是Unload(bool unloadAllLoadedObjects)。传true会把该Bundle下所有已加载的资源对象一并卸载看起来方便但如果有其他资源正引用了这里面的某个对象卸载后就会生成Missing引用材质变粉色、贴图变紫方格。传false只卸载Bundle的镜像不卸载资源给资源做后续释放或再次加载留出空间。常规做法是场景切换时对旧场景的Bundle统一调用Unload(true)但要先确保没有其他模块仍在引用它的对象。Addressables的引用计数规则我个人理解成一个简化版的共享引用模型。每次成功LoadAssetAsync会为资源计数加一Release时减一实例化的资源计数同样累加通过ReleaseInstance减一。只有计数归零后资源才会真正进入可卸载状态。若依赖加载失败或提前释放引用计数会变成不稳定的悬挂状态运行期报错很难排查。所以代码里尽量用一个统一封装去调加载、实例化和释放不要在业务代码里横七竖八地直接调Addressables。一个轻量的引用计数封装思路是public class AssetHandle { private Dictionarystring, int refCounts new Dictionarystring, int(); public void Retain(string key) { if (refCounts.ContainsKey(key)) { refCounts[key]; } else { refCounts[key] 1; } } public void Release(string key) { if (!refCounts.ContainsKey(key)) return; refCounts[key]--; if (refCounts[key] 0) { Addressables.Release(key); refCounts.Remove(key); } } }知道引用数归零并调用Release后再配合Resources.UnloadUnusedAssets去做Phase 2回收时机上会安全许多。UnloadUnusedAssets是一个会触发引擎GC的接口高频调用反而会增加卡顿我的建议是在场景切换或确认大批资源不再使用的时机去触发不要每一帧都执行。3.2 AssetBundle构建与依赖管理Addressables虽然封装了AssetBundle但很多项目出于定制化热更方案的需求还是选择手工构建AssetBundle。此时最核心的问题是依赖管理。我举个例子有包A包含一个材质材质引用了一张共享贴图而这张共享贴图同时被包B和包C使用。如果打包脚本没有显式处理依赖构建时这张贴图可能会被重复打进A、B、C三个Bundle里最终包体膨胀加载时还会产生多个相同资源的副本内存被白白多吃一块。构建AssetBundle前强烈建议先生成依赖清单并做依赖预分析。Unity的BuildAssetBundleOptions里有一个选项叫ForceRebuildAssetBundle还有DisableWriteTypeTree但最关键的其实是自带生成的Manifest文件。每次构建都会输出清单文件其中详细列出了每个Bundle依赖的其他Bundle。加载某个Bundle前应该先加载它的Manifest确认依赖链再按顺序加载依赖包否则大概率碰到资源丢失、依赖加载失败的问题。常规构建脚本可以这样写using UnityEditor; using System.IO; public class BuildBundles { [MenuItem(Tools/Build AssetBundles)] public static void BuildAllBundles() { string outputPath Path.Combine(Application.streamingAssetsPath, AssetBundles); if (!Directory.Exists(outputPath)) Directory.CreateDirectory(outputPath); BuildPipeline.BuildAssetBundles(outputPath, BuildAssetBundleOptions.ChunkBasedCompression, BuildTarget.Android); } }这只是基础模板实际使用中你还得根据模块创建多个构建Map把资源按分组规则映射到不同的Bundle。我强烈建议给Bundle分两个层级一级为逻辑模块比如UI、角色、场景、技能音效二级为资源变体比如不同材质质量的贴图。按逻辑模块打包解决的是加载粒度按更新频率打包解决的是热更包体积。如果一个包打了整整一个关卡的全部资源那每次改动哪怕一行文字整个包都得重新下载。依赖问题排查时最有效的工具是AssetBundle Browser图形化查看每个Bundle里包含的资源以及它的依赖列表。看到重复资源就回到打包分组脚本里维护一个全局依赖表确保共享资源单独打一个依赖包不要让业务包互相嵌套依赖。3.3 Profiler内存分析实战我排查内存问题最长的一次花了两个工作日最后发现根源是某段代码每帧加载了一张相同的贴图却又没有释放。这种问题如果依赖肉眼读代码效率太低一定要用Profiler去定位。打开Profiler后在Memory分类里重点关注Texture2D、Mesh、AudioClip、AnimationClip这几类资源。每类资源都有当前实例的Total Count和Total Size。当连续切场景或反复进入同一个玩法后如果Total Count在增长说明资源被重复加载且没有被释放。这个时候在Profiler里找到对应资源名双击可以跳到引用视图里看到它被哪个对象持有。有一个最简单也常被忽略的检查方法在编辑器里跑Game视图一段时间然后执行一次Resources.UnloadUnusedAssets再切到Profiler看资源数量变化。如果数量下降不明显说明有强引用在持有资源对象。此时要重点检查静态字段、单例对象、事件监听里是不是把资源对象缓存了下来。Audios和Shader同样值得关注。某些Shader会在运行时变体加载每切换一个档位就会多一份变体这也是内存累积的来源之一。如果发现Shader占用异常优先检查Always Included Shaders列表是不是把很少用到的Shader加进了全局列表。我写了一个简单的工具函数专门用来统计当前所有已加载资源并按大小排序在编辑器MenuItem里直接调用定位大资源非常方便using UnityEditor; using UnityEngine; using System.Collections.Generic; using System.Text; public class ResourceStatsWindow : EditorWindow { [MenuItem(Tools/Dump Loaded Resources)] public static void DumpLoadedResources() { var roots Resources.FindObjectsOfTypeAllUnityEngine.Object(); var dict new Dictionarystring, long(); foreach (var obj in roots) { if (obj is Texture2D t) { long size 0; try { size t.dimension TextureDimension.None ? 0 : (long)t.width * t.height * 4; } catch { } dict[obj.name] size; } } StringBuilder sb new StringBuilder(); foreach (var kv in dict) { sb.AppendLine(${kv.Key}: {kv.Value / 1024f:F1} KB); } Debug.Log(sb.ToString()); } }这个工具不算精致但足够帮你定位到现阶段项目中哪些贴图占用了异常高的内存。排查到具体资源后再回过去看它的加载时机、引用对象、打包分组基本都能把内存问题找到。4. 常见问题与排查技巧实录4.1 高频问题速查表把我在多个项目里遇到的资源管理问题汇总成了下面这个速查表项目里出了类似问题可以直接照着处理。现象可能原因解决思路场景切换后内存不降旧场景资源被静态引用或DontDestroyOnLoad持有用Profiler查强引用持有者清理静态缓存与事件监听贴图重复加载、数量持续增长同一资源被多个Bundle重复包含或反复Load统一走引用计数封装共享资源单独打包加载Bundle时报依赖缺失Bundle加载顺序不对或Manifest未读取加载前先读取依赖清单按顺序加载依赖包模型导入后颜色丢失或发紫材质引用的贴图或Shader未随模型打包检查Bundle依赖关系确认Shader与贴图在同包或依赖包中UI加载卡顿UI图集颗粒太细加载点数过多合并Sprite Atlas减少单个界面加载的贴图数量启动加载时间过长Resources目录资源过多或启动场景绑定了大量资源将Resources资源迁至Addressables或AssetBundle冷启动只加载核心内容热更包过大按模块维护的Bundle粒度太粗或没有做增量打包检查构建选项按更新频率拆包共享资源独立成公共包音频播放卡顿大量音频使用Decompress on LoadBGM改为Compressed in Memory或Streaming音效按需加载这张表只是给排查方向。每个问题在具体项目里的表现会略有不同但排查思路通常是先确认资源是否被正确加载再确认是否被正确释放最后看是否被正确打包。4.2 我的独家避坑清单这里写几条我后来一直坚持的规则每条都是实打实踩出来的坑。第一场景里的直接引用必须克制。如果一个Prefab在Inspector里直接挂了一个大贴图或大模型那么这个资源会跟随场景常驻内存哪怕场景里根本看不到它。做Prefab时尽量把它做轻只引用自己需要的最小资源。第二Resources目录越空越好。我见过有项目把全部配置表、所有UI图集、所有角色模型全放进Resources目录里最后包体直接从200MB涨到600MB启动时间从2秒涨到8秒。把Resources只留给启动必需的少量配置其余全部迁到动态加载路径。第三图集不是越大越好。图集过大加载的整张大图在内存中占用的空间会很大图集过小又会造成Draw Call上升。我的处理方式是UI界面按界面成图集公共元素单独成小图集避免为了节省内存把整个UI做成一张巨型贴图导致内存翻倍。第四Addressables的引用计数必须由统一封装管理。业务代码里直接调用加载与释放一定会在某个逻辑分支上漏掉Release。我自己封了一个资源加载服务之后资源泄漏这个Bug类别的出现频率大幅下降。第五正式包一定要关掉不必要的资源选项。Read/Write Enabled、Generate Mip Maps、多余的Shader变体、过高的Max Size每项看起来都只是多占一点内存叠加起来就能压垮低端机。第六做热更方案时别忘了老版本兼容。Bundle结构一旦发布出去后续修改Bundle分组名、依赖关系会导致老版本客户端加载失败所以热更目录和分组策略要预留扩展空间不要随意改包名。4.3 团队协作中的资源管理规范资源管理不只是个人技术问题更是团队协作问题。我见过几个项目因为团队之间没有统一的资源管理约定最后沦为互相甩锅美术说资源没问题程序说是加载写错了策划说资源在策划表里找不到。推荐在项目启动时建立一份简短的《资源管理规范文档》包含三块内容目录结构与命名规范、加载与释放规则的接口约定、资源导入参数的表单。表格形式可以这样组织资源类型UI贴图、角色模型、BGM、音效路径前缀UI_、Char_、BGM_、SFX_默认加载方式Addressables异步加载释放方式通过统一资源服务Release常用资源类型都可以在规范文档中给出一个示例配置例如纹理压缩默认ASTC 6x6角色模型Max Size为1024音效文件统一用16bit、44.1kHz的WAV。这些约定看似琐碎却能显著减少后期资源内存占用过高、Debug成本高这类问题。另外代码Review时建议把资源加载与释放是否成对出现作为必查项。团队中一旦出现复制一段加载代码但忘了释放的情况后面写出来的功能都会带病上线。资源管理这件事提前定规矩比事后再补救值得多。我在实际项目里还有个体会每当内存、包体出问题第一反应不是去写优化代码而是先检查是不是有谁的写法绕过了统一的资源服务、或者直接用了Resources.Load。绝大多数资源相关的疑难杂症最后都能归结到一个没有按既定规范做的不起眼改动上面。如果你也在维护一个快被资源问题拖垮的项目先把目录、命名、加载释放规则统一了再谈具体的优化手段效果会好得多。 
长河君 · 2026/10/16 9:57:17 · 阅读 1.2k Unity资源管理实战：AssetBundle、Addressables与内存调优
做了几年Unity开发最让我头疼的不是玩法逻辑也不是渲染效果而是Unity资源管理。内存峰值、加载卡顿、包体膨胀、版本更新失败这些问题追根溯源大半都出在资源管理上。这篇笔记把我这些年整理资源、规划目录、处理AssetBundle和内存泄漏的经验做了个汇总适合刚接触Unity资源管理的开发者也适合项目已经跑起来但总觉得卡顿、内存不对劲的团队参考。内容全部来自实际项目踩坑没有那种只会讲概念的泛泛之谈。1. 资源管理的整体规划1.1 为什么资源管理决定项目质量上限很多团队立项时想的是玩法、美术风格、运营活动资源管理基本靠开发过程中临时抱佛脚。等游戏做到中后期你会发现资源问题变成了一颗不知道什么时候会炸的雷某次版本更新后启动变慢因为热更包把原本该拆分的资源全打进了主包某个关卡切换时掉帧因为场景里加载了一堆从不复用的大贴图某台低配手机上闪退因为内存峰值超出了设备上限。我见过最典型的情况是项目初期图省事把所有UI资源、角色模型、音频全丢进Resources目录用Resources.Load随手加载。前期没问题打包速度也快但项目大了之后Resources目录里的所有东西都会无条件打进最终包体启动时还要做索引加载包体翻倍不说内存里还会残留大量无用资源。更严重的是Resources目录无法参与增量更新每次发版都要全量替换运营活动根本没法做。所以资源管理不是技术债而是项目的骨架。骨架歪了后面所有模块都会歪。资源管理的目标其实很清楚让资源按需加载、及时释放、可控更新、结构清晰。围绕这四点去规划后面的细节才有意义。1.2 目录结构先把家底盘清楚动手写代码之前第一件事是整理Assets目录。我见过太多项目Assets下平铺三层文件夹叫NewFolder 1temp2资源名像碎纸片一样散着。这种目录别说团队协作自己隔一个月回去都找不到东西。我的习惯是按下述结构来组织Scenes只放场景文件按关卡或者流程再建子目录Scripts代码按模块分但注意不要把编辑器的辅助脚本和运行时脚本混在一起Art美术原始资源下面再分Models、Textures、Materials、Shaders等子目录Audio音频资源分为BGM、SFX、Voice子目录Prefabs预制体按模块与场景粒度区分Resources这个目录保留但严格限制只放启动时必须同步加载的配置型资源数量控制在个位数级别Bundles需要打进AssetBundle或交给Addressables管理的动态资源与Resources隔离命名规范也值得在一开始就定死。资源前缀我习惯用类型标识比如纹理用tex_开头、音频用sfx_或bgm_开头、预制体用prefab_或ui_开头、材质用mat_开头。配合小驼峰命名文件名就不会乱成一锅粥。例如tex_player_sword_blade、sfx_ui_button_click、prefab_enemy_guard_01。这样配合搜索、筛选资源效率和准确性都会高不少。目录和命名规范不需要多花哨关键是统一执行。只要项目里有一个人乱建文件夹后面所有人都会跟着乱。团队里最好在项目初期就把这个规范写进文档里并在Code Review时顺手检查。1.3 资源分类方案按模块还是按更新频率整理资源时先要回答一个问题一个资源到底属于什么维度按功能模块分还是按类型分这是两种完全不同的思路。按类型分理解起来很直观就是纹理放一堆、模型放一堆。但对于一个角色资源来说模型、贴图、材质、动画、音效甚至技能特效都有关联拆开放在不同类型目录下就会造成管理困难。所以我更推荐按功能模块为主、类型为嵌套来组织。比如角色目录下面再拆分Models、Textures、Materials等二级目录Assets/Art/Characters/Knight/Models、Assets/Art/Characters/Knight/Textures。还有一个维度很容易被忽略按更新频率分类。这是做热更新方案时必须考虑的。启动必需资源、场景内高频资源、版本更新资源、活动临时资源它们的加载时机和存储位置完全不一样。启动必需资源应该留在本地包内高频场景资源可以做成常驻内存版本更新资源通过AssetBundle下载运营活动资源走后端动态下发。把这些资源按更新频率拆开后面搭建更新流程才会顺手。我的经验是多问自己一个问题这个资源如果做成可下载的下载失败时玩家还能不能正常玩答案决定它的存储与加载方案。规划阶段宁可多花两天把分类想清楚也不要在项目中期推倒重来。2. 资源加载方案怎么选2.1 References、Resources与AssetBundle到底怎么取舍很多初学者对加载方式的理解是想要某个资源用Resources.Load最方便或者干脆做成全局静态引用。这种思路在Demo里没问题但到了正式项目里就是灾难。先看三种常见方案的适用场景直接引用在Inspector面板把资源拖到脚本字段里。优点是非常直观、加载速度最快因为资源是随场景一起加载的缺点是会导致资源被场景持有如果场景之间共享大资源要么预先加载好要么就只能反复加载。适合UI图集、场景固定物件这类确定存在的资源。Resources.Load优点是代码里随手就可以取到资源适合配置表、初始化素材缺点是Resources目录下所有资源都会打进主包无法增量更新且运行时对资源索引、加载解析有额外的内存开销。适合数量极少的启动配置不适合游戏内容资源。AssetBundle与Addressables优点是支持独立打包、运行时下载、按需加载和卸载是目前游戏项目做更新、做内存控制的主流方案缺点是引入复杂度需要处理依赖、引用计数、下载失败等场景。适合正式运营项目里的核心内容资源。很多团队会有一个误区就是把Resources当成省事加载器后面又因为包体、内存问题被迫迁移到AssetBundle迁移成本高到让人崩溃。除非项目非常小且不做更新否则我建议从一开始就选择动态加载方案。2.2 Addressables实操从接入到首次加载Addressables是Unity官方推荐的资源管理方案底层封装了AssetBundle提供了按地址加载、自动管理依赖、引用计数、远程分组等能力。对大部分项目来说直接用Addressables会比手工拼AssetBundle省心得多。接入流程其实很清晰打开Package Manager安装Addressables包。打开Window Asset Management Addressables Groups创建分组把需要动态加载的资源拖进组里并设置Addressable名称。名称就是加载时的key。给资源设置加载类型Addressable表示动态加载Packed AssetBundle表示打进包里Local和Remote决定存放位置。代码加载时用Addressables.LoadAssetAsync (key)或直接给字段声明AssetReference在Inspector里拖资源。我用AssetReference的场景比较多它有一个天然的好处Prefab上关联的资源是强引用关系编辑器里能直观看到引用的资源对象构建时Addressables会自动把依赖资源打进对应Bundle不会出现手工管理依赖时漏打包的情况。举个例子一个加载角色预制体并实例化的逻辑可以这样写using UnityEngine; using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; using UnityEngine.ResourceManagement.ResourceProviders; public class SpawnManager : MonoBehaviour { public AssetReference playerPrefabRef; private GameObject currentInstance; public void SpawnPlayer() { if (currentInstance ! null) { playerPrefabRef.ReleaseInstance(currentInstance); } playerPrefabRef.InstantiateAsync().Completed handle { if (handle.Status AsyncOperationStatus.Succeeded) { currentInstance handle.Result; } }; } }这里最关键的是释放操作。加载一个资源并实例化后如果只调用Destroy而不调用Release资源仍驻留在内存中。Addressables用引用计数管理生命周期每加载一次计数加一实例化出的对象销毁时应当调用ReleaseInstance而不是直接Destroy否则计数永远不会归零最终内存泄漏。这一段我踩过不只一次每次排查漏资源最后定位都是这里。2.3 纹理、音频、模型导入设置的隐藏坑资源导入设置看起来属于美术那边的事但恰恰是资源管理中最容易爆内存和卡顿的环节。开发阶段用默认设置、用原图直接跑到了提测阶段才发现内存爆表再去优化已经晚了。纹理方面最重要的是贴图格式与Max Size。移动端常见压缩格式有ASTC和ETC2ASTC在带宽与画质上的综合表现更好Android与iOS主流设备都支持。iOS上可用ASTC 6x6起手Android设备兼容性稍好推荐ASTC 4x4作为底线必要时对UI贴图单独做不同压缩策略。Max Size要按实际使用尺寸来控制一张1024规格的UI图就不要让它以4096的尺寸存在。另外如果贴图用在UI上Generate Mip Maps通常是不需要的这个选项开着会白白多出三分之一的内存空间。音频的三种加载类型要分清Decompress on Load适合短小音效加载时会直接解码播放延迟低Compressed in Memory适合BGM解码播放减少内存Streaming适合长音频邊下邊播但必须注意流式播放对I/O的占用。很多音效卡顿、切换缓慢的问题根源就是全部音频都选了Decompress on Load启动时一次性解码几千个音频文件。模型的Read/Write Enabled选项默认可能是打开的但正式包必须关闭否则Mesh数据会同时留一份在CPU端和GPU端内存翻倍又毫无收益。顺便可以打开Mesh Compression来压缩顶点数据静态网格收益明显。动画文件与骨骼模型尽量用压缩动画格式。导入设置的规律总结起来就是先确认资源真正的使用上限再按上限去设置导入参数不要让Unity帮你做最保守、浪费内存的决定。3. 生命周期与内存管理实操3.1 引用计数与卸载机制的核心资源管理的核心不是加载而是释放。我观察过很多团队他们能花一整周搞定资源加载方案但是卸载策略基本没有设计过。结果资源越加载越多最后进程被系统杀掉玩家在微信后台看到的是闪退两个字。想要释放准确必须先理解Unity资源的内存归属。总体上看资源进入内存后有几类场景中的GameObject由场景管理资源对象Texture、Mesh、AudioClip则有对应的引用来源。如果你用Resources.Load或者AssetBundle加载资源实例化出的对象销毁不代表资源本身可以被回收必须调用对应的卸载接口。AssetBundle里最典型的坑是Unload(bool unloadAllLoadedObjects)。传true会把该Bundle下所有已加载的资源对象一并卸载看起来方便但如果有其他资源正引用了这里面的某个对象卸载后就会生成Missing引用材质变粉色、贴图变紫方格。传false只卸载Bundle的镜像不卸载资源给资源做后续释放或再次加载留出空间。常规做法是场景切换时对旧场景的Bundle统一调用Unload(true)但要先确保没有其他模块仍在引用它的对象。Addressables的引用计数规则我个人理解成一个简化版的共享引用模型。每次成功LoadAssetAsync会为资源计数加一Release时减一实例化的资源计数同样累加通过ReleaseInstance减一。只有计数归零后资源才会真正进入可卸载状态。若依赖加载失败或提前释放引用计数会变成不稳定的悬挂状态运行期报错很难排查。所以代码里尽量用一个统一封装去调加载、实例化和释放不要在业务代码里横七竖八地直接调Addressables。一个轻量的引用计数封装思路是public class AssetHandle { private Dictionarystring, int refCounts new Dictionarystring, int(); public void Retain(string key) { if (refCounts.ContainsKey(key)) { refCounts[key]; } else { refCounts[key] 1; } } public void Release(string key) { if (!refCounts.ContainsKey(key)) return; refCounts[key]--; if (refCounts[key] 0) { Addressables.Release(key); refCounts.Remove(key); } } }知道引用数归零并调用Release后再配合Resources.UnloadUnusedAssets去做Phase 2回收时机上会安全许多。UnloadUnusedAssets是一个会触发引擎GC的接口高频调用反而会增加卡顿我的建议是在场景切换或确认大批资源不再使用的时机去触发不要每一帧都执行。3.2 AssetBundle构建与依赖管理Addressables虽然封装了AssetBundle但很多项目出于定制化热更方案的需求还是选择手工构建AssetBundle。此时最核心的问题是依赖管理。我举个例子有包A包含一个材质材质引用了一张共享贴图而这张共享贴图同时被包B和包C使用。如果打包脚本没有显式处理依赖构建时这张贴图可能会被重复打进A、B、C三个Bundle里最终包体膨胀加载时还会产生多个相同资源的副本内存被白白多吃一块。构建AssetBundle前强烈建议先生成依赖清单并做依赖预分析。Unity的BuildAssetBundleOptions里有一个选项叫ForceRebuildAssetBundle还有DisableWriteTypeTree但最关键的其实是自带生成的Manifest文件。每次构建都会输出清单文件其中详细列出了每个Bundle依赖的其他Bundle。加载某个Bundle前应该先加载它的Manifest确认依赖链再按顺序加载依赖包否则大概率碰到资源丢失、依赖加载失败的问题。常规构建脚本可以这样写using UnityEditor; using System.IO; public class BuildBundles { [MenuItem(Tools/Build AssetBundles)] public static void BuildAllBundles() { string outputPath Path.Combine(Application.streamingAssetsPath, AssetBundles); if (!Directory.Exists(outputPath)) Directory.CreateDirectory(outputPath); BuildPipeline.BuildAssetBundles(outputPath, BuildAssetBundleOptions.ChunkBasedCompression, BuildTarget.Android); } }这只是基础模板实际使用中你还得根据模块创建多个构建Map把资源按分组规则映射到不同的Bundle。我强烈建议给Bundle分两个层级一级为逻辑模块比如UI、角色、场景、技能音效二级为资源变体比如不同材质质量的贴图。按逻辑模块打包解决的是加载粒度按更新频率打包解决的是热更包体积。如果一个包打了整整一个关卡的全部资源那每次改动哪怕一行文字整个包都得重新下载。依赖问题排查时最有效的工具是AssetBundle Browser图形化查看每个Bundle里包含的资源以及它的依赖列表。看到重复资源就回到打包分组脚本里维护一个全局依赖表确保共享资源单独打一个依赖包不要让业务包互相嵌套依赖。3.3 Profiler内存分析实战我排查内存问题最长的一次花了两个工作日最后发现根源是某段代码每帧加载了一张相同的贴图却又没有释放。这种问题如果依赖肉眼读代码效率太低一定要用Profiler去定位。打开Profiler后在Memory分类里重点关注Texture2D、Mesh、AudioClip、AnimationClip这几类资源。每类资源都有当前实例的Total Count和Total Size。当连续切场景或反复进入同一个玩法后如果Total Count在增长说明资源被重复加载且没有被释放。这个时候在Profiler里找到对应资源名双击可以跳到引用视图里看到它被哪个对象持有。有一个最简单也常被忽略的检查方法在编辑器里跑Game视图一段时间然后执行一次Resources.UnloadUnusedAssets再切到Profiler看资源数量变化。如果数量下降不明显说明有强引用在持有资源对象。此时要重点检查静态字段、单例对象、事件监听里是不是把资源对象缓存了下来。Audios和Shader同样值得关注。某些Shader会在运行时变体加载每切换一个档位就会多一份变体这也是内存累积的来源之一。如果发现Shader占用异常优先检查Always Included Shaders列表是不是把很少用到的Shader加进了全局列表。我写了一个简单的工具函数专门用来统计当前所有已加载资源并按大小排序在编辑器MenuItem里直接调用定位大资源非常方便using UnityEditor; using UnityEngine; using System.Collections.Generic; using System.Text; public class ResourceStatsWindow : EditorWindow { [MenuItem(Tools/Dump Loaded Resources)] public static void DumpLoadedResources() { var roots Resources.FindObjectsOfTypeAllUnityEngine.Object(); var dict new Dictionarystring, long(); foreach (var obj in roots) { if (obj is Texture2D t) { long size 0; try { size t.dimension TextureDimension.None ? 0 : (long)t.width * t.height * 4; } catch { } dict[obj.name] size; } } StringBuilder sb new StringBuilder(); foreach (var kv in dict) { sb.AppendLine(${kv.Key}: {kv.Value / 1024f:F1} KB); } Debug.Log(sb.ToString()); } }这个工具不算精致但足够帮你定位到现阶段项目中哪些贴图占用了异常高的内存。排查到具体资源后再回过去看它的加载时机、引用对象、打包分组基本都能把内存问题找到。4. 常见问题与排查技巧实录4.1 高频问题速查表把我在多个项目里遇到的资源管理问题汇总成了下面这个速查表项目里出了类似问题可以直接照着处理。现象可能原因解决思路场景切换后内存不降旧场景资源被静态引用或DontDestroyOnLoad持有用Profiler查强引用持有者清理静态缓存与事件监听贴图重复加载、数量持续增长同一资源被多个Bundle重复包含或反复Load统一走引用计数封装共享资源单独打包加载Bundle时报依赖缺失Bundle加载顺序不对或Manifest未读取加载前先读取依赖清单按顺序加载依赖包模型导入后颜色丢失或发紫材质引用的贴图或Shader未随模型打包检查Bundle依赖关系确认Shader与贴图在同包或依赖包中UI加载卡顿UI图集颗粒太细加载点数过多合并Sprite Atlas减少单个界面加载的贴图数量启动加载时间过长Resources目录资源过多或启动场景绑定了大量资源将Resources资源迁至Addressables或AssetBundle冷启动只加载核心内容热更包过大按模块维护的Bundle粒度太粗或没有做增量打包检查构建选项按更新频率拆包共享资源独立成公共包音频播放卡顿大量音频使用Decompress on LoadBGM改为Compressed in Memory或Streaming音效按需加载这张表只是给排查方向。每个问题在具体项目里的表现会略有不同但排查思路通常是先确认资源是否被正确加载再确认是否被正确释放最后看是否被正确打包。4.2 我的独家避坑清单这里写几条我后来一直坚持的规则每条都是实打实踩出来的坑。第一场景里的直接引用必须克制。如果一个Prefab在Inspector里直接挂了一个大贴图或大模型那么这个资源会跟随场景常驻内存哪怕场景里根本看不到它。做Prefab时尽量把它做轻只引用自己需要的最小资源。第二Resources目录越空越好。我见过有项目把全部配置表、所有UI图集、所有角色模型全放进Resources目录里最后包体直接从200MB涨到600MB启动时间从2秒涨到8秒。把Resources只留给启动必需的少量配置其余全部迁到动态加载路径。第三图集不是越大越好。图集过大加载的整张大图在内存中占用的空间会很大图集过小又会造成Draw Call上升。我的处理方式是UI界面按界面成图集公共元素单独成小图集避免为了节省内存把整个UI做成一张巨型贴图导致内存翻倍。第四Addressables的引用计数必须由统一封装管理。业务代码里直接调用加载与释放一定会在某个逻辑分支上漏掉Release。我自己封了一个资源加载服务之后资源泄漏这个Bug类别的出现频率大幅下降。第五正式包一定要关掉不必要的资源选项。Read/Write Enabled、Generate Mip Maps、多余的Shader变体、过高的Max Size每项看起来都只是多占一点内存叠加起来就能压垮低端机。第六做热更方案时别忘了老版本兼容。Bundle结构一旦发布出去后续修改Bundle分组名、依赖关系会导致老版本客户端加载失败所以热更目录和分组策略要预留扩展空间不要随意改包名。4.3 团队协作中的资源管理规范资源管理不只是个人技术问题更是团队协作问题。我见过几个项目因为团队之间没有统一的资源管理约定最后沦为互相甩锅美术说资源没问题程序说是加载写错了策划说资源在策划表里找不到。推荐在项目启动时建立一份简短的《资源管理规范文档》包含三块内容目录结构与命名规范、加载与释放规则的接口约定、资源导入参数的表单。表格形式可以这样组织资源类型UI贴图、角色模型、BGM、音效路径前缀UI_、Char_、BGM_、SFX_默认加载方式Addressables异步加载释放方式通过统一资源服务Release常用资源类型都可以在规范文档中给出一个示例配置例如纹理压缩默认ASTC 6x6角色模型Max Size为1024音效文件统一用16bit、44.1kHz的WAV。这些约定看似琐碎却能显著减少后期资源内存占用过高、Debug成本高这类问题。另外代码Review时建议把资源加载与释放是否成对出现作为必查项。团队中一旦出现复制一段加载代码但忘了释放的情况后面写出来的功能都会带病上线。资源管理这件事提前定规矩比事后再补救值得多。我在实际项目里还有个体会每当内存、包体出问题第一反应不是去写优化代码而是先检查是不是有谁的写法绕过了统一的资源服务、或者直接用了Resources.Load。绝大多数资源相关的疑难杂症最后都能归结到一个没有按既定规范做的不起眼改动上面。如果你也在维护一个快被资源问题拖垮的项目先把目录、命名、加载释放规则统一了再谈具体的优化手段效果会好得多。