1. 为什么打包成APK之后资源加载全乱套了如果你做过Unity移动端项目大概率经历过这个场景在编辑器里跑得好好的场景打包成APK装到安卓手机上要么贴图变成一片粉红要么模型直接消失要么音效播不出来。更让人抓狂的是有时候第一次装上去没问题第二次更新资源之后老用户手机上的界面就变成了“抽象画展”。这个问题的根源十有八九出在资源管理方式上。很多团队在项目初期为了图省事所有资源都塞进场景或者Resources文件夹里编辑器里一切正常因为编辑器会实时从工程目录读取资源。但一旦打包Unity会把Resources文件夹里的所有东西一股脑打进安装包包体动辄几百兆甚至上G而且每次改一个图标都得重新出整包。这时候AssetBundle就该登场了。AssetBundle是Unity提供的一套资源打包与动态加载机制。简单说它允许你把贴图、模型、预制体、音频、甚至整个场景按照你定义的规则打成一个个独立的压缩包放在服务器或者安装包的某个目录里。游戏运行时通过代码从这些包里按需加载资源。这样做的好处很直接包体可以拆得很小首包只带必要资源其余内容等玩家用到时再下载热更新变得可行改个UI贴图不用重新发版内存管理更精细不用的包可以主动卸载释放。但AssetBundle也是Unity里出了名的“坑王”。从打包策略、依赖关系、加载路径、内存释放到安卓平台特有的存储权限和压缩格式问题每一步都有细节能让你调试到凌晨三点。这篇文章就围绕“在安卓手机上跑通AssetBundle”这个目标把从零搭建到实际落地的完整链路拆开讲清楚。不管你是刚接触AssetBundle的新手还是被依赖关系绕晕的老手下面这些内容应该都能帮你省下不少查文档和试错的时间。2. 打包之前必须想清楚的资源分组逻辑2.1 按功能模块分还是按资源类型分AssetBundle打包的第一步不是写代码而是决定怎么分组。这个决定一旦做错后期改起来成本极高。我见过不少项目一开始按“贴图一个包、模型一个包、音效一个包”来分结果加载一个角色要同时请求五六个包IO次数暴增加载时间翻倍。也见过所有资源打成一个包的包体巨大不说改一个按钮图标要重新下载整个包。比较稳妥的分组思路是按功能模块划分同时兼顾资源类型。举个例子一个角色扮演类项目可以这样分分组名称包含内容加载时机ui_common通用按钮、字体、通用弹窗背景游戏启动时常驻ui_main主界面专属贴图与预制体进入主界面时加载role_hero_001某个英雄的模型、贴图、动画、技能特效选中该英雄时加载scene_battle_01战斗场景的地形、光照贴图、装饰物进入战斗时加载audio_bgm背景音乐按需加载audio_sfx音效按需加载这个分法的核心逻辑是把同时使用、同时废弃的资源放在一起。ui_common里的东西几乎全程都在用所以常驻内存没问题。role_hero_001只在特定英雄出场时用英雄换下去就可以整个包卸载。scene_battle_01打完这一局就可以释放。这样内存曲线是可控的不会出现越玩越卡的情况。2.2 依赖关系是绕不开的坎AssetBundle最让人头疼的就是依赖。假设你把一个角色的贴图放在role_hero_001包里但这个贴图同时被ui_main里的某个头像框引用了。如果你分别打这两个包Unity在打包时会自动把被共享的资源复制一份到两个包里造成冗余。更糟糕的是如果两个包引用了同一个材质而材质又引用了同一个Shader加载时可能会出现Shader丢失导致的粉红材质。正确的做法是把被多个包共享的资源单独抽出来打成一个共享包。比如所有UI共用的图集、所有角色共用的Shader、通用字体都放到一个叫shared_assets的包里。其他包在打包时Unity会自动记录对shared_assets的依赖。运行时必须先加载shared_assets再加载具体功能包否则会出现引用丢失。这里有个实操细节Unity在打包时会生成一个和AssetBundle同名的.manifest文件里面记录了该包的依赖关系。你可以用代码读取这个文件来获取依赖列表但更推荐的做法是在打包脚本里自己维护一份依赖配置表因为.manifest文件在运行时读取需要额外的IO而且格式是Unity私有的解析起来不够灵活。注意如果A包依赖B包加载A之前必须先加载B。但B包加载后不能立即卸载否则A包里的资源会变成“空引用”。这个顺序问题在热更新场景下尤其容易出错。2.3 粒度控制太粗和太细都难受包分得太粗比如所有UI打成一个包那改一个界面就要重新下载整个UI包热更新流量浪费严重。包分得太细比如每个预制体一个包那加载一个界面可能要请求几十个包安卓手机上的文件IO本来就慢加载时间会变得不可接受。我的经验是单个AssetBundle的未压缩大小控制在1MB到5MB之间。小于1MB的包考虑合并到相邻功能模块大于5MB的包考虑按使用频率或场景进一步拆分。当然这不是硬性标准具体要看项目类型。休闲游戏可能整个游戏才几十兆那包可以分得粗一些大型MMO可能一个场景就上百兆那必须拆得很细。还有一个容易被忽略的点AssetBundle的数量本身也有开销。每个包在加载时都会产生一个AssetBundle对象这个对象本身占用内存而且Unity内部对同时打开的AssetBundle数量是有限制的。虽然这个限制比较高但在低端安卓机上同时打开几十个包确实会导致明显的卡顿。所以分组时也要考虑运行时同时活跃的包数量尽量控制在10个以内。3. 打包脚本怎么写才不给自己挖坑3.1 标记资源AssetBundle名称的命名规范在Unity编辑器里选中一个资源在Inspector面板最下方可以设置它的AssetBundle名称和变体Variant。名称格式通常是“包名.扩展名”比如“role_hero_001.unity3d”。扩展名可以随便写但建议统一方便后续识别。手动一个个标记资源是不现实的项目里几千个资源标到猴年马月。通常的做法是写一个编辑器脚本根据资源所在目录自动设置AssetBundle名称。比如所有放在Assets/UI/Main目录下的资源自动标记为“ui_main”。这样美术和策划只需要按规范放资源打包时自动分组。这里有个坑目录结构变化后AssetBundle名称不会自动更新。比如你把一个资源从UI/Main移到了UI/Common但之前标记的AssetBundle名称还是ui_main打包时它还是会进ui_main包。所以每次打包前最好先清除所有资源的AssetBundle标记再重新按目录规则标记一遍。清除的代码很简单string[] allAssets AssetDatabase.GetAllAssetPaths(); foreach (string asset in allAssets) { AssetImporter importer AssetImporter.GetAtPath(asset); if (importer ! null) { importer.assetBundleName string.Empty; importer.assetBundleVariant string.Empty; } }这段代码会遍历工程里所有资源把AssetBundle名称清空。执行完之后再根据目录规则重新赋值确保标记和实际目录结构一致。3.2 打包参数BuildAssetBundleOptions怎么选Unity的BuildPipeline.BuildAssetBundles方法有一个BuildAssetBundleOptions参数用来控制打包行为。常用的选项有这几个None默认不做任何特殊处理。UncompressedAssetBundle不压缩。包体大但加载快因为省去了解压步骤。ChunkBasedCompression使用LZ4压缩。这是我最推荐的选项。LZ4的压缩率不如LZMA但解压速度极快而且支持随机读取不需要把整个包解压到内存里。对于移动端来说这个平衡点非常合适。DisableWriteTypeTree不写入类型树信息。可以减小包体但会降低版本兼容性。如果Unity版本升级后资源格式有变化可能会加载失败。一般不建议开启除非你对版本控制非常有信心。DeterministicAssetBundle让每次打包生成的AssetBundle的哈希值保持一致。这个选项对热更新差分对比很有用建议开启。综合下来移动端项目的推荐配置是BuildAssetBundleOptions options BuildAssetBundleOptions.ChunkBasedCompression | BuildAssetBundleOptions.DeterministicAssetBundle;ChunkBasedCompression在安卓上的表现尤其好因为安卓的存储IO性能参差不齐LZ4的快速解压能明显减少加载等待时间。而DeterministicAssetBundle能让相同内容的包生成相同的哈希方便做增量更新。3.3 平台差异安卓和编辑器下的包不能混用这是新手最容易踩的坑之一在编辑器里打好的AssetBundle直接拷到安卓手机上用结果加载报错。原因是AssetBundle是平台相关的编辑器Windows/Mac下打的包和安卓、iOS下打的包内部格式不同不能混用。所以打包脚本里必须根据当前目标平台设置BuildTargetBuildTarget target BuildTarget.Android; if (EditorUserBuildSettings.activeBuildTarget BuildTarget.iOS) { target BuildTarget.iOS; } BuildPipeline.BuildAssetBundles(outputPath, bundles, options, target);输出目录也建议按平台分开比如“AssetBundles/Android”和“AssetBundles/iOS”避免混淆。另外安卓平台还有一个特殊之处StreamingAssets目录下的文件在APK里是压缩的不能直接用File.ReadAllBytes读取。如果要把AssetBundle随包发布需要放在StreamingAssets里然后用UnityWebRequest来读取它会自动处理APK内的解压。3.4 打包后的文件清单与版本管理每次打包完成后除了AssetBundle文件本身还会生成一个总的manifest文件和输出目录同名。这个文件记录了所有包的列表、依赖关系和哈希值。做热更新时通常需要把这个manifest文件也上传到服务器客户端下载后对比本地版本决定哪些包需要更新。我习惯在打包脚本最后加一步生成一个自定义的版本清单文件格式用JSON包含每个包的名称、哈希、大小、依赖列表。这样客户端解析起来比Unity原生的manifest方便得多。示例结构{ version: 1.0.3, bundles: [ { name: ui_common, hash: a1b2c3d4, size: 102400, deps: [shared_assets] }, { name: role_hero_001, hash: e5f6g7h8, size: 204800, deps: [shared_assets] } ] }这个文件在客户端启动时下载和本地缓存的版本对比有差异的包才去下载。这样能把热更新的流量降到最低。4. 安卓手机上的加载路径与存储策略4.1 只读的StreamingAssets和可写的PersistentDataPath安卓系统对应用的文件访问有严格限制。APK安装后里面的文件是只读的不能修改。而应用有一个专属的可写目录在Unity里通过Application.persistentDataPath获取路径类似“/storage/emulated/0/Android/data/包名/files”。这个目录下的文件可以自由读写而且应用卸载时会被清除。AssetBundle的存放策略通常是这样的首包自带的资源放在StreamingAssets里热更新的资源下载到PersistentDataPath里。运行时先检查PersistentDataPath里有没有对应的包有就用本地的没有就从StreamingAssets里读或者从服务器下载。这里有个细节StreamingAssets里的文件在安卓上不能直接用File类读取必须用UnityWebRequest。而PersistentDataPath里的文件可以用File.ReadAllBytes直接读。所以加载代码里需要根据路径来源选择不同的读取方式。我一般会封装一个统一的加载接口内部判断路径前缀自动选择读取方式。4.2 加载方式同步还是异步AssetBundle的加载API有两套同步的AssetBundle.LoadFromFile和异步的AssetBundle.LoadFromFileAsync。在移动端强烈建议全部使用异步加载。原因很简单同步加载会阻塞主线程安卓手机上一次IO操作可能耗时几十毫秒甚至上百毫秒如果同时加载多个包卡顿感会非常明显。异步加载虽然代码写起来麻烦一点需要处理回调或协程但能保证游戏帧率稳定。用协程写异步加载的典型结构IEnumerator LoadBundleAsync(string path) { AssetBundleCreateRequest request AssetBundle.LoadFromFileAsync(path); yield return request; AssetBundle bundle request.assetBundle; if (bundle null) { Debug.LogError(加载失败: path); yield break; } // 加载包内资源 AssetBundleRequest assetRequest bundle.LoadAssetAsyncGameObject(MyPrefab); yield return assetRequest; GameObject prefab assetRequest.asset as GameObject; Instantiate(prefab); }如果是UnityWebRequest方式用于StreamingAssets或远程下载结构类似只是把AssetBundle.LoadFromFileAsync换成UnityWebRequestAssetBundle.GetAssetBundle。4.3 依赖包的加载顺序不能乱前面提到过有依赖关系的包必须先加载被依赖的包。但实际项目中依赖关系可能有多层A依赖BB依赖C。手动管理加载顺序很容易出错。我的做法是写一个依赖解析器在加载某个包之前先递归加载它所有的依赖包确保依赖树上的每个包都已经在内存里。具体实现时可以用一个字典记录已经加载的包避免重复加载。加载依赖时如果发现某个依赖包已经在字典里就跳过。伪代码逻辑void LoadBundleWithDeps(string bundleName) { if (loadedBundles.ContainsKey(bundleName)) return; string[] deps GetDependencies(bundleName); foreach (string dep in deps) { LoadBundleWithDeps(dep); } AssetBundle bundle LoadBundleFromDisk(bundleName); loadedBundles.Add(bundleName, bundle); }这个递归逻辑看起来简单但实际写的时候要注意循环依赖的问题。虽然Unity在打包时会检测并阻止循环依赖但自己维护的依赖配置表如果写错了还是可能出现死循环。加一个正在加载中的标记集合可以避免这个问题。4.4 卸载时机什么时候可以安全释放AssetBundle的卸载有两个APIAssetBundle.Unload(false)和AssetBundle.Unload(true)。参数为false时只释放AssetBundle对象本身从包里加载出来的资源比如GameObject、Texture不会被销毁。参数为true时连加载出来的资源也一并销毁。选哪个取决于你的资源管理策略。如果资源已经被其他系统引用比如场景里已经实例化的物体用Unload(true)会导致这些物体变成粉红或消失。所以大多数情况下用Unload(false)然后自己管理资源的生命周期。当确定某个资源不再被任何地方引用时再手动Destroy它最后调用Resources.UnloadUnusedAssets()清理。但这里有个陷阱如果资源还被引用Resources.UnloadUnusedAssets()不会释放它。所以你需要一套引用计数机制记录每个资源被多少地方使用。当计数归零时才真正销毁。这套机制实现起来不复杂但需要在所有加载和释放资源的地方都严格遵守否则就会出现内存泄漏或者提前释放的问题。提示在安卓低内存设备上AssetBundle卸载不及时是导致闪退的主要原因之一。建议在场景切换、大界面关闭等关键节点主动触发一次资源清理。5. 真机调试中那些让人抓狂的报错5.1 “The AssetBundle can not be loaded because it was created with a newer version of Unity”这个报错的意思是AssetBundle是用更新版本的Unity打的当前运行的Unity版本不支持。解决办法很简单确保打包和运行使用的是同一个Unity版本。但实际项目中有时候团队里不同人用的Unity版本不一致或者打包机上的版本和开发机不同就会出这个问题。建议在项目里锁定Unity版本用版本管理工具统一管理。5.2 加载成功但资源显示异常有时候包加载成功了没有报错但实例化出来的物体贴图丢失、材质变粉。这种情况通常是Shader丢失导致的。AssetBundle里如果引用了自定义Shader而这个Shader没有被打进任何包或者打包时被剥离了运行时就会找不到。解决办法是把所有用到的Shader显式加入Always Included Shaders列表或者单独打一个Shader包确保它先于其他包加载。另一个可能的原因是依赖包没有加载。比如A包里的预制体引用了B包里的材质但加载A之前没有加载BUnity在实例化时会找不到材质显示为默认的粉红材质。这种问题不会报错但表现很明显。排查方法是检查加载日志确认所有依赖包都已经在内存里。5.3 安卓上的文件路径大小写问题Windows系统对文件路径大小写不敏感但安卓是基于Linux的大小写敏感。如果你在代码里写的路径是“UI_Common”而实际文件名是“ui_common”在编辑器里能正常加载到了安卓上就报“文件不存在”。这个坑非常隐蔽因为编辑器里测试一切正常。解决办法是统一命名规范所有AssetBundle名称和路径全部用小写字母加下划线避免大小写混用。5.4 内存泄漏包越加载越多AssetBundle如果只加载不卸载内存会持续增长最终导致闪退。常见的原因有加载了包但忘记在合适的时候调用Unload或者调用了Unload(false)但资源还被引用导致包对象释放了但资源内存没释放或者重复加载同一个包每次都创建新的AssetBundle对象旧的对象没有被释放。排查内存泄漏可以用Unity Profiler在安卓真机上连接Profiler观察AssetBundle对象数量和Texture内存的变化。如果发现AssetBundle数量只增不减那肯定是卸载逻辑有问题。建议在代码里加一个调试面板实时显示当前加载的包列表和内存占用方便定位问题。6. 从首包到热更新一套可落地的资源更新流程6.1 首包资源的最小化策略首包的大小直接影响用户的下载意愿。安卓应用商店对APK大小虽然没有硬性限制但超过100MB之后下载转化率会明显下降。所以首包里只放启动必须的资源登录界面、基础UI、加载动画、必要的Shader和字体。其他所有资源都通过热更新在首次启动后下载。具体操作上可以把首包资源单独打一个包放在StreamingAssets里。游戏启动时先加载这个首包显示加载界面同时后台去服务器请求版本清单对比差异下载缺失的包。下载完成后后续所有资源都从PersistentDataPath加载。6.2 版本对比与增量下载版本对比的核心是前面提到的JSON清单文件。客户端启动时先读取本地缓存的清单如果没有就用首包里的清单然后从服务器下载最新的清单逐个对比每个包的哈希值。哈希不同的包需要更新哈希相同的包直接复用本地缓存。增量下载时可以同时下载多个包但要注意控制并发数。安卓手机的网络IO和磁盘IO都有瓶颈同时下载太多包反而会拖慢整体速度。我的经验是并发数控制在3到5个比较合适。下载完成后校验文件的哈希值确保没有损坏然后写入PersistentDataPath。6.3 断点续传与失败重试移动网络不稳定下载中断是常有的事。如果每次中断都从头开始下载用户体验会很差。所以下载逻辑里必须支持断点续传。实现方式是利用HTTP的Range头记录已下载的字节数下次请求时从断点位置继续。失败重试也要做好。网络请求失败后不要立即弹窗报错而是自动重试2到3次每次间隔递增比如1秒、3秒、5秒。如果重试仍然失败再提示用户检查网络。重试逻辑要区分错误类型如果是404文件不存在重试没有意义直接报错如果是超时或连接中断才值得重试。6.4 更新完成后的资源切换所有包下载完成后需要把资源加载路径从StreamingAssets切换到PersistentDataPath。这个切换通常发生在重启游戏或者重新进入某个场景时。切换时要确保旧的AssetBundle已经全部卸载避免新旧资源混用导致的问题。一个稳妥的做法是下载完成后提示用户“更新完成需要重启游戏生效”然后调用Application.Quit()用户重新打开后自然就从新资源加载了。虽然体验上多了一次重启但能避免很多资源状态不一致的诡异问题。如果不想重启那就需要在代码里严格管理资源切换的时机确保所有旧资源都被释放新资源按正确的依赖顺序加载。7. 几个让我少熬几个通宵的实操心得AssetBundle这套东西文档看再多不如自己踩一遍坑来得深刻。下面这几条是我在实际项目里总结出来的有些是血泪教训有些是提高效率的小技巧分享出来希望能帮你省点时间。第一条打包机上的Unity版本必须和开发机完全一致。我们曾经遇到过打包机是Unity 2021.3.5开发机是2021.3.8小版本号不同打出来的包在部分安卓机型上加载失败。后来统一用版本管理工具锁死Unity版本这个问题再没出现过。第二条AssetBundle名称全部用小写。前面提过大小写问题这里再强调一次。不仅是包名包内的资源路径也尽量用小写。Windows下开发时可能感觉不到一到安卓真机就各种“文件不存在”。统一小写能避免90%的路径问题。第三条每次打包前先清理再重新标记。不要依赖上一次的标记结果因为目录结构可能变了资源可能增删了。写一个一键打包脚本先清除所有标记再按目录规则重新标记然后执行打包。这样每次打出来的包都是干净、一致的。第四条在真机上测试加载性能。编辑器里的加载速度没有参考价值因为编辑器直接从工程目录读文件不经过压缩包解压。一定要在安卓真机上测而且要用低端机测。我习惯用一台几年前的中端安卓机做性能基准如果在这台机器上加载不卡那大部分设备都没问题。第五条给每个AssetBundle加一个引用计数。加载时计数加一释放时计数减一归零时才真正Unload。这个机制能有效防止资源被提前释放或者忘记释放。实现起来不复杂但需要在所有加载和释放的地方都严格遵守形成团队规范。第六条日志里记录每个包的加载耗时。在加载前后打时间戳输出到日志文件。这样当玩家反馈“加载慢”时你能快速定位是哪个包拖了后腿。如果某个包加载耗时明显偏高可能是包体太大或者压缩格式不合适需要针对性优化。第七条热更新清单文件加一个版本号字段。每次打包递增版本号客户端对比版本号决定是否需要更新清单。这样即使某个包的哈希没变但依赖关系变了也能通过版本号触发更新。这个小细节能避免很多“明明更新了但没生效”的诡异问题。第八条不要把所有资源都塞进AssetBundle。有些资源比如场景里固定不变的静态物体直接放在场景里打包进APK反而更简单。AssetBundle适合动态加载的资源比如角色、UI、特效。滥用AssetBundle会让资源管理变得复杂得不偿失。第九条安卓的存储权限要处理好。从Android 6.0开始写入外部存储需要动态申请权限。虽然PersistentDataPath在大多数情况下不需要额外权限但在某些定制ROM上可能会被限制。建议在游戏启动时检查存储可用性如果不可用给用户一个明确的提示而不是直接崩溃。第十条保持耐心AssetBundle的问题往往不是单一原因。一个加载失败的现象可能是路径问题、依赖问题、版本问题、权限问题叠加在一起。排查时不要只盯着一个方向用排除法逐个验证。先确认包文件存在再确认路径正确再确认依赖已加载再确认版本匹配。一步一步来总能找到原因。这套AssetBundle方案在我们几个项目中跑下来安卓端的表现算是比较稳定的。首包控制在30MB以内热更新流量平均每次版本更新在5MB左右低端机上的加载时间也能接受。当然每个项目情况不同具体参数需要根据实际情况调整。希望这些内容能帮你少走一些弯路早点把资源系统跑通把时间留给更重要的玩法开发。
1. 为什么打包成APK之后资源加载全乱套了如果你做过Unity移动端项目大概率经历过这个场景在编辑器里跑得好好的场景打包成APK装到安卓手机上要么贴图变成一片粉红要么模型直接消失要么音效播不出来。更让人抓狂的是有时候第一次装上去没问题第二次更新资源之后老用户手机上的界面就变成了“抽象画展”。这个问题的根源十有八九出在资源管理方式上。很多团队在项目初期为了图省事所有资源都塞进场景或者Resources文件夹里编辑器里一切正常因为编辑器会实时从工程目录读取资源。但一旦打包Unity会把Resources文件夹里的所有东西一股脑打进安装包包体动辄几百兆甚至上G而且每次改一个图标都得重新出整包。这时候AssetBundle就该登场了。AssetBundle是Unity提供的一套资源打包与动态加载机制。简单说它允许你把贴图、模型、预制体、音频、甚至整个场景按照你定义的规则打成一个个独立的压缩包放在服务器或者安装包的某个目录里。游戏运行时通过代码从这些包里按需加载资源。这样做的好处很直接包体可以拆得很小首包只带必要资源其余内容等玩家用到时再下载热更新变得可行改个UI贴图不用重新发版内存管理更精细不用的包可以主动卸载释放。但AssetBundle也是Unity里出了名的“坑王”。从打包策略、依赖关系、加载路径、内存释放到安卓平台特有的存储权限和压缩格式问题每一步都有细节能让你调试到凌晨三点。这篇文章就围绕“在安卓手机上跑通AssetBundle”这个目标把从零搭建到实际落地的完整链路拆开讲清楚。不管你是刚接触AssetBundle的新手还是被依赖关系绕晕的老手下面这些内容应该都能帮你省下不少查文档和试错的时间。2. 打包之前必须想清楚的资源分组逻辑2.1 按功能模块分还是按资源类型分AssetBundle打包的第一步不是写代码而是决定怎么分组。这个决定一旦做错后期改起来成本极高。我见过不少项目一开始按“贴图一个包、模型一个包、音效一个包”来分结果加载一个角色要同时请求五六个包IO次数暴增加载时间翻倍。也见过所有资源打成一个包的包体巨大不说改一个按钮图标要重新下载整个包。比较稳妥的分组思路是按功能模块划分同时兼顾资源类型。举个例子一个角色扮演类项目可以这样分分组名称包含内容加载时机ui_common通用按钮、字体、通用弹窗背景游戏启动时常驻ui_main主界面专属贴图与预制体进入主界面时加载role_hero_001某个英雄的模型、贴图、动画、技能特效选中该英雄时加载scene_battle_01战斗场景的地形、光照贴图、装饰物进入战斗时加载audio_bgm背景音乐按需加载audio_sfx音效按需加载这个分法的核心逻辑是把同时使用、同时废弃的资源放在一起。ui_common里的东西几乎全程都在用所以常驻内存没问题。role_hero_001只在特定英雄出场时用英雄换下去就可以整个包卸载。scene_battle_01打完这一局就可以释放。这样内存曲线是可控的不会出现越玩越卡的情况。2.2 依赖关系是绕不开的坎AssetBundle最让人头疼的就是依赖。假设你把一个角色的贴图放在role_hero_001包里但这个贴图同时被ui_main里的某个头像框引用了。如果你分别打这两个包Unity在打包时会自动把被共享的资源复制一份到两个包里造成冗余。更糟糕的是如果两个包引用了同一个材质而材质又引用了同一个Shader加载时可能会出现Shader丢失导致的粉红材质。正确的做法是把被多个包共享的资源单独抽出来打成一个共享包。比如所有UI共用的图集、所有角色共用的Shader、通用字体都放到一个叫shared_assets的包里。其他包在打包时Unity会自动记录对shared_assets的依赖。运行时必须先加载shared_assets再加载具体功能包否则会出现引用丢失。这里有个实操细节Unity在打包时会生成一个和AssetBundle同名的.manifest文件里面记录了该包的依赖关系。你可以用代码读取这个文件来获取依赖列表但更推荐的做法是在打包脚本里自己维护一份依赖配置表因为.manifest文件在运行时读取需要额外的IO而且格式是Unity私有的解析起来不够灵活。注意如果A包依赖B包加载A之前必须先加载B。但B包加载后不能立即卸载否则A包里的资源会变成“空引用”。这个顺序问题在热更新场景下尤其容易出错。2.3 粒度控制太粗和太细都难受包分得太粗比如所有UI打成一个包那改一个界面就要重新下载整个UI包热更新流量浪费严重。包分得太细比如每个预制体一个包那加载一个界面可能要请求几十个包安卓手机上的文件IO本来就慢加载时间会变得不可接受。我的经验是单个AssetBundle的未压缩大小控制在1MB到5MB之间。小于1MB的包考虑合并到相邻功能模块大于5MB的包考虑按使用频率或场景进一步拆分。当然这不是硬性标准具体要看项目类型。休闲游戏可能整个游戏才几十兆那包可以分得粗一些大型MMO可能一个场景就上百兆那必须拆得很细。还有一个容易被忽略的点AssetBundle的数量本身也有开销。每个包在加载时都会产生一个AssetBundle对象这个对象本身占用内存而且Unity内部对同时打开的AssetBundle数量是有限制的。虽然这个限制比较高但在低端安卓机上同时打开几十个包确实会导致明显的卡顿。所以分组时也要考虑运行时同时活跃的包数量尽量控制在10个以内。3. 打包脚本怎么写才不给自己挖坑3.1 标记资源AssetBundle名称的命名规范在Unity编辑器里选中一个资源在Inspector面板最下方可以设置它的AssetBundle名称和变体Variant。名称格式通常是“包名.扩展名”比如“role_hero_001.unity3d”。扩展名可以随便写但建议统一方便后续识别。手动一个个标记资源是不现实的项目里几千个资源标到猴年马月。通常的做法是写一个编辑器脚本根据资源所在目录自动设置AssetBundle名称。比如所有放在Assets/UI/Main目录下的资源自动标记为“ui_main”。这样美术和策划只需要按规范放资源打包时自动分组。这里有个坑目录结构变化后AssetBundle名称不会自动更新。比如你把一个资源从UI/Main移到了UI/Common但之前标记的AssetBundle名称还是ui_main打包时它还是会进ui_main包。所以每次打包前最好先清除所有资源的AssetBundle标记再重新按目录规则标记一遍。清除的代码很简单string[] allAssets AssetDatabase.GetAllAssetPaths(); foreach (string asset in allAssets) { AssetImporter importer AssetImporter.GetAtPath(asset); if (importer ! null) { importer.assetBundleName string.Empty; importer.assetBundleVariant string.Empty; } }这段代码会遍历工程里所有资源把AssetBundle名称清空。执行完之后再根据目录规则重新赋值确保标记和实际目录结构一致。3.2 打包参数BuildAssetBundleOptions怎么选Unity的BuildPipeline.BuildAssetBundles方法有一个BuildAssetBundleOptions参数用来控制打包行为。常用的选项有这几个None默认不做任何特殊处理。UncompressedAssetBundle不压缩。包体大但加载快因为省去了解压步骤。ChunkBasedCompression使用LZ4压缩。这是我最推荐的选项。LZ4的压缩率不如LZMA但解压速度极快而且支持随机读取不需要把整个包解压到内存里。对于移动端来说这个平衡点非常合适。DisableWriteTypeTree不写入类型树信息。可以减小包体但会降低版本兼容性。如果Unity版本升级后资源格式有变化可能会加载失败。一般不建议开启除非你对版本控制非常有信心。DeterministicAssetBundle让每次打包生成的AssetBundle的哈希值保持一致。这个选项对热更新差分对比很有用建议开启。综合下来移动端项目的推荐配置是BuildAssetBundleOptions options BuildAssetBundleOptions.ChunkBasedCompression | BuildAssetBundleOptions.DeterministicAssetBundle;ChunkBasedCompression在安卓上的表现尤其好因为安卓的存储IO性能参差不齐LZ4的快速解压能明显减少加载等待时间。而DeterministicAssetBundle能让相同内容的包生成相同的哈希方便做增量更新。3.3 平台差异安卓和编辑器下的包不能混用这是新手最容易踩的坑之一在编辑器里打好的AssetBundle直接拷到安卓手机上用结果加载报错。原因是AssetBundle是平台相关的编辑器Windows/Mac下打的包和安卓、iOS下打的包内部格式不同不能混用。所以打包脚本里必须根据当前目标平台设置BuildTargetBuildTarget target BuildTarget.Android; if (EditorUserBuildSettings.activeBuildTarget BuildTarget.iOS) { target BuildTarget.iOS; } BuildPipeline.BuildAssetBundles(outputPath, bundles, options, target);输出目录也建议按平台分开比如“AssetBundles/Android”和“AssetBundles/iOS”避免混淆。另外安卓平台还有一个特殊之处StreamingAssets目录下的文件在APK里是压缩的不能直接用File.ReadAllBytes读取。如果要把AssetBundle随包发布需要放在StreamingAssets里然后用UnityWebRequest来读取它会自动处理APK内的解压。3.4 打包后的文件清单与版本管理每次打包完成后除了AssetBundle文件本身还会生成一个总的manifest文件和输出目录同名。这个文件记录了所有包的列表、依赖关系和哈希值。做热更新时通常需要把这个manifest文件也上传到服务器客户端下载后对比本地版本决定哪些包需要更新。我习惯在打包脚本最后加一步生成一个自定义的版本清单文件格式用JSON包含每个包的名称、哈希、大小、依赖列表。这样客户端解析起来比Unity原生的manifest方便得多。示例结构{ version: 1.0.3, bundles: [ { name: ui_common, hash: a1b2c3d4, size: 102400, deps: [shared_assets] }, { name: role_hero_001, hash: e5f6g7h8, size: 204800, deps: [shared_assets] } ] }这个文件在客户端启动时下载和本地缓存的版本对比有差异的包才去下载。这样能把热更新的流量降到最低。4. 安卓手机上的加载路径与存储策略4.1 只读的StreamingAssets和可写的PersistentDataPath安卓系统对应用的文件访问有严格限制。APK安装后里面的文件是只读的不能修改。而应用有一个专属的可写目录在Unity里通过Application.persistentDataPath获取路径类似“/storage/emulated/0/Android/data/包名/files”。这个目录下的文件可以自由读写而且应用卸载时会被清除。AssetBundle的存放策略通常是这样的首包自带的资源放在StreamingAssets里热更新的资源下载到PersistentDataPath里。运行时先检查PersistentDataPath里有没有对应的包有就用本地的没有就从StreamingAssets里读或者从服务器下载。这里有个细节StreamingAssets里的文件在安卓上不能直接用File类读取必须用UnityWebRequest。而PersistentDataPath里的文件可以用File.ReadAllBytes直接读。所以加载代码里需要根据路径来源选择不同的读取方式。我一般会封装一个统一的加载接口内部判断路径前缀自动选择读取方式。4.2 加载方式同步还是异步AssetBundle的加载API有两套同步的AssetBundle.LoadFromFile和异步的AssetBundle.LoadFromFileAsync。在移动端强烈建议全部使用异步加载。原因很简单同步加载会阻塞主线程安卓手机上一次IO操作可能耗时几十毫秒甚至上百毫秒如果同时加载多个包卡顿感会非常明显。异步加载虽然代码写起来麻烦一点需要处理回调或协程但能保证游戏帧率稳定。用协程写异步加载的典型结构IEnumerator LoadBundleAsync(string path) { AssetBundleCreateRequest request AssetBundle.LoadFromFileAsync(path); yield return request; AssetBundle bundle request.assetBundle; if (bundle null) { Debug.LogError(加载失败: path); yield break; } // 加载包内资源 AssetBundleRequest assetRequest bundle.LoadAssetAsyncGameObject(MyPrefab); yield return assetRequest; GameObject prefab assetRequest.asset as GameObject; Instantiate(prefab); }如果是UnityWebRequest方式用于StreamingAssets或远程下载结构类似只是把AssetBundle.LoadFromFileAsync换成UnityWebRequestAssetBundle.GetAssetBundle。4.3 依赖包的加载顺序不能乱前面提到过有依赖关系的包必须先加载被依赖的包。但实际项目中依赖关系可能有多层A依赖BB依赖C。手动管理加载顺序很容易出错。我的做法是写一个依赖解析器在加载某个包之前先递归加载它所有的依赖包确保依赖树上的每个包都已经在内存里。具体实现时可以用一个字典记录已经加载的包避免重复加载。加载依赖时如果发现某个依赖包已经在字典里就跳过。伪代码逻辑void LoadBundleWithDeps(string bundleName) { if (loadedBundles.ContainsKey(bundleName)) return; string[] deps GetDependencies(bundleName); foreach (string dep in deps) { LoadBundleWithDeps(dep); } AssetBundle bundle LoadBundleFromDisk(bundleName); loadedBundles.Add(bundleName, bundle); }这个递归逻辑看起来简单但实际写的时候要注意循环依赖的问题。虽然Unity在打包时会检测并阻止循环依赖但自己维护的依赖配置表如果写错了还是可能出现死循环。加一个正在加载中的标记集合可以避免这个问题。4.4 卸载时机什么时候可以安全释放AssetBundle的卸载有两个APIAssetBundle.Unload(false)和AssetBundle.Unload(true)。参数为false时只释放AssetBundle对象本身从包里加载出来的资源比如GameObject、Texture不会被销毁。参数为true时连加载出来的资源也一并销毁。选哪个取决于你的资源管理策略。如果资源已经被其他系统引用比如场景里已经实例化的物体用Unload(true)会导致这些物体变成粉红或消失。所以大多数情况下用Unload(false)然后自己管理资源的生命周期。当确定某个资源不再被任何地方引用时再手动Destroy它最后调用Resources.UnloadUnusedAssets()清理。但这里有个陷阱如果资源还被引用Resources.UnloadUnusedAssets()不会释放它。所以你需要一套引用计数机制记录每个资源被多少地方使用。当计数归零时才真正销毁。这套机制实现起来不复杂但需要在所有加载和释放资源的地方都严格遵守否则就会出现内存泄漏或者提前释放的问题。提示在安卓低内存设备上AssetBundle卸载不及时是导致闪退的主要原因之一。建议在场景切换、大界面关闭等关键节点主动触发一次资源清理。5. 真机调试中那些让人抓狂的报错5.1 “The AssetBundle can not be loaded because it was created with a newer version of Unity”这个报错的意思是AssetBundle是用更新版本的Unity打的当前运行的Unity版本不支持。解决办法很简单确保打包和运行使用的是同一个Unity版本。但实际项目中有时候团队里不同人用的Unity版本不一致或者打包机上的版本和开发机不同就会出这个问题。建议在项目里锁定Unity版本用版本管理工具统一管理。5.2 加载成功但资源显示异常有时候包加载成功了没有报错但实例化出来的物体贴图丢失、材质变粉。这种情况通常是Shader丢失导致的。AssetBundle里如果引用了自定义Shader而这个Shader没有被打进任何包或者打包时被剥离了运行时就会找不到。解决办法是把所有用到的Shader显式加入Always Included Shaders列表或者单独打一个Shader包确保它先于其他包加载。另一个可能的原因是依赖包没有加载。比如A包里的预制体引用了B包里的材质但加载A之前没有加载BUnity在实例化时会找不到材质显示为默认的粉红材质。这种问题不会报错但表现很明显。排查方法是检查加载日志确认所有依赖包都已经在内存里。5.3 安卓上的文件路径大小写问题Windows系统对文件路径大小写不敏感但安卓是基于Linux的大小写敏感。如果你在代码里写的路径是“UI_Common”而实际文件名是“ui_common”在编辑器里能正常加载到了安卓上就报“文件不存在”。这个坑非常隐蔽因为编辑器里测试一切正常。解决办法是统一命名规范所有AssetBundle名称和路径全部用小写字母加下划线避免大小写混用。5.4 内存泄漏包越加载越多AssetBundle如果只加载不卸载内存会持续增长最终导致闪退。常见的原因有加载了包但忘记在合适的时候调用Unload或者调用了Unload(false)但资源还被引用导致包对象释放了但资源内存没释放或者重复加载同一个包每次都创建新的AssetBundle对象旧的对象没有被释放。排查内存泄漏可以用Unity Profiler在安卓真机上连接Profiler观察AssetBundle对象数量和Texture内存的变化。如果发现AssetBundle数量只增不减那肯定是卸载逻辑有问题。建议在代码里加一个调试面板实时显示当前加载的包列表和内存占用方便定位问题。6. 从首包到热更新一套可落地的资源更新流程6.1 首包资源的最小化策略首包的大小直接影响用户的下载意愿。安卓应用商店对APK大小虽然没有硬性限制但超过100MB之后下载转化率会明显下降。所以首包里只放启动必须的资源登录界面、基础UI、加载动画、必要的Shader和字体。其他所有资源都通过热更新在首次启动后下载。具体操作上可以把首包资源单独打一个包放在StreamingAssets里。游戏启动时先加载这个首包显示加载界面同时后台去服务器请求版本清单对比差异下载缺失的包。下载完成后后续所有资源都从PersistentDataPath加载。6.2 版本对比与增量下载版本对比的核心是前面提到的JSON清单文件。客户端启动时先读取本地缓存的清单如果没有就用首包里的清单然后从服务器下载最新的清单逐个对比每个包的哈希值。哈希不同的包需要更新哈希相同的包直接复用本地缓存。增量下载时可以同时下载多个包但要注意控制并发数。安卓手机的网络IO和磁盘IO都有瓶颈同时下载太多包反而会拖慢整体速度。我的经验是并发数控制在3到5个比较合适。下载完成后校验文件的哈希值确保没有损坏然后写入PersistentDataPath。6.3 断点续传与失败重试移动网络不稳定下载中断是常有的事。如果每次中断都从头开始下载用户体验会很差。所以下载逻辑里必须支持断点续传。实现方式是利用HTTP的Range头记录已下载的字节数下次请求时从断点位置继续。失败重试也要做好。网络请求失败后不要立即弹窗报错而是自动重试2到3次每次间隔递增比如1秒、3秒、5秒。如果重试仍然失败再提示用户检查网络。重试逻辑要区分错误类型如果是404文件不存在重试没有意义直接报错如果是超时或连接中断才值得重试。6.4 更新完成后的资源切换所有包下载完成后需要把资源加载路径从StreamingAssets切换到PersistentDataPath。这个切换通常发生在重启游戏或者重新进入某个场景时。切换时要确保旧的AssetBundle已经全部卸载避免新旧资源混用导致的问题。一个稳妥的做法是下载完成后提示用户“更新完成需要重启游戏生效”然后调用Application.Quit()用户重新打开后自然就从新资源加载了。虽然体验上多了一次重启但能避免很多资源状态不一致的诡异问题。如果不想重启那就需要在代码里严格管理资源切换的时机确保所有旧资源都被释放新资源按正确的依赖顺序加载。7. 几个让我少熬几个通宵的实操心得AssetBundle这套东西文档看再多不如自己踩一遍坑来得深刻。下面这几条是我在实际项目里总结出来的有些是血泪教训有些是提高效率的小技巧分享出来希望能帮你省点时间。第一条打包机上的Unity版本必须和开发机完全一致。我们曾经遇到过打包机是Unity 2021.3.5开发机是2021.3.8小版本号不同打出来的包在部分安卓机型上加载失败。后来统一用版本管理工具锁死Unity版本这个问题再没出现过。第二条AssetBundle名称全部用小写。前面提过大小写问题这里再强调一次。不仅是包名包内的资源路径也尽量用小写。Windows下开发时可能感觉不到一到安卓真机就各种“文件不存在”。统一小写能避免90%的路径问题。第三条每次打包前先清理再重新标记。不要依赖上一次的标记结果因为目录结构可能变了资源可能增删了。写一个一键打包脚本先清除所有标记再按目录规则重新标记然后执行打包。这样每次打出来的包都是干净、一致的。第四条在真机上测试加载性能。编辑器里的加载速度没有参考价值因为编辑器直接从工程目录读文件不经过压缩包解压。一定要在安卓真机上测而且要用低端机测。我习惯用一台几年前的中端安卓机做性能基准如果在这台机器上加载不卡那大部分设备都没问题。第五条给每个AssetBundle加一个引用计数。加载时计数加一释放时计数减一归零时才真正Unload。这个机制能有效防止资源被提前释放或者忘记释放。实现起来不复杂但需要在所有加载和释放的地方都严格遵守形成团队规范。第六条日志里记录每个包的加载耗时。在加载前后打时间戳输出到日志文件。这样当玩家反馈“加载慢”时你能快速定位是哪个包拖了后腿。如果某个包加载耗时明显偏高可能是包体太大或者压缩格式不合适需要针对性优化。第七条热更新清单文件加一个版本号字段。每次打包递增版本号客户端对比版本号决定是否需要更新清单。这样即使某个包的哈希没变但依赖关系变了也能通过版本号触发更新。这个小细节能避免很多“明明更新了但没生效”的诡异问题。第八条不要把所有资源都塞进AssetBundle。有些资源比如场景里固定不变的静态物体直接放在场景里打包进APK反而更简单。AssetBundle适合动态加载的资源比如角色、UI、特效。滥用AssetBundle会让资源管理变得复杂得不偿失。第九条安卓的存储权限要处理好。从Android 6.0开始写入外部存储需要动态申请权限。虽然PersistentDataPath在大多数情况下不需要额外权限但在某些定制ROM上可能会被限制。建议在游戏启动时检查存储可用性如果不可用给用户一个明确的提示而不是直接崩溃。第十条保持耐心AssetBundle的问题往往不是单一原因。一个加载失败的现象可能是路径问题、依赖问题、版本问题、权限问题叠加在一起。排查时不要只盯着一个方向用排除法逐个验证。先确认包文件存在再确认路径正确再确认依赖已加载再确认版本匹配。一步一步来总能找到原因。这套AssetBundle方案在我们几个项目中跑下来安卓端的表现算是比较稳定的。首包控制在30MB以内热更新流量平均每次版本更新在5MB左右低端机上的加载时间也能接受。当然每个项目情况不同具体参数需要根据实际情况调整。希望这些内容能帮你少走一些弯路早点把资源系统跑通把时间留给更重要的玩法开发。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
