做过Unity项目的人基本都躲不过资源加载这件事。最早我做项目用的是Resources.Load后来项目体量稍微上来一点就开始切AssetBundle再后来被各种依赖、异步回调、重复加载折腾得够呛。这个Unity3D-有组合性的异步资源框架其实不是某个现成插件的名字而是我自己在项目里沉淀下来的一套资源加载思路把加载行为拆成独立模块再通过组合的方式拼出复杂业务需要的加载流程。这篇文章会把我的设计思路、核心代码、踩过的坑全部写出来希望对正在纠结资源加载到底怎么组织的人有帮助。1. 项目缘起同步加载和裸用AssetBundle到底痛在哪1.1 从一次线上卡顿说起我记得很清楚有一次项目刚上线玩家进入某个副本时明显卡顿低端机甚至直接白屏两三秒。查下来发现是副本入口一次性同步加载了20多个AssetBundle主线程全部卡在IO和反序列化上。那会儿我意识到同步加载不只在开发期慢它会造成帧率尖刺、加载白屏、内存瞬时飙升这些问题在真机上会被放大好几倍。异步加载解决的是不卡主线程的问题但光异步还不够。AssetBundle本身有依赖关系比如一个角色Prefab依赖一个共享ShaderShader又依赖贴图依赖项如果加载顺序不对或者漏加载了某个依赖出来就是粉红色模型或者干脆报错。原始的方式是把所有依赖手动写在一个配置表里然后一个个EnsureLoaded这种代码写到后面全是面条改一个资源路径要翻好几个文件。1.2 组合性到底在说什么我理解的组合性是加载逻辑可以拆成最小可用单元这些单元之间可以互相嵌套、拼接搭出任意复杂的加载链路。打个比方同步加载是你点一份全家桶后厨把所有东西一次性端上来而组合式异步框架是你分别下单汉堡、鸡翅、可乐再告诉店员打包到一起。每个下单动作都是一个独立的加载器而打包这个动作也是一个加载器它负责把多个子任务的完成状态汇总起来对外暴露一个统一的完成回调。这样做有几个好处第一每个加载器职责单一单独测试很容易第二上层业务可以根据需要自由组合想加载单个贴图就只调单个加载器想加载整个场景就组合十几个加载器第三组合方式可以复用不会出现每个界面各写一套加载逻辑的重复代码。所以这个框架名字里有组合性三个字不是形容词它是整个架构设计的核心约束所有模块必须能够像乐高积木一样拼接。2. 整体设计与模块划分资源框架的正确打开方式2.1 先回答一个问题为什么不用Addressables这是我在技术选型时最纠结的一环。Unity官方Addressables确实功能强大它内部封装了AssetBundle加载、依赖管理、远程构建、资源分组。但我最终没有直接用原因有三第一我们的项目本身已经有一套完善的热更新和打包管线AssetBundle的构建、版本控制、下载分发都是自研的Addressables如果再引入一套自己的规则等于把打包链路推倒重来迁移成本太高。第二Addressables对业务层暴露的API比较重很多操作需要走Addressables.LoadAssetAsyncT回调里拿到的AsyncOperationHandle还要处理释放、异常、依赖追踪。对策划和客户端同学来说学习成本不算低。第三组合性这个需求Addressables虽然支持但它的组合模型是基于ResourceLocation和依赖分组粒度比较粗。我自己想要的是可以自由控制每个加载器的行为比如断点重试、超时取消、限定并发数这是自研框架最容易做到的事。所以我当时定的方向是不排斥Addressables的封装思路但自己写一套轻量的、可组合的加载内核底层资源加载方式可以自由切换AssetBundle、Resources或者未来换成Addressables。我的框架只约束加载逻辑怎么组织不约束资源具体从哪来。2.2 框架的核心模块划分我把整个框架拆成了四层从下往上分别是资源层AssetProvider负责真正执行加载动作包括AssetBundle.LoadFromFileAsync、AssetBundle.LoadAssetAsync、Resources.LoadAsync等底层API封装。它不关心谁在调用、调用顺序如何只负责把一个路径映射成一个资源对象。加载器层AssetLoader这是整个框架的灵魂。每个加载器负责一个完整的资源加载任务它可以是一个单资源加载器也可以是组合加载器。加载器之间可以嵌套组合这是框架的核心能力。依赖管理层DependencyManager负责维护资源之间的依赖关系提供依赖查询、预加载、依赖打包等服务。AssetBundle的依赖信息在构建时就会被提取出来运行期间框架通过这个模块来决定加载A之前需不需要先加载B、C、D。缓存和生命周期层AssetCache ReferenceCount负责资源的引用计数、缓存生命周期、自动释放策略。缓存策略直接决定内存峰值引用计数决定资源什么时候可以安全卸载。这样的分层是经过几个版本迭代后形成的。最早我把依赖管理直接写在加载器里后来发现组合加载器之间会互相重复查询依赖逻辑越加越混乱。拆出来之后每个模块只关注一件事调试的时候开日志根据模块名过滤几秒钟就能定位问题。2.3 核心数据流一次完整加载请求长什么样我用一句话概括数据流业务层发起加载请求加载器把请求拆分成若干子任务子任务在依赖管理层的辅助下依次或并行执行资源层返回加载结果后回填到缓存最终组合加载器把结果汇总并通知业务层。文字描述有点抽象我实际操作中的流程是这样的假设业务层要加载一个关卡场景它调用的是SceneLoader.LoadAsync(sceneName)。这个组合加载器会先查一下依赖管理层得到这个场景依赖的AssetBundle列表然后并行创建若干BundleLoader。每个BundleLoader去检查自己的AssetBundle是否已经被加载并缓存没有则走资源层发起异步加载。所有BundleLoader完成后场景加载器再执行SceneManager.LoadSceneAsync场景里引用的Prefab资源会由框架内部的依赖追踪自动处理。最后组合加载器把场景句柄返回给业务层。可以看到组合加载器自己不直接碰底层资源加载它只负责编排和状态汇总。这就是组合性的体现编排逻辑和实际加载逻辑彻底分离。3. 核心实现细节与关键代码解析3.1 加载器的接口设计所有加载器都实现同一个接口这是组合性的基础。我定的接口非常精简核心就三个方法public interface IAssetLoader { LoadState State { get; } void Execute(); void Cancel(); event ActionIAssetLoader OnCompleted; }State标识加载状态Idle、Loading、Succeeded、Failed、Canceled。Execute触发加载Cancel允许取消。OnCompleted在加载结束时通知外部。接口设计得简单是因为组合加载器需要以统一的方式管理所有子加载器。如果每个加载器有各自不同的接口组合逻辑写起来就会到处if-else。这里有个细节值得一说OnCompleted事件是在加载结束时触发的但具体触发时机由加载器自己控制。对于单资源加载器底层异步操作完成就是完成对于组合加载器必须等全部子加载器完成才算完成。我最初设计时把事件放在基类里统一定时触发后来发现不行因为组合加载器和子加载器的完成时机不同事件分发必须由子类自行控制。3.2 单资源加载器的具体实现单资源加载器主要负责加载一个AssetBundle或一个Asset。以BundleLoader为例它内部封装了AssetBundle加载逻辑public class BundleLoader : IAssetLoader { private readonly string _bundleName; private AssetBundleCreateRequest _request; public LoadState State { get; private set; } public event ActionIAssetLoader OnCompleted; public BundleLoader(string bundleName) { _bundleName bundleName; } public void Execute() { State LoadState.Loading; _request AssetBundle.LoadFromFileAsync(_bundleName); _request.completed OnRequestCompleted; } private void OnRequestCompleted(AsyncOperation op) { if (string.IsNullOrEmpty(_request.assetBundle?.name)) { State LoadState.Failed; } else { State LoadState.Succeeded; } OnCompleted?.Invoke(this); } public void Cancel() { /* 实现取消逻辑 */ } }注意这里加载的是AssetBundle不是具体的资源对象。AssetBundle相当于一个容器容器加载成功后再通过bundle.LoadAssetAsync(assetName)加载具体资源。我把这两步拆成了两级加载器BundleLoader和AssetLoader。这样设计的好处是一个AssetBundle可以被多个具体资源共享加载一次即可不会因为加载了同一个Bundle里的两个不同Prefab导致Bundle被加载两次。3.3 组合加载器的三种基本形态组合加载器是框架组合性的直接体现。我实现了三种基本形态后续所有复杂加载都可以用这三种形态拼出来。第一种是顺序组合SequenceLoader子加载器按照顺序依次执行前一个完成后才启动下一个。适合加载链路中有先后依赖的场景比如先加载配置表再加载依赖的代码模块最后加载UI界面。第二种是并行组合ParallelLoader所有子加载器同时执行全部完成后才通知外部。适合加载彼此之间没有依赖的资源。并行加载能显著缩短加载时间但需要注意同时发起的异步加载请求数量太多会把磁盘IO打满反而变慢。我在项目里默认限制了并发数为6实测比全量并发速度更稳。第三种是条件选择组合SelectorLoader根据运行时条件选择某一个子加载器执行。比如根据平台选择不同的资源来源编辑器下从Resources加载真机上从AssetBundle加载。这种加载器看起来简单但对工程化帮助很大。组合加载器的核心代码大致如下拿ParallelLoader举例public class ParallelLoader : IAssetLoader { private readonly ListIAssetLoader _children; private int _remaining; public LoadState State { get; private set; } public event ActionIAssetLoader OnCompleted; public ParallelLoader(ListIAssetLoader children) { _children children; } public void Execute() { State LoadState.Loading; _remaining _children.Count; foreach (var child in _children) { child.OnCompleted OnChildCompleted; child.Execute(); } } private void OnChildCompleted(IAssetLoader child) { _remaining--; if (_remaining 0) { State LoadState.Succeeded; OnCompleted?.Invoke(this); } } }这个代码看起来简单但有一个细节容易被忽视_children列表必须在Execute之前固定下来不能在加载过程中动态增删。否则_remaining计数对不上永远等不到完成事件。我在实际开发中吃过这个亏后来规定组合加载器的子加载器列表一旦构造完成就是只读的。3.4 引用计数与缓存策略缓存和引用计数是框架里最容易踩坑的部分。我采用的方案是每种资源AssetBundle或Asset都有唯一的缓存条目条目内部维护引用计数。加载时引用计数加一释放时引用计数减一减到零时才真正卸载。这块我做了两个优化非常值得分享第一个优化是共享加锁。同一个资源可能同时被多个加载器请求加载比如两个UI界面同时依赖同一个角色头像。如果两个加载器各加载各的同一个资源就被重复加载两次浪费IO和内存。我的做法是缓存条目中记录当前加载状态如果资源正在加载中新的请求直接订阅这个正在进行中的加载任务等它完成时一起通知。这样同一个资源在任意时刻最多只有一个底层加载请求。第二个优化是分代缓存。对于频繁加载但不会长期持有的资源比如UI图标我设置了缓存容量上限和过期时间。当缓存条目数量超过上限按最近最少使用策略LRU清理最久没用的条目。这个策略对内存控制特别有效我见过很多项目的缓存无限增长最终在低端机上频繁触发GC甚至OOM。需要注意的是热更新资源的缓存策略和本地资源不一样。热更新来的Bundle文件每个版本都可能变化旧版本必须及时清理否则内存里堆积多个版本的同一资源不仅浪费还可能导致引用错乱。我的做法是Bundle缓存条目标记版本号版本不一致时强制卸载旧条目再加载新版本。3.5 加载状态的统一封装异步加载最烦人的地方是底层API返回的AsyncOperation种类很多AssetBundleCreateRequest、AssetBundleRequest、SceneManager.LoadSceneAsync、Resources.LoadAsync每种的处理方式都不太一样。如果每个加载器直接跟这些API打交道上层代码就不可避免地接触各种AsyncOperation子类耦合度很高。所以我加了一层统一的LoadHandle封装把所有异步操作抽象成两个状态IsDone和Progress加一个完成回调。代码大致是这样public class LoadHandle { public bool IsDone { get; private set; } public float Progress { get; private set; } public event Action OnComplete; public static LoadHandle FromAsyncOperation(AsyncOperation op) { var handle new LoadHandle(); op.completed _ { handle.IsDone true; handle.Progress 1f; handle.OnComplete?.Invoke(); }; return handle; } }有了这层封装上层加载器不需要关心底层具体是AssetBundle还是Resources统一通过LoadHandle获取进度和完成状态。这个抽象后来还被我用在了加载进度的实时展示上做一个统一的加载进度条界面就很简单了。4. 组合式API设计怎么像拼积木一样组织加载流程4.1 实战场景一加载一个战斗场景战斗场景是加载逻辑最复杂的地方之一。典型的需求是先确保资源包下载完整再加载公共BundleShader、图集、特效再加载场景内所有怪物Prefab最后打开加载进度界面。用组合加载器来组织流程是这样的var downloadLoader new DownloadLoader(battleConfig.Bundles); var commonBundleLoader new ParallelLoader( new BundleLoader(shared.shader), new BundleLoader(common.atlas), new BundleLoader(common.effects) ); var monsterBundleLoader new ParallelLoader( battleConfig.MonsterBundles.Select(b new BundleLoader(b)) ); var sceneLoader new SceneLoader(BattleScene_ battleConfig.LevelId); var composite new SequenceLoader( downloadLoader, commonBundleLoader, monsterBundleLoader, sceneLoader ); composite.OnCompleted _ OnBattleSceneReady(); composite.Execute();重点看这个SequenceLoader嵌套了两个ParallelLoader先并行加载公共Bundle再并行加载怪物Bundle然后加载场景。这个顺序是经过验证的——公共Bundle先加载可以避免怪物Prefab反序列化时找不到Shader或特效资源。而且这套逻辑不需要写任何先判断A是否加载完再决定加载B的if-else加载器之间的前后关系已经由嵌套方式固化了。4.2 实战场景二动态加载并合并多个UI面板另一个高频场景是UI框架中的界面动态加载。很多项目采用按需加载UI策略打开某个面板时才加载对应Prefab。如果面板之间有依赖关系比如角色详情面板依赖角色列表面板的数据你就需要保证先加载列表再加载详情。我用组合加载器实现了一个UIGroupLoader它的工作方式是接收一组UI面板路径支持按依赖顺序加载也可以并行加载最后统一返回所有面板的Prefab引用。public class UIGroupLoader : IAssetLoader { private readonly ListUIItem _uiItems; private readonly ParallelLoader _parallelLoader; public UIGroupLoader(ListUIItem uiItems) { _uiItems uiItems; _parallelLoader new ParallelLoader( _uiItems.Select(item new AssetLoader(item.PrefabPath)).ToList() ); } public void Execute() { State LoadState.Loading; _parallelLoader.OnCompleted OnChildrenCompleted; _parallelLoader.Execute(); } }实际项目里这个UIGroupLoader还做了一件事记录每个UI面板的资源路径和释放标记当界面关闭时自动释放对应的Asset。因为每个AssetLoader在加载完成后会把资源的引用计数加一UI关闭时再通过统一的AssetReleaser把计数归零从根本上防止UI资源泄漏。4.3 组合加载器如何接入热更新流程热更新资源和本地资源有一个本质区别本地资源在安装包内路径确定直接加载热更新资源需要先检查更新、下载、然后从沙盒目录加载。组合加载器可以很好地屏蔽这个差异。我的做法是定义一个UpdatableBundleLoader它内部包含两个子加载器CheckUpdateLoader和BundleLoader。CheckUpdateLoader先检查资源版本如果本地没有最新版则下载下载完成后BundleLoader再从正确的沙盒路径加载。整个流程对上层是透明的上层只关心最终能不能拿到Bundle资源不关心这个资源来自安装包还是沙盒。这个设计还有个好处如果某个资源根本不需要热更新直接用BundleLoader而不是UpdatableBundleLoader性能上没有任何额外开销。组合加载器的可替换性在这里体现得淋漓尽致。5. 常见问题与排查技巧实录5.1 组合加载器之间的状态传递我踩过最大的坑之一是组合加载器完成时发生了子加载器已经失败但组合加载器仍然标记为成功的情况。原因是我初始化_remaining时用的是子加载器数量但某个子加载器因为资源路径错误直接Compute了失败状态只更新了状态并没有走到完成事件的计数逻辑。后来我的解决方式是在子加载器状态变为Failed或Canceled时组合加载器也要感知这个状态一旦有子加载器失败组合加载器立即标记失败并且取消还在进行中的其他子加载器。这里也必须说明组合加载器不是简单全部完成就算成功而是在约定的状态下全部完成才算成功。我用一个状态聚合逻辑来统一处理private void OnChildCompleted(IAssetLoader child) { if (child.State LoadState.Failed || child.State LoadState.Canceled) { State child.State; _parallelLoader.Cancel(); OnCompleted?.Invoke(this); return; } _remaining--; if (_remaining 0) { State LoadState.Succeeded; OnCompleted?.Invoke(this); } }说实话这种细节如果不踩一次坑根本不会想到要处理。5.2 异步加载中“找不到资源”的诡异现象异步加载的诡异Bug往往不是完全找不到而是有时候找不到有时候找得到。现象是同一份资源某些设备上加载正常某些设备上报错。我排查下来最常见的原因是AssetBundle文件路径在不同平台上大小写敏感程度不同。PC开发环境大小写不敏感Android和iOS大小写敏感开发时写的路径全是小写真机上路径一旦有大小写不一致就找不到。我的做法是所有资源路径统一在构建期转换为小写框架内统一使用规范化的路径格式禁止直接用原始字符串。框架还加了一个路径校验开关Debug模式下加载前检查路径格式测试环境下可以快速发现路径问题。5.3 内存泄漏排查引用计数为什么永远降不到零资源框架的内存泄漏90%都是引用计数管理出了问题。最常见的情况是某个资源加载了但永远没有释放或者释放了又有其他地方强制把它加载回来计数被反复锁定。有一个非常隐蔽的Bug我用Dictionarystring, AssetCacheItem管理缓存key是资源路径。路径大小写规范化之后理论上同一个路径只对应一个缓存条目。但有一次某个业务模块在运行时动态拼接了带前后空格的路径空格没有trim导致同一个资源被当作两个不同key产生两个缓存条目。其中一个条目被引用一次不释放另一个条目也被引用一次不释放表现为两个小内存泄漏。我把所有加入缓存的路径都做了trim和toLower之后这个问题就消失了。另一个记忆深刻的坑是AssetBundle加载成功后我缓存了Bundle对象的引用但忘记缓存Bundle内部Asset对象的引用计数。业务层加载了一个Asset释放时只释放了Asset的部分而Bundle本身因为缓存条目存在永远不会卸载。我的解决方式是把Bundle和Asset的生命周期绑定到同一个缓存条目上Bundle引用计数为0时强制卸载Bundle同时销毁其内部所有Asset缓存条目。5.4 并发数限制与性能分析并发加载数限制非常关键。最初我没设限制所有资源同时发起异步请求结果在Android真机上出现明显的加载卡顿原因是底层文件IO线程数被打满多个请求互相竞争。后来我加了并发书签实测最稳的是并发数为6到8之间。帧率尖刺时间从2.5秒降到了1秒以内加载总时长只多了约200毫秒。性能分析方法也分享一下Unity Profiler里主要看三块——AsyncOperation的创建数量、AssetBundle.LoadFromFile的调用频次、以及GC Alloc。如果AsyncOperation创建量异常大多半是有资源被重复发起加载如果LoadFromFile调用频次高可能是依赖预加载没做好如果GC Alloc高很可能是加载器对象在加载链路上被反复创建导致。框架加个加载日志开关线上出问题时可以按模块过滤上下文。5.5 编辑器环境与真机环境的差异最后必须提醒一点Unity编辑器和真机在资源加载上的行为差异非常大。编辑器下Resources.Load和AssetBundle.Load的效率远高于真机很多异步问题在编辑器里根本复现不出来。我的做法是框架内保留两套Provider实现——编辑器下可以用同步加载临时跑通逻辑真机上强制走异步链路同时设置了编辑器下的模拟并发限制尽量模拟真机的IO性能。真机适配时最值得关注的是低端机的IO并发极限和内存峰值这两个点直接决定你框架参数的最终调优方向。6. 写在最后的个人体会这个组合式异步资源框架是我在多个项目里反复打磨出来的产物对我来说最有价值的不是代码量而是把加载逻辑拆成可组合的最小单元这个思维方式。它让资源加载从一件写的时候靠经验、跑起来看运气的事变成了一套可以预测、可以测试、可以随时替换底层实现的基础设施。如果你现在正在设计自己的资源加载框架我的建议是先别急着写代码花点时间想清楚组合的边界在哪里哪些行为应该内聚在一个加载器里哪些行为应该拆成独立加载器。组合太细会导致加载链路过长、调试困难组合太粗又会导致复用性差。我实践下来一个加载器最好只负责一种资源获取行为比如下载一个包加载一个Bundle加载一个Prefab加载一个场景。超过这个范围就考虑拆分。最后再分享一个小技巧一定要给框架加上详细的加载日志开关。这个开关在线上出问题时简直是救命稻草。我们当时加了一个日志级别控制打开Verbose级别后每个加载器的开始、结束、依赖查询、缓存命中、引用计数变化全部打点线上故障时按时间线回放基本能在十分钟内定位到是哪个业务代码漏释放了资源。很多资源框架的问题不是框架本身不够好而是出了问题之后你根本不知道问题在哪。可观测性做好的框架才敢在生产环境里放心用。
