异步资源加载

先把题目说成人话

玩家推开副本大门时，背景文件也许已经搬到内存，但把模型拆箱、登记、上传并点亮场景仍可能挤在同一帧，造成明显停顿。让可后台执行的资源工作不阻塞玩家等待，叫异步加载（Async Loading）。可靠切换还要列清物件依赖，把主线程收尾分开安排；关键资源失败时，玩家应继续留在安全的旧场景。

这是虚构教学故事，不是个人项目经历。

场景：先让问题变得看得见

玩家从城镇进入副本。门口的进度已经显示文件全部运到，画面却仍冻结了一下。时间记录表明，卡住的不是搬运文件，而是大量物件在同一帧被拆开、登记、放进房间、叫醒脚本并第一次显示出来。

这说明“已经搬到门口”和“房间可以住”是两个进度。还要先知道一件家具依赖哪些零件、哪些零件被多个房间共用，以及哪一步必须由主线程亲手完成。

（右脑）画面： 玩家正从旧房搬进新房。货车可以趁他还在旧房时把箱子送到新门口，可门一打开，屋里还要装床、拧螺丝、接电和点灯；若把所有箱子都留到开门那一刻才拆，玩家仍会站在门口等很久。更糟的是，关键的灯泡若在路上摔坏，新房一片漆黑，旧房却已经被拆空了。

（左脑）对表： 先根据稳定资源键解析直接依赖，再展开、去重为带版本与哈希的依赖闭包；每个共享资源由加载句柄和引用计数记录谁仍在使用。下载、文件读取和部分解压可以进入受并发与临时内存限制的后台队列；进入 Unity 对象后，再按真实平台能力区分反序列化、纹理或网格上传、实例化、脚本回调与场景激活。时间线（Timeline）逐段测主线程最长片段，容量以 MiB 记录，进度条则分开显示下载、加载、准备和激活。取消只释放本请求的持有关系，关键依赖失败时不得跨过激活门。

小明：先形成一个完整猜测

小明设计了一条直线流程：请求副本场景，等待所有依赖完成，然后在一帧里实例化并激活。他还把并发数拉高，希望越多任务一起跑，玩家等得越短。

这个模型考虑了异步读取，却遗漏了共享依赖、主线程收尾和内存峰值。并发过高会争抢 I/O、解压线程和临时内存；所有请求同一时刻完成，又会把主线程工作挤到同一帧。

小红：把猜测放回现实检查

小红先画出依赖闭包：场景引用 Prefab，Prefab 再引用材质、贴图、动画与 Shader。每个可加载单元都有稳定 key、版本/hash、依赖列表、状态和引用计数；同一依赖只加载一次，所有持有者释放后才允许卸载。她检查并拒绝循环依赖与版本不匹配，避免“加载成功但组合错误”。

接着她逐阶段看线程与生命周期：下载、文件读取和部分解压可异步执行；资源反序列化、GPU 上传、实例化、脚本回调与激活有平台和 Unity API 限制，其中许多工作仍会触碰主线程。她不再只看总耗时，而是看每帧主线程最长片段、并发队列和临时内存峰值。

我：用检查结果修正模型

我把系统改成可恢复的状态机：Resolve Dependencies → Download/Read → Load → Prepare → Activate → In Use → Release。根据玩家路径预取下一个区域；后台阶段设并发与内存上限；Prepare 只对应用能显式拆分的实例列表、满足 Unity 异步上传条件的纹理/Mesh，以及项目明确分批的预触发工作做预算治理。ShaderVariantCollection.WarmUp() 在 Unity 2022.3 的常规路径中是同步调用；实验性的 ShaderWarmup 只在支持的平台上可能异步预热部分管线状态，还依赖顶点布局与 Render Target 配置，必须按图形 API 实测，不能统称为通用 progressive warmup。不能切片的脚本回调、首用驱动工作和场景激活，则通过内容拆分、提前预触发与目标构建捕获降低尖峰，而不是承诺一个通用硬切片器。

失败处理也属于正常路径：可选装饰缺失时用占位资源，关键依赖失败时不激活新场景，保留旧场景并展示重试；版本或 hash 不一致时清理对应缓存后重新获取。取消请求只减少调用者的持有关系，不能在仍有其他使用者时销毁共享依赖。切换完成后按引用计数释放，并在受控时机卸载无引用资源，避免把卸载和 GC 又堆成下一次卡顿。

（右脑）画面修正： 小明看见最后一辆货车到站，就以为搬家已经完成，结果所有床架、灯具和柜子仍在同一刻涌进屋里组装，门口还是堵住了。小红把卸货、安装和通电沿时间摊开，让能分批做的工作慢慢完成；两间房共用的灯也等到最后一间不用时才搬走。若关键箱子损坏，玩家继续留在明亮的旧房，而不是被赶进一间只装了一半的新房。

（左脑）严格对表： 请求依次执行 Resolve→Download/Read→Load→Prepare→Activate→In Use→Release：解析阶段生成无环、版本一致的依赖闭包并去重；后台阶段受并发和临时内存上限约束；Prepare 仅给显式可拆的实例批次、符合异步上传条件的资源，以及经过目标 API 验证的分批预触发或异步 PSO 预热分配预算。Awake/OnEnable、驱动首用与其他不可切片工作不写入同一毫秒承诺，而是拆小内容单元、在安全时机预触发并从目标构建实测最长片段。全部关键句柄成功后才进入激活；取消只释放本请求引用，计数归零且无进行中使用才可卸载。验收覆盖主线程最长片段、峰值内存、共享去重、坏缓存/断网/取消，以及失败时旧场景仍可操作。

老师解惑

• 依赖管理的核心是“闭包 + 去重 + 版本 + 引用生命周期”，不是一张只列直接引用的清单。
• 异步能隐藏等待，不保证所有工作都离开主线程；最终必须用 Profiler 确认每个 Unity 版本和平台的实际行为。
• 进度条要区分下载、加载和激活。文件已经在内存里，不代表对象已经可用。
• 引用计数解决“何时可以释放”，内存预算和淘汰策略解决“现在是否应该释放”。

工具分工

• Addressables/AssetBundle 依赖信息：提供依赖解析、版本与加载句柄的基础能力。
• Unity Profiler Timeline：区分 I/O、反序列化、实例化、脚本回调、上传和激活尖峰。
• Memory Profiler：观察共享依赖是否重复、预取是否造成峰值以及释放后是否仍被引用。
• 故障注入测试：模拟断网、坏缓存、版本不一致、取消和低内存，验证回退路线确实能走通。

记忆钩子

后台负责运输，主线程按预算拆箱；依赖要去重计数，失败要能留在旧世界。