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下打的包，内部格式不同，不能混用。
所以打包脚本里必须根据当前目标平台设置BuildTarget：
BuildTarget 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.LoadAssetAsync<GameObject>("MyPrefab"); yield return assetRequest; GameObject prefab = assetRequest.asset as GameObject; Instantiate(prefab); }如果是UnityWebRequest方式（用于StreamingAssets或远程下载），结构类似，只是把AssetBundle.LoadFromFileAsync换成UnityWebRequestAssetBundle.GetAssetBundle。
4.3 依赖包的加载顺序不能乱
前面提到过，有依赖关系的包必须先加载被依赖的包。但实际项目中，依赖关系可能有多层，A依赖B，B依赖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的卸载有两个API：AssetBundle.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之前没有加载B，Unity在实例化时会找不到材质，显示为默认的粉红材质。这种问题不会报错，但表现很明显。排查方法是检查加载日志，确认所有依赖包都已经在内存里。
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左右，低端机上的加载时间也能接受。当然每个项目情况不同，具体参数需要根据实际情况调整。希望这些内容能帮你少走一些弯路，早点把资源系统跑通，把时间留给更重要的玩法开发。
