1. 为什么值得花时间啃透AssetBundle如果你做Unity开发有一段时间了大概率经历过这样的场景项目初期资源随便扔在Resources目录里跑得挺欢等到包体膨胀到两三百兆加载越来越慢老板开始问“能不能热更”你才发现Resources目录根本扛不住这个需求。这时候绕不开的一个东西就是AssetBundle。AssetBundle是Unity官方提供的一套资源打包与动态加载机制。说人话就是你可以把贴图、模型、音频、预制体这些资源按照自己定的规则打成一个个“包裹”运行时从本地磁盘或者远端服务器把这些包裹拉下来再从中加载出具体资源。它能解决的核心问题有三个——减小初始包体、支持资源热更新、按需加载降低内存峰值。这套东西适合谁学我的判断是只要你的项目有热更需求或者包体超过150MB或者你在做多平台发布需要差异化资源管理AssetBundle就是必修课。新手向的教程网上很多但大部分只告诉你API怎么调不讲为什么这么设计、坑在哪里。这篇内容我会从方案选型、打包策略、加载管理、依赖处理、常见故障排查几个维度把我在实际项目里踩过的坑和总结的经验完整分享出来。注意AssetBundle这套机制在不同Unity版本之间有一些行为差异本文的经验主要基于Unity 2021 LTS和2022 LTS更早的版本部分API可能不同我会在涉及的地方标注出来。2. 整体方案设计与核心思路拆解2.1 为什么不用Resources而选AssetBundle很多刚接触Unity的朋友会问Resources目录用起来多方便直接Resources.Load就完事了为什么要折腾AssetBundle这个问题我在带新人的时候被问过不下十次。Resources目录的问题在于里面所有资源在打包时会被无条件打进安装包并且以Unity内部格式存储你没法控制压缩方式也没法在运行时替换。更致命的是Resources目录下的资源会在游戏启动时全部建立索引资源越多启动时的索引构建耗时越长。我实测过一个包含约800个贴图和300个预制体的Resources目录在移动端冷启动时仅索引构建就吃掉了将近1.2秒。AssetBundle则完全不同。它把资源的打包时机、打包粒度、压缩算法、存储位置全部交给你来决定。你可以把高频使用的UI图集打成一个包常驻内存把某个关卡独有的场景资源打成另一个包用完就卸载。这种精细控制能力是Resources给不了的。2.2 打包粒度怎么定一个没有标准答案的问题打包粒度是AssetBundle设计中最核心也最容易出错的决策。粒度太粗一个包几百兆更新时用户要重新下载全部内容粒度太细包数量爆炸依赖关系复杂到你自己都理不清而且每个包都有固定的头部开销和加载时的IO开销。我的经验法则是按“逻辑分组更新频率”两个维度来切按逻辑分组同一个UI界面的贴图、预制体、动画打在一起同一个角色的模型、材质、贴图打在一起。这样加载和卸载的边界很清晰。按更新频率经常改的资源和基本不动的资源分开打包。比如活动UI的图集可能每周都换但基础框架的通用贴图可能半年不动这两类必须分开。有个具体的数字可以参考单个AssetBundle包的大小控制在1MB到10MB之间比较合理。小于1MB的包头部开销占比太高大于10MB的包加载时的卡顿感会很明显尤其是在移动设备上。2.3 压缩方式的选择逻辑Unity提供了三种压缩方式我直接用一个表格来对比压缩方式包体大小加载速度内存占用适用场景LZMA最小最慢较低首次下载的包不常加载LZ4中等快较高高频加载的包不压缩最大最快高本地调试或极高频小包实际项目中的常见做法是首次发布用LZMA压缩减小下载体积下载到本地后通过AssetBundle.RecompressAssetBundleAsync转成LZ4格式缓存后续加载就走LZ4。这个流程在Unity 2019之后的版本支持得比较好。提示LZ4在移动端的解压速度优势非常明显。我做过对比测试同一个8MB的包LZMA加载耗时约180msLZ4约45ms差距接近4倍。3. 核心细节解析与实操要点3.1 AssetBundle的构建配置从零开始搭一套构建AssetBundle的第一步是配置资源的AssetBundle标签。在Unity编辑器中选中资源在Inspector面板底部可以设置AssetBundle的归属和变体。但手动一个个设置效率太低实际项目里都是用脚本批量处理。我通常会在项目里建一个AssetBundleConfig的ScriptableObject把打包规则数据化[CreateAssetMenu(fileName AssetBundleConfig, menuName AssetBundle/Build Config)] public class AssetBundleConfig : ScriptableObject { [System.Serializable] public class BundleRule { public string bundleName; public string searchPath; public string searchPattern; public bool recursive; } public BundleRule[] rules; public BuildTarget buildTarget; public bool useLZ4; }然后在构建脚本里遍历这些规则自动给匹配到的资源打标签public static void ApplyBundleLabels(AssetBundleConfig config) { foreach (var rule in config.rules) { var guids AssetDatabase.FindAssets(rule.searchPattern, new[] { rule.searchPath }); foreach (var guid in guids) { var path AssetDatabase.GUIDToAssetPath(guid); var importer AssetImporter.GetAtPath(path); if (importer ! null) { importer.assetBundleName rule.bundleName; importer.assetBundleVariant string.Empty; } } } AssetDatabase.Refresh(); }这样做的好处是打包规则可版本管理、可复用不会因为换了台机器就丢失配置。3.2 依赖关系处理最容易翻车的地方AssetBundle之间会存在依赖。比如包A里的预制体引用了包B里的贴图那么加载包A之前必须先加载包B否则预制体上的贴图会丢失显示成紫色。Unity在构建时会生成一个manifest文件记录所有依赖关系但运行时它不会自动帮你加载依赖。你需要自己维护这套逻辑。我的做法是在构建后解析manifest生成一张依赖关系表public class BundleManifest { private Dictionarystring, string[] _dependencies; public void LoadFrom(AssetBundleManifest manifest) { var allBundles manifest.GetAllAssetBundles(); _dependencies new Dictionarystring, string[](); foreach (var bundle in allBundles) { _dependencies[bundle] manifest.GetAllDependencies(bundle); } } public string[] GetDependencies(string bundleName) { return _dependencies.TryGetValue(bundleName, out var deps) ? deps : new string[0]; } }加载某个包时先递归加载它的所有依赖包再加载目标包。这里有个细节依赖包加载后不要立即卸载因为可能被多个包共享。我一般用一个引用计数来管理。3.3 加载方式的选择同步还是异步AssetBundle提供了同步和异步两套加载API。同步的LoadFromFile用起来简单但在加载大包时会阻塞主线程造成明显卡顿。异步的LoadFromFileAsync配合协程或async/await可以避免这个问题。我的建议是小于2MB的包可以用同步加载超过2MB一律走异步。在移动端这个阈值还要降低1MB以上就建议异步。public IEnumerator LoadBundleAsync(string path, ActionAssetBundle onComplete) { var request AssetBundle.LoadFromFileAsync(path); yield return request; if (request.assetBundle null) { Debug.LogError($Failed to load bundle: {path}); yield break; } onComplete?.Invoke(request.assetBundle); }注意异步加载完成的那一帧仍然会有一定的CPU开销用于对象初始化如果同时完成多个异步请求可能造成瞬时卡顿。可以通过分帧处理来缓解比如每帧最多处理2到3个加载完成回调。4. 完整实操流程与关键环节实现4.1 从零搭建一套可用的AssetBundle管理框架我把整个流程拆成构建、加载、卸载三个阶段每个阶段都有对应的管理类。构建阶段的核心任务是收集资源、打标签、执行构建、生成依赖表。构建脚本我一般放在Editor目录下[MenuItem(Tools/Build AssetBundles)] public static void BuildAll() { var config AssetDatabase.LoadAssetAtPathAssetBundleConfig( Assets/Configs/AssetBundleConfig.asset); ApplyBundleLabels(config); var outputPath Path.Combine(Application.streamingAssetsPath, Bundles); if (!Directory.Exists(outputPath)) Directory.CreateDirectory(outputPath); var options config.useLZ4 ? BuildAssetBundleOptions.ChunkBasedCompression : BuildAssetBundleOptions.None; BuildPipeline.BuildAssetBundles( outputPath, options, config.buildTarget); AssetDatabase.Refresh(); Debug.Log(Build complete.); }加载阶段需要一个运行时管理器负责缓存已加载的AssetBundle、处理依赖、提供资源加载接口public class AssetBundleManager : MonoBehaviour { private Dictionarystring, AssetBundle _loadedBundles new(); private Dictionarystring, int _refCounts new(); private BundleManifest _manifest; public Object LoadAsset(string bundleName, string assetName) { var bundle LoadBundleWithDeps(bundleName); return bundle?.LoadAsset(assetName); } private AssetBundle LoadBundleWithDeps(string bundleName) { if (_loadedBundles.TryGetValue(bundleName, out var cached)) { _refCounts[bundleName]; return cached; } foreach (var dep in _manifest.GetDependencies(bundleName)) { LoadBundleWithDeps(dep); } var path Path.Combine(BundleRootPath, bundleName); var bundle AssetBundle.LoadFromFile(path); if (bundle ! null) { _loadedBundles[bundleName] bundle; _refCounts[bundleName] 1; } return bundle; } }卸载阶段是最容易出问题的。AssetBundle.Unload(true)会卸载包本身以及从它加载出来的所有Asset对象如果这些Asset还在被引用就会变成missing状态。Unload(false)只卸载包本身已加载的Asset会保留在内存中但会切断与包的关联。我的策略是对于场景切换这种明确的批量卸载时机用Unload(true)对于单个资源的精细管理用Unload(false)配合Resources.UnloadUnusedAssets。4.2 一个完整的加载场景示例假设我们有一个UI界面它的预制体在ui_main包里依赖ui_atlas_common和font_common两个包。完整的加载流程是这样的public class UILoader : MonoBehaviour { private AssetBundleManager _bundleManager; private IEnumerator Start() { // 第一步加载依赖包 yield return _bundleManager.LoadBundleAsync(ui_atlas_common); yield return _bundleManager.LoadBundleAsync(font_common); // 第二步加载目标包 yield return _bundleManager.LoadBundleAsync(ui_main); // 第三步从包中加载预制体 var prefab _bundleManager.LoadAssetGameObject(ui_main, MainPanel); var instance Instantiate(prefab); // 第四步使用完毕后释放 // 注意这里不能立即卸载包因为实例还在使用中 // 应该在界面关闭时再执行卸载逻辑 } }这个流程看起来简单但每一步都有细节。比如第一步加载依赖包时如果依赖包已经被其他系统加载过了引用计数会递增不会重复加载。第三步加载预制体时如果预制体本身还引用了其他包里的资源那些包也必须已经加载完毕。4.3 构建后的验证与体积分析构建完成后我强烈建议做两件事一是检查manifest文件确认依赖关系正确二是分析每个包的实际体积和内容构成。Unity没有内置的包体积分析工具但你可以写一个简单的编辑器脚本来输出报告[MenuItem(Tools/Analyze Bundle Size)] public static void AnalyzeSize() { var bundlePath Path.Combine(Application.streamingAssetsPath, Bundles); var files Directory.GetFiles(bundlePath, *, SearchOption.TopDirectoryOnly); var report new StringBuilder(); long totalSize 0; foreach (var file in files) { if (file.EndsWith(.manifest)) continue; var info new FileInfo(file); totalSize info.Length; report.AppendLine(${info.Name}: {info.Length / 1024f:F1} KB); } report.AppendLine($Total: {totalSize / 1024f / 1024f:F2} MB); Debug.Log(report.ToString()); }这个报告能帮你快速发现异常大的包通常意味着打包粒度需要调整。5. 常见问题与排查技巧实录5.1 资源丢失变紫依赖没加载对这是AssetBundle最经典的问题。表现是预制体加载出来了但上面的贴图全是紫色或者材质变成了默认材质。根本原因就是依赖包没有在目标包之前加载。排查方法打开构建输出目录下的manifest文件找到目标包对应的条目看它的Dependencies列表里有哪些包确认这些包在加载目标包之前都已经加载完毕。我遇到过一个隐蔽的情况包A依赖包B包B依赖包C但构建时Unity只记录了A对B的直接依赖没有记录A对C的间接依赖。运行时如果只加载了A和B没有加载CB里的资源就会出问题。解决办法是在加载逻辑里做递归依赖解析把所有层级的依赖都加载上。5.2 内存泄漏卸载时机不对AssetBundle的内存管理是另一个重灾区。常见的内存泄漏场景包括加载了包但从未卸载、卸载了包但Asset还被引用导致无法释放、重复加载同一个包导致多份内存占用。我一般会在开发阶段加一个调试面板实时显示当前已加载的包数量和总内存占用public class BundleDebugPanel : MonoBehaviour { private void OnGUI() { var manager AssetBundleManager.Instance; GUILayout.Label($Loaded Bundles: {manager.LoadedCount}); GUILayout.Label($Total Memory: {manager.TotalMemoryMB:F1} MB); if (GUILayout.Button(Unload All)) { manager.UnloadAll(true); } } }这个面板在真机测试时特别有用能帮你快速定位是哪个环节没有正确释放。5.3 加载速度慢IO和压缩的双重影响移动端的IO性能远不如PC尤其是Android设备上不同机型的存储读写速度差异巨大。我实测过同一套AssetBundle在不同设备上的加载耗时低端机上可能是高端机的3到5倍。优化加载速度的几个方向使用LZ4压缩替代LZMA解压速度提升明显把高频加载的包放在StreamingAssets目录避免从压缩包中读取对包进行预加载在进入战斗或切换场景的loading界面时提前把包加载到内存减少单包内的资源数量避免一个包加载时触发大量对象的初始化5.4 常见问题速查表问题现象可能原因排查方向解决方案贴图变紫依赖包未加载检查manifest依赖列表递归加载所有依赖加载报错Null包路径错误或包未构建确认构建输出目录重新构建并检查路径内存持续增长包未卸载或引用未释放用调试面板监控检查卸载逻辑和引用计数加载卡顿明显同步加载大包检查包体积改用异步加载包体过大打包粒度太粗分析单包体积拆分细粒度热更后资源没变缓存未清理检查缓存目录清理旧缓存或加版本号提示热更新场景下一定要给AssetBundle加上版本号或哈希值作为文件名的一部分否则客户端可能加载到旧缓存。我见过因为缓存问题导致更新后玩家看到的还是旧资源的案例排查了大半天才发现是缓存没清。6. 进阶技巧与实战经验补充6.1 用引用计数管理包的生命周期引用计数是管理AssetBundle生命周期的核心手段。每加载一次包计数加一每释放一次计数减一计数归零时才真正卸载。这套机制听起来简单但实际写起来容易漏掉某些路径。我的做法是把引用计数的增减封装在管理器的加载和释放接口里业务层不需要手动操作计数public void ReleaseBundle(string bundleName) { if (!_refCounts.ContainsKey(bundleName)) return; _refCounts[bundleName]--; if (_refCounts[bundleName] 0) { if (_loadedBundles.TryGetValue(bundleName, out var bundle)) { bundle.Unload(false); _loadedBundles.Remove(bundleName); } _refCounts.Remove(bundleName); } }关键点是释放依赖包时也要递归释放但要注意共享依赖的情况。如果包A和包B都依赖包C释放A时不能直接把C也释放了因为B还在用。6.2 变体Variant的使用场景AssetBundle的变体机制允许你为同一份资源打不同版本的包比如高清版和标清版。运行时根据设备性能加载对应的变体。这个功能在需要适配多档次设备的项目中很有用。使用方式是在设置AssetBundle标签时指定变体名比如ui_main.hd和ui_main.sd。加载时通过AssetBundle.LoadFromFile的变体参数来指定加载哪个版本。不过变体机制在实际项目中使用率并不高因为大部分团队更倾向于用不同的构建配置来管理不同档次的资源而不是用变体。变体的维护成本较高容易在构建时产生意料之外的包。6.3 与Addressables的关系Unity后来推出了Addressables系统它在AssetBundle之上做了一层封装提供了更友好的API和自动化的依赖管理。很多新项目直接上Addressables不再手动管理AssetBundle。但我的观点是理解AssetBundle的底层机制仍然很重要。Addressables出问题时你最终还是得回到AssetBundle层面去排查。而且有些项目因为历史原因或特殊需求必须直接使用AssetBundle。所以先把AssetBundle搞明白再用Addressables会事半功倍。6.4 构建自动化与CI集成在团队协作中AssetBundle的构建最好集成到CI流程里避免每个人本地构建产生不一致的结果。我通常会在构建脚本里加上版本号和构建时间戳方便追溯var buildVersion DateTime.Now.ToString(yyyyMMdd_HHmm); var outputPath Path.Combine(Application.streamingAssetsPath, Bundles, buildVersion);同时在构建完成后自动生成一份构建报告记录每个包的大小、包含的资源列表、依赖关系提交到版本控制系统。这样当线上出现资源问题时可以快速定位是哪个版本、哪个包出了问题。我在实际项目里踩过最大的一个坑是构建AssetBundle时忘记把Shader加入Always Included Shaders列表导致在真机上所有使用自定义Shader的材质都渲染异常。这个问题在编辑器里完全看不出来只有打包到真机才会暴露。从那以后我在每次构建后都会在真机上跑一遍完整的资源加载测试确认所有Shader和关键资源都能正常加载。这个习惯帮我避免了好几次潜在的线上事故。 
长河君 · 2026/10/15 6:10:40 · 阅读 1.2k Unity AssetBundle实战：打包策略、依赖管理与热更新避坑指南
1. 为什么值得花时间啃透AssetBundle如果你做Unity开发有一段时间了大概率经历过这样的场景项目初期资源随便扔在Resources目录里跑得挺欢等到包体膨胀到两三百兆加载越来越慢老板开始问“能不能热更”你才发现Resources目录根本扛不住这个需求。这时候绕不开的一个东西就是AssetBundle。AssetBundle是Unity官方提供的一套资源打包与动态加载机制。说人话就是你可以把贴图、模型、音频、预制体这些资源按照自己定的规则打成一个个“包裹”运行时从本地磁盘或者远端服务器把这些包裹拉下来再从中加载出具体资源。它能解决的核心问题有三个——减小初始包体、支持资源热更新、按需加载降低内存峰值。这套东西适合谁学我的判断是只要你的项目有热更需求或者包体超过150MB或者你在做多平台发布需要差异化资源管理AssetBundle就是必修课。新手向的教程网上很多但大部分只告诉你API怎么调不讲为什么这么设计、坑在哪里。这篇内容我会从方案选型、打包策略、加载管理、依赖处理、常见故障排查几个维度把我在实际项目里踩过的坑和总结的经验完整分享出来。注意AssetBundle这套机制在不同Unity版本之间有一些行为差异本文的经验主要基于Unity 2021 LTS和2022 LTS更早的版本部分API可能不同我会在涉及的地方标注出来。2. 整体方案设计与核心思路拆解2.1 为什么不用Resources而选AssetBundle很多刚接触Unity的朋友会问Resources目录用起来多方便直接Resources.Load就完事了为什么要折腾AssetBundle这个问题我在带新人的时候被问过不下十次。Resources目录的问题在于里面所有资源在打包时会被无条件打进安装包并且以Unity内部格式存储你没法控制压缩方式也没法在运行时替换。更致命的是Resources目录下的资源会在游戏启动时全部建立索引资源越多启动时的索引构建耗时越长。我实测过一个包含约800个贴图和300个预制体的Resources目录在移动端冷启动时仅索引构建就吃掉了将近1.2秒。AssetBundle则完全不同。它把资源的打包时机、打包粒度、压缩算法、存储位置全部交给你来决定。你可以把高频使用的UI图集打成一个包常驻内存把某个关卡独有的场景资源打成另一个包用完就卸载。这种精细控制能力是Resources给不了的。2.2 打包粒度怎么定一个没有标准答案的问题打包粒度是AssetBundle设计中最核心也最容易出错的决策。粒度太粗一个包几百兆更新时用户要重新下载全部内容粒度太细包数量爆炸依赖关系复杂到你自己都理不清而且每个包都有固定的头部开销和加载时的IO开销。我的经验法则是按“逻辑分组更新频率”两个维度来切按逻辑分组同一个UI界面的贴图、预制体、动画打在一起同一个角色的模型、材质、贴图打在一起。这样加载和卸载的边界很清晰。按更新频率经常改的资源和基本不动的资源分开打包。比如活动UI的图集可能每周都换但基础框架的通用贴图可能半年不动这两类必须分开。有个具体的数字可以参考单个AssetBundle包的大小控制在1MB到10MB之间比较合理。小于1MB的包头部开销占比太高大于10MB的包加载时的卡顿感会很明显尤其是在移动设备上。2.3 压缩方式的选择逻辑Unity提供了三种压缩方式我直接用一个表格来对比压缩方式包体大小加载速度内存占用适用场景LZMA最小最慢较低首次下载的包不常加载LZ4中等快较高高频加载的包不压缩最大最快高本地调试或极高频小包实际项目中的常见做法是首次发布用LZMA压缩减小下载体积下载到本地后通过AssetBundle.RecompressAssetBundleAsync转成LZ4格式缓存后续加载就走LZ4。这个流程在Unity 2019之后的版本支持得比较好。提示LZ4在移动端的解压速度优势非常明显。我做过对比测试同一个8MB的包LZMA加载耗时约180msLZ4约45ms差距接近4倍。3. 核心细节解析与实操要点3.1 AssetBundle的构建配置从零开始搭一套构建AssetBundle的第一步是配置资源的AssetBundle标签。在Unity编辑器中选中资源在Inspector面板底部可以设置AssetBundle的归属和变体。但手动一个个设置效率太低实际项目里都是用脚本批量处理。我通常会在项目里建一个AssetBundleConfig的ScriptableObject把打包规则数据化[CreateAssetMenu(fileName AssetBundleConfig, menuName AssetBundle/Build Config)] public class AssetBundleConfig : ScriptableObject { [System.Serializable] public class BundleRule { public string bundleName; public string searchPath; public string searchPattern; public bool recursive; } public BundleRule[] rules; public BuildTarget buildTarget; public bool useLZ4; }然后在构建脚本里遍历这些规则自动给匹配到的资源打标签public static void ApplyBundleLabels(AssetBundleConfig config) { foreach (var rule in config.rules) { var guids AssetDatabase.FindAssets(rule.searchPattern, new[] { rule.searchPath }); foreach (var guid in guids) { var path AssetDatabase.GUIDToAssetPath(guid); var importer AssetImporter.GetAtPath(path); if (importer ! null) { importer.assetBundleName rule.bundleName; importer.assetBundleVariant string.Empty; } } } AssetDatabase.Refresh(); }这样做的好处是打包规则可版本管理、可复用不会因为换了台机器就丢失配置。3.2 依赖关系处理最容易翻车的地方AssetBundle之间会存在依赖。比如包A里的预制体引用了包B里的贴图那么加载包A之前必须先加载包B否则预制体上的贴图会丢失显示成紫色。Unity在构建时会生成一个manifest文件记录所有依赖关系但运行时它不会自动帮你加载依赖。你需要自己维护这套逻辑。我的做法是在构建后解析manifest生成一张依赖关系表public class BundleManifest { private Dictionarystring, string[] _dependencies; public void LoadFrom(AssetBundleManifest manifest) { var allBundles manifest.GetAllAssetBundles(); _dependencies new Dictionarystring, string[](); foreach (var bundle in allBundles) { _dependencies[bundle] manifest.GetAllDependencies(bundle); } } public string[] GetDependencies(string bundleName) { return _dependencies.TryGetValue(bundleName, out var deps) ? deps : new string[0]; } }加载某个包时先递归加载它的所有依赖包再加载目标包。这里有个细节依赖包加载后不要立即卸载因为可能被多个包共享。我一般用一个引用计数来管理。3.3 加载方式的选择同步还是异步AssetBundle提供了同步和异步两套加载API。同步的LoadFromFile用起来简单但在加载大包时会阻塞主线程造成明显卡顿。异步的LoadFromFileAsync配合协程或async/await可以避免这个问题。我的建议是小于2MB的包可以用同步加载超过2MB一律走异步。在移动端这个阈值还要降低1MB以上就建议异步。public IEnumerator LoadBundleAsync(string path, ActionAssetBundle onComplete) { var request AssetBundle.LoadFromFileAsync(path); yield return request; if (request.assetBundle null) { Debug.LogError($Failed to load bundle: {path}); yield break; } onComplete?.Invoke(request.assetBundle); }注意异步加载完成的那一帧仍然会有一定的CPU开销用于对象初始化如果同时完成多个异步请求可能造成瞬时卡顿。可以通过分帧处理来缓解比如每帧最多处理2到3个加载完成回调。4. 完整实操流程与关键环节实现4.1 从零搭建一套可用的AssetBundle管理框架我把整个流程拆成构建、加载、卸载三个阶段每个阶段都有对应的管理类。构建阶段的核心任务是收集资源、打标签、执行构建、生成依赖表。构建脚本我一般放在Editor目录下[MenuItem(Tools/Build AssetBundles)] public static void BuildAll() { var config AssetDatabase.LoadAssetAtPathAssetBundleConfig( Assets/Configs/AssetBundleConfig.asset); ApplyBundleLabels(config); var outputPath Path.Combine(Application.streamingAssetsPath, Bundles); if (!Directory.Exists(outputPath)) Directory.CreateDirectory(outputPath); var options config.useLZ4 ? BuildAssetBundleOptions.ChunkBasedCompression : BuildAssetBundleOptions.None; BuildPipeline.BuildAssetBundles( outputPath, options, config.buildTarget); AssetDatabase.Refresh(); Debug.Log(Build complete.); }加载阶段需要一个运行时管理器负责缓存已加载的AssetBundle、处理依赖、提供资源加载接口public class AssetBundleManager : MonoBehaviour { private Dictionarystring, AssetBundle _loadedBundles new(); private Dictionarystring, int _refCounts new(); private BundleManifest _manifest; public Object LoadAsset(string bundleName, string assetName) { var bundle LoadBundleWithDeps(bundleName); return bundle?.LoadAsset(assetName); } private AssetBundle LoadBundleWithDeps(string bundleName) { if (_loadedBundles.TryGetValue(bundleName, out var cached)) { _refCounts[bundleName]; return cached; } foreach (var dep in _manifest.GetDependencies(bundleName)) { LoadBundleWithDeps(dep); } var path Path.Combine(BundleRootPath, bundleName); var bundle AssetBundle.LoadFromFile(path); if (bundle ! null) { _loadedBundles[bundleName] bundle; _refCounts[bundleName] 1; } return bundle; } }卸载阶段是最容易出问题的。AssetBundle.Unload(true)会卸载包本身以及从它加载出来的所有Asset对象如果这些Asset还在被引用就会变成missing状态。Unload(false)只卸载包本身已加载的Asset会保留在内存中但会切断与包的关联。我的策略是对于场景切换这种明确的批量卸载时机用Unload(true)对于单个资源的精细管理用Unload(false)配合Resources.UnloadUnusedAssets。4.2 一个完整的加载场景示例假设我们有一个UI界面它的预制体在ui_main包里依赖ui_atlas_common和font_common两个包。完整的加载流程是这样的public class UILoader : MonoBehaviour { private AssetBundleManager _bundleManager; private IEnumerator Start() { // 第一步加载依赖包 yield return _bundleManager.LoadBundleAsync(ui_atlas_common); yield return _bundleManager.LoadBundleAsync(font_common); // 第二步加载目标包 yield return _bundleManager.LoadBundleAsync(ui_main); // 第三步从包中加载预制体 var prefab _bundleManager.LoadAssetGameObject(ui_main, MainPanel); var instance Instantiate(prefab); // 第四步使用完毕后释放 // 注意这里不能立即卸载包因为实例还在使用中 // 应该在界面关闭时再执行卸载逻辑 } }这个流程看起来简单但每一步都有细节。比如第一步加载依赖包时如果依赖包已经被其他系统加载过了引用计数会递增不会重复加载。第三步加载预制体时如果预制体本身还引用了其他包里的资源那些包也必须已经加载完毕。4.3 构建后的验证与体积分析构建完成后我强烈建议做两件事一是检查manifest文件确认依赖关系正确二是分析每个包的实际体积和内容构成。Unity没有内置的包体积分析工具但你可以写一个简单的编辑器脚本来输出报告[MenuItem(Tools/Analyze Bundle Size)] public static void AnalyzeSize() { var bundlePath Path.Combine(Application.streamingAssetsPath, Bundles); var files Directory.GetFiles(bundlePath, *, SearchOption.TopDirectoryOnly); var report new StringBuilder(); long totalSize 0; foreach (var file in files) { if (file.EndsWith(.manifest)) continue; var info new FileInfo(file); totalSize info.Length; report.AppendLine(${info.Name}: {info.Length / 1024f:F1} KB); } report.AppendLine($Total: {totalSize / 1024f / 1024f:F2} MB); Debug.Log(report.ToString()); }这个报告能帮你快速发现异常大的包通常意味着打包粒度需要调整。5. 常见问题与排查技巧实录5.1 资源丢失变紫依赖没加载对这是AssetBundle最经典的问题。表现是预制体加载出来了但上面的贴图全是紫色或者材质变成了默认材质。根本原因就是依赖包没有在目标包之前加载。排查方法打开构建输出目录下的manifest文件找到目标包对应的条目看它的Dependencies列表里有哪些包确认这些包在加载目标包之前都已经加载完毕。我遇到过一个隐蔽的情况包A依赖包B包B依赖包C但构建时Unity只记录了A对B的直接依赖没有记录A对C的间接依赖。运行时如果只加载了A和B没有加载CB里的资源就会出问题。解决办法是在加载逻辑里做递归依赖解析把所有层级的依赖都加载上。5.2 内存泄漏卸载时机不对AssetBundle的内存管理是另一个重灾区。常见的内存泄漏场景包括加载了包但从未卸载、卸载了包但Asset还被引用导致无法释放、重复加载同一个包导致多份内存占用。我一般会在开发阶段加一个调试面板实时显示当前已加载的包数量和总内存占用public class BundleDebugPanel : MonoBehaviour { private void OnGUI() { var manager AssetBundleManager.Instance; GUILayout.Label($Loaded Bundles: {manager.LoadedCount}); GUILayout.Label($Total Memory: {manager.TotalMemoryMB:F1} MB); if (GUILayout.Button(Unload All)) { manager.UnloadAll(true); } } }这个面板在真机测试时特别有用能帮你快速定位是哪个环节没有正确释放。5.3 加载速度慢IO和压缩的双重影响移动端的IO性能远不如PC尤其是Android设备上不同机型的存储读写速度差异巨大。我实测过同一套AssetBundle在不同设备上的加载耗时低端机上可能是高端机的3到5倍。优化加载速度的几个方向使用LZ4压缩替代LZMA解压速度提升明显把高频加载的包放在StreamingAssets目录避免从压缩包中读取对包进行预加载在进入战斗或切换场景的loading界面时提前把包加载到内存减少单包内的资源数量避免一个包加载时触发大量对象的初始化5.4 常见问题速查表问题现象可能原因排查方向解决方案贴图变紫依赖包未加载检查manifest依赖列表递归加载所有依赖加载报错Null包路径错误或包未构建确认构建输出目录重新构建并检查路径内存持续增长包未卸载或引用未释放用调试面板监控检查卸载逻辑和引用计数加载卡顿明显同步加载大包检查包体积改用异步加载包体过大打包粒度太粗分析单包体积拆分细粒度热更后资源没变缓存未清理检查缓存目录清理旧缓存或加版本号提示热更新场景下一定要给AssetBundle加上版本号或哈希值作为文件名的一部分否则客户端可能加载到旧缓存。我见过因为缓存问题导致更新后玩家看到的还是旧资源的案例排查了大半天才发现是缓存没清。6. 进阶技巧与实战经验补充6.1 用引用计数管理包的生命周期引用计数是管理AssetBundle生命周期的核心手段。每加载一次包计数加一每释放一次计数减一计数归零时才真正卸载。这套机制听起来简单但实际写起来容易漏掉某些路径。我的做法是把引用计数的增减封装在管理器的加载和释放接口里业务层不需要手动操作计数public void ReleaseBundle(string bundleName) { if (!_refCounts.ContainsKey(bundleName)) return; _refCounts[bundleName]--; if (_refCounts[bundleName] 0) { if (_loadedBundles.TryGetValue(bundleName, out var bundle)) { bundle.Unload(false); _loadedBundles.Remove(bundleName); } _refCounts.Remove(bundleName); } }关键点是释放依赖包时也要递归释放但要注意共享依赖的情况。如果包A和包B都依赖包C释放A时不能直接把C也释放了因为B还在用。6.2 变体Variant的使用场景AssetBundle的变体机制允许你为同一份资源打不同版本的包比如高清版和标清版。运行时根据设备性能加载对应的变体。这个功能在需要适配多档次设备的项目中很有用。使用方式是在设置AssetBundle标签时指定变体名比如ui_main.hd和ui_main.sd。加载时通过AssetBundle.LoadFromFile的变体参数来指定加载哪个版本。不过变体机制在实际项目中使用率并不高因为大部分团队更倾向于用不同的构建配置来管理不同档次的资源而不是用变体。变体的维护成本较高容易在构建时产生意料之外的包。6.3 与Addressables的关系Unity后来推出了Addressables系统它在AssetBundle之上做了一层封装提供了更友好的API和自动化的依赖管理。很多新项目直接上Addressables不再手动管理AssetBundle。但我的观点是理解AssetBundle的底层机制仍然很重要。Addressables出问题时你最终还是得回到AssetBundle层面去排查。而且有些项目因为历史原因或特殊需求必须直接使用AssetBundle。所以先把AssetBundle搞明白再用Addressables会事半功倍。6.4 构建自动化与CI集成在团队协作中AssetBundle的构建最好集成到CI流程里避免每个人本地构建产生不一致的结果。我通常会在构建脚本里加上版本号和构建时间戳方便追溯var buildVersion DateTime.Now.ToString(yyyyMMdd_HHmm); var outputPath Path.Combine(Application.streamingAssetsPath, Bundles, buildVersion);同时在构建完成后自动生成一份构建报告记录每个包的大小、包含的资源列表、依赖关系提交到版本控制系统。这样当线上出现资源问题时可以快速定位是哪个版本、哪个包出了问题。我在实际项目里踩过最大的一个坑是构建AssetBundle时忘记把Shader加入Always Included Shaders列表导致在真机上所有使用自定义Shader的材质都渲染异常。这个问题在编辑器里完全看不出来只有打包到真机才会暴露。从那以后我在每次构建后都会在真机上跑一遍完整的资源加载测试确认所有Shader和关键资源都能正常加载。这个习惯帮我避免了好几次潜在的线上事故。