1. 项目概述与问题根源在Unity项目开发中尤其是大型项目或需要热更新的移动端、WebGL项目AssetBundleAB包是管理资源、控制包体大小的核心工具。然而一个普遍存在且极易被忽视的性能陷阱就是场景资产的重复加载。想象一下你进入一个游戏关卡场景中的一棵树、一块石头可能因为被多个Prefab引用或者因为依赖关系管理不当在内存中被加载了两次、三次甚至更多次。这不仅白白浪费了宝贵的内存更会在加载时造成不必要的CPU开销和IO延迟直接导致场景切换卡顿、内存峰值飙升在移动设备上甚至可能引发闪退。这个问题之所以隐蔽是因为它通常不会直接导致逻辑错误。游戏能跑物体能显示但性能在不知不觉中被蚕食。其根源往往在于开发者对AssetBundle的依赖链、引用计数以及Unity资源管理机制的理解不够深入。当多个AB包都包含了同一份材质、贴图或模型或者一个AB包被多个地方异步请求加载时如果没有统一的缓存和管理机制重复加载就发生了。本次优化就是要彻底解决这个问题构建一个健壮的、无重复的AB包加载体系。2. 核心优化思路与方案设计要避免重复加载核心思路是“一次加载全局引用”。这听起来简单但在复杂的依赖关系和异步加载环境下实现起来需要一套严谨的架构。我们不能仅仅依赖开发者的自觉而是要通过系统设计来强制避免重复。2.1 总体架构设计一个有效的AB包管理框架需要包含以下几个核心组件AB包加载器 (AssetBundleLoader)负责实际的加载、卸载操作是直接与AssetBundle.LoadFromFile或UnityWebRequestAssetBundle打交道的模块。AB包缓存中心 (AssetBundleCache)这是避免重复加载的核心。它是一个全局的、静态的字典Dictionarystring, AssetBundle以AB包的名称或完整路径哈希为Key以已加载的AssetBundle对象为Value。任何加载请求都必须先经过这里。引用计数器 (Reference Counter)仅仅缓存还不够我们需要知道一个AB包当前被多少“客户”所使用。当引用计数为0时才应该将其从缓存中移除并卸载。这避免了某个模块用完就卸载导致其他模块资源丢失的问题。依赖关系解析器 (Dependency Resolver)利用AssetBundleManifest在加载目标AB包前递归地加载其所有依赖包。关键点在于依赖包的加载也必须走缓存中心确保依赖包本身也不会被重复加载。资源加载接口 (Asset Loader)提供从已加载的AB包中同步或异步加载具体资源如GameObject, Texture的接口并管理资源自身的实例化与回收。2.2 关键决策同步 vs 异步与缓存策略在实现上述架构时有几个关键决策点加载方式选择对于本地存储的AB包AssetBundle.LoadFromFile在非压缩或LZ4压缩格式下效率最高。对于需要从网络下载的包则必须使用UnityWebRequestAssetBundle。我们的框架需要同时支持这两种方式并根据传入的路径协议file://或http://自动选择。缓存粒度我们缓存的是AssetBundle对象本身而不是从AB包中加载出来的具体UnityEngine.Object资源。因为同一个AB包可能包含多个资源缓存AB包这一层能最大程度地复用。资源本身的实例化管理可以交给对象池或其他游戏模块。卸载策略采用AssetBundle.Unload(false)配合引用计数。当某个AB包的引用计数归零时我们调用Unload(false)只卸载AB包文件本身保留已经从该包中加载出来并正在使用的资源对象如场景中的模型。只有当这些资源对象也被销毁并通过Resources.UnloadUnusedAssets()或场景切换等方式真正不再被引用时Unity才会回收其内存。这种策略最安全避免了“材质变紫”的经典问题。注意永远不要在资源还被场景中的物体引用时调用AssetBundle.Unload(true)。这会导致资源被强制卸载引用它的物体会因为丢失材质、网格而显示为粉色或消失。Unload(true)仅在非常确定所有衍生资源都已不再需要且希望立刻释放内存时使用风险极高。3. 实现详解构建防重复加载管理系统下面我们将分步骤实现这个管理系统的核心代码。为了清晰起见这里会展示关键部分的伪代码和逻辑并解释每一步的意图。3.1 定义核心数据结构和缓存中心首先我们定义一个类来封装AB包的信息包括其对象、引用计数和依赖关系。using System.Collections.Generic; using UnityEngine; public class AssetBundleInfo { public AssetBundle Bundle { get; set; } public int RefCount { get; set; } // 引用计数 // 可以添加其他信息如路径、哈希值等 } public static class AssetBundleManager { // 核心缓存字典AB包名称 - AssetBundleInfo private static Dictionarystring, AssetBundleInfo _loadedBundles new Dictionarystring, AssetBundleInfo(); private static AssetBundleManifest _manifest null; private static AssetBundle _manifestBundle null; private static string _streamingAssetsPath; // 初始化加载Manifest文件 public static void Initialize(string manifestBundleName) { _streamingAssetsPath Application.streamingAssetsPath; // 加载包含Manifest的AB包通常与输出目录同名 string manifestPath Path.Combine(_streamingAssetsPath, manifestBundleName); if (!File.Exists(manifestPath) !File.Exists(manifestPath .manifest)) { Debug.LogError($Manifest bundle not found at {manifestPath}); return; } _manifestBundle AssetBundle.LoadFromFile(manifestPath); if (_manifestBundle null) { Debug.LogError($Failed to load manifest bundle from {manifestPath}); return; } _manifest _manifestBundle.LoadAssetAssetBundleManifest(AssetBundleManifest); _manifestBundle.Unload(false); // 卸载AB包但Manifest资源已加载到内存 Debug.Log(AssetBundleManager initialized with manifest.); } }3.2 实现带依赖加载和缓存的加载方法这是最核心的方法。它处理加载请求并确保依赖包先被加载且不被重复加载。public static AssetBundle LoadAssetBundle(string bundleName) { // 1. 检查缓存 if (_loadedBundles.TryGetValue(bundleName, out AssetBundleInfo bundleInfo)) { bundleInfo.RefCount; Debug.Log($Bundle {bundleName} already loaded. RefCount: {bundleInfo.RefCount}); return bundleInfo.Bundle; } // 2. 加载依赖包 (递归调用依赖包也会走缓存) if (_manifest ! null) { string[] dependencies _manifest.GetAllDependencies(bundleName); foreach (var dep in dependencies) { LoadAssetBundle(dep); // 递归加载依赖 } } // 3. 加载目标AB包 string path Path.Combine(_streamingAssetsPath, bundleName); AssetBundle newBundle AssetBundle.LoadFromFile(path); if (newBundle null) { Debug.LogError($Failed to load AssetBundle: {bundleName} from {path}); return null; } // 4. 存入缓存 bundleInfo new AssetBundleInfo { Bundle newBundle, RefCount 1 }; _loadedBundles.Add(bundleName, bundleInfo); Debug.Log($Bundle {bundleName} loaded successfully. RefCount: 1); return newBundle; }为什么递归加载依赖是安全的因为LoadAssetBundle方法的第一步就是检查缓存。如果依赖包A已经被主包B加载过了当包C也需要依赖A时走到第一步就会直接返回缓存的A并增加其引用计数。这完美避免了重复加载。3.3 实现引用计数与安全卸载有加载就必须有卸载。卸载逻辑需要与引用计数紧密绑定。public static void UnloadAssetBundle(string bundleName, bool unloadAllLoadedObjects false) { if (!_loadedBundles.TryGetValue(bundleName, out AssetBundleInfo bundleInfo)) { Debug.LogWarning($Trying to unload a bundle that is not in cache: {bundleName}); return; } bundleInfo.RefCount--; Debug.Log($Bundle {bundleName} ref count decreased to {bundleInfo.RefCount}); if (bundleInfo.RefCount 0) { // 引用计数为0从缓存中移除并卸载 _loadedBundles.Remove(bundleName); bundleInfo.Bundle.Unload(unloadAllLoadedObjects); // 通常传false Debug.Log($Bundle {bundleName} unloaded from memory.); // 注意这里我们不会递归卸载依赖包。 // 因为依赖包可能有其他使用者它们的引用计数由各自的管理逻辑控制。 // 例如包B和包C都依赖包A。当包B被卸载只减少包B对A的引用。 // 包A的卸载由它自己的引用计数为0时触发。 } }3.4 封装资源加载接口最后我们提供一个更上层的接口让业务代码无需直接接触AB包只需关心资源名。public class BundleAssetLoader : MonoBehaviour { public static T LoadAssetT(string bundleName, string assetName) where T : UnityEngine.Object { AssetBundle bundle AssetBundleManager.LoadAssetBundle(bundleName); if (bundle null) return null; T asset bundle.LoadAssetT(assetName); // 注意这里只加载资源不增加AB包的引用计数。 // 因为LoadAssetBundle内部已经增加了。 // 资源的生命周期管理实例化、销毁应由调用方负责。 return asset; } public static async TaskT LoadAssetAsyncT(string bundleName, string assetName) where T : UnityEngine.Object { AssetBundle bundle AssetBundleManager.LoadAssetBundle(bundleName); if (bundle null) return null; AssetBundleRequest request bundle.LoadAssetAsyncT(assetName); await request; // 使用C#的async/await或Unity的Coroutine等待 return (T)request.asset; } // 当一个场景或模块卸载时它应该调用此方法来释放其持有的AB包引用 public static void ReleaseBundle(string bundleName) { AssetBundleManager.UnloadAssetBundle(bundleName, false); } }4. 实战应用场景加载流程改造现在我们将这套管理系统应用到实际的场景加载流程中。假设我们有一个关卡场景level_1它被打包进了AB包scenes_level1这个场景依赖一个共用材质包materials_common和一个角色模型包characters_hero。旧的、有问题的加载流程可能是这样的加载场景时直接AssetBundle.LoadFromFileAsync(scenes_level1)。场景中的Prefab引用了materials_common包中的材质但代码没有显式加载这个依赖包依赖关系可能未被正确处理导致Unity隐式加载或加载失败。其他地方也可能直接加载characters_hero包造成重复。新的、优化后的加载流程public class SceneLoader : MonoBehaviour { public string sceneBundleName scenes_level1; public string sceneAssetName Level1; async void Start() { await LoadSceneBundle(); } private async Task LoadSceneBundle() { // 使用我们的管理器加载场景AB包。管理器内部会处理依赖。 AssetBundle sceneBundle AssetBundleManager.LoadAssetBundle(sceneBundleName); if (sceneBundle null) yield break; // 从AB包中异步加载场景 AssetBundleRequest request sceneBundle.LoadAssetAsyncScene(sceneAssetName); await request; Scene scene (Scene)request.asset; // 加载场景假设为附加模式 SceneManager.LoadScene(scene.name, LoadSceneMode.Additive); // 重要场景加载完成后我们是否立即卸载AB包 // 不能因为场景中的物体还在引用AB包中的资源。 // 我们只是在这里完成了一次“使用”但引用由场景持有。 // 通常在切换关卡时我们才卸载旧的场景包。 } // 切换关卡时调用 public void OnUnloadLevel() { // 释放本场景对AB包的引用 BundleAssetLoader.ReleaseBundle(sceneBundleName); // 卸载场景 SceneManager.UnloadSceneAsync(sceneAssetName); // 可以手动触发一次资源清理非必须Unity会在合适时机自动进行 // Resources.UnloadUnusedAssets(); } }关键点SceneLoader脚本在Start时增加了场景AB包的引用计数。在OnUnloadLevel中减少引用计数。如果这是该AB包的唯一使用者引用计数归零AB包将被安全卸载。依赖包materials_common的引用计数也会被其他使用者如其他场景或UI管理只有当所有使用者都释放后它才会被卸载。5. 常见问题、排查技巧与性能考量即使有了完善的管理系统在实际开发中还是会遇到各种问题。这里记录一些典型的“坑”和解决思路。5.1 问题排查清单问题现象可能原因排查步骤与解决方案资源加载后显示为粉色Missing Material1. 材质所在的AB包被过早Unload(true)。2. 材质依赖的贴图/Shader所在的AB包未加载或已卸载。3. AB包打包时资源的依赖关系未正确包含。1.检查卸载逻辑确保在资源被使用期间其所属的AB包引用计数0。使用Unload(false)。2.检查依赖链使用AssetBundleBrowser工具或代码检查目标资源的全部依赖确保所有依赖包都已正确加载并缓存。3.验证打包设置确保打包时勾选了合适的选项如BuildAssetBundleOptions.DeterministicAssetBundle。内存泄漏AB包或资源未被释放1. 引用计数逻辑错误只增不减。2. 静态对象或全局管理器持有了对资源或AB包的引用。3. 场景中的对象未正确销毁导致其引用的资源无法被回收。1.审计引用计数在Load和Release时打印日志确保成对出现。2.使用Profiler在Unity Profiler的Memory模块中查看AssetBundle和Other部分定位未被释放的AB包和资源对象。检查其引用链。3.清理场景确保在切换场景时旧场景的所有动态生成物体都被Destroy。加载时卡顿尤其是移动端1. 同步加载大量或大型AB包。2. 重复加载了相同的AB包本文解决的核心问题。3. 磁盘IO性能瓶颈大量小文件。1.异步化将所有LoadFromFile和LoadAsset调用改为异步版本LoadFromFileAsync,LoadAssetAsync。2.确认缓存生效在加载日志中确认“already loaded”信息出现。3.合并小包将大量小的、相关的资源打包到一个AB包中减少文件寻址开销。使用LZ4压缩以获得更快的加载速度。WebGL平台加载失败或异常1. 使用了AssetBundle.LoadFromFile在WebGL的StreamingAssets中不可用。2. 网络加载未处理错误和超时。3. 跨域问题CORS。1.统一使用UnityWebRequest为WebGL平台编写专用的加载路径强制使用UnityWebRequestAssetBundle。2.增加错误处理对UnityWebRequest的结果进行isNetworkError和isHttpError判断。3.配置服务器确保资源服务器正确配置了CORS头信息。5.2 进阶性能优化技巧AB包压缩格式选择LZMA压缩率最高但加载时必须整体解压内存和CPU开销大。适合作为初始下载包。LZ4/ChunkBasedCompression压缩率稍低但支持随机读取加载速度快内存占用可控。强烈推荐作为热更新和运行时加载的格式。不压缩加载速度最快但包体最大占用磁盘和下载流量多。适合极小型包或对速度极度敏感的场景。分包策略按功能模块分UI一个包角色一个包场景一个包。逻辑清晰但可能导致公共资源重复。按依赖关系分使用工具分析资源引用将频繁共同出现的资源打到一个“共享包”中。其他包依赖它。这能最大化复用减少重复是最佳实践。Unity的Addressable系统内部就是采用类似的策略。预加载与懒加载结合预加载在加载场景前或进入游戏主菜单时异步加载核心的、必需的AB包如共享材质、通用UI。懒加载对于场景内非关键资源如远处建筑的细节贴图等玩家接近时再动态加载。这能极大提升初始加载速度。监控与调试在开发阶段为你的AssetBundleManager添加详细的日志输出记录每个包的加载、引用、卸载事件。编写一个简单的编辑器窗口实时显示当前缓存中所有AB包的状态名称、引用计数、内存大小这对于调试内存问题至关重要。5.3 关于Unity Addressables的考量你可能会问既然Unity官方推出了Addressables系统为什么还要自己造轮子Addressables确实是一个更强大、更自动化的资源管理系统它底层也基于AssetBundle但封装了依赖管理、远程分发、内存管理等一系列复杂功能。自己实现管理系统的价值在于深度控制与理解你能完全掌控每一行代码深刻理解AB包从加载到卸载的整个生命周期这对于优化和排查复杂问题有不可替代的价值。轻量级对于中小项目一个自己实现的、几百行代码的管理器可能比引入完整的Addressables更简单、更可控。定制化你可以根据项目特殊需求定制缓存策略、加载优先级、错误恢复机制等。何时应该选择Addressables项目庞大资源繁多依赖关系复杂。需要频繁的热更新。团队规模较大需要一套标准化的、有官方支持的工具和 workflow。不想在资源管理上投入过多的开发和维护成本。无论选择哪条路理解本文所阐述的“避免重复加载”的核心原理都是至关重要的。这能帮助你在使用Addressables时也能理解其背后的行为并更好地配置和使用它。