4、AssetBundle打包策略：从API到实战的完整指南
AssetBundle打包，说白了就是把你的资源打包成一个个独立的小包裹。我做了这么多年项目，发现很多团队都在这一步栽过跟头。今天我就把压箱底的经验掏出来，跟你聊聊打包的那些事儿。
4.1 打包API：BuildPipeline.BuildAssetBundles
Unity提供的核心API就一个——BuildPipeline.BuildAssetBundles。别看就这一个函数，用好了能省不少事。
// 基础用法
BuildPipeline.BuildAssetBundles(
"Assets/StreamingAssets",
BuildAssetBundleOptions.None,
BuildTarget.StandaloneWindows64
);嗯，这里要注意几个参数。第一个是输出路径，我习惯放在Assets/StreamingAssets下，这样打包后直接跟着安装包走。第二个参数是选项，第三个是目标平台。
核心参数详解：
- BuildAssetBundleOptions.None：默认选项，不压缩。适合开发阶段快速迭代。
- BuildAssetBundleOptions.ChunkBasedCompression：LZ4压缩。我个人最推荐这个，加载快、包体小。
- BuildAssetBundleOptions.UncompressedAssetBundle：不压缩。加载最快，但包体最大。
我在项目中遇到过一个问题：用None选项打包后，包体居然比原始资源还大！后来才发现，Unity默认用了LZMA压缩，虽然压缩率高，但解压时会把整个包都解压到内存里。你想想看，一个100MB的包，解压后可能变成200MB，这谁受得了？
我的建议：正式发布时用ChunkBasedCompression。它按块压缩，加载时只解压需要的块，内存和速度都兼顾。
4.2 打包分组策略：三种主流方案
分组策略是打包的灵魂。分得好，加载快、更新小；分得差，用户骂娘、老板拍桌。我总结了三种主流方案，你可以根据项目情况灵活组合。
4.2.1 按逻辑分组
说白了，就是把功能相关的资源放一起。比如一个UI界面，它的图片、字体、预制体都放在一个包里。
// 示例：UI主界面包
Assets/UI/MainPanel/
├── MainPanel.prefab
├── bg.png
├── btn_normal.png
└── font.otf这样做的好处是：加载一个界面，只需要加载一个包。我曾经做过一个MMO项目，每个场景的模型、贴图、动画都按逻辑分组。玩家切换场景时，只需要加载当前场景的包，其他场景的资源根本不用管。加载速度直接提升了40%。
注意：别把太多资源塞进一个逻辑包。我见过有人把整个游戏的所有UI都放一个包里，结果打开背包界面要等3秒。用户早跑了。
4.2.2 按更新频率分组
这个策略很实用。把经常更新的资源和不常更新的资源分开打包。
| 更新频率 | 资源类型 | 打包建议 |
|---|---|---|
| 高频（每周更新） | 活动UI、节日特效、新角色模型 | 每个活动单独一个包 |
| 中频（每月更新） | 英雄皮肤、武器模型 | 按系列分组 |
| 低频（几乎不更新） | 基础UI、通用模型、核心逻辑 | 合并成大包 |
我有个血的教训：曾经把活动资源和基础UI混在一起打包。结果每次更新活动，用户都要重新下载整个基础UI包。100MB的包，用户只更新了1MB的活动资源，却要下100MB。你说用户气不气？
避坑指南：我曾经把配置表也打进AssetBundle里。结果每次改个数值，都要重新打包整个配置表包。后来我把配置表单独拎出来，用TextAsset存，更新时只替换这个文件。嗯，省事多了。
4.2.3 按资源类型分组
把相同类型的资源放一起。比如所有贴图放一个包，所有模型放一个包，所有音频放一个包。
// 按类型分组示例
Assets/AssetBundles/
├── textures.unity3d // 所有贴图
├── models.unity3d // 所有模型
├── audio.unity3d // 所有音频
└── prefabs.unity3d // 所有预制体这种方案适合资源复用率高的项目。比如多个场景共用同一张贴图，那这张贴图只需要加载一次，所有场景都能用。但有个问题：如果你只想要一个模型，却要下载整个模型包，里面可能包含几十个你不需要的模型。
我的经验：按类型分组适合做公共资源包。比如所有UI共用的字体、所有场景共用的天空盒。这些资源加载一次，全局可用。但别把业务资源也这么搞，否则加载效率会很低。
4.3 打包命名规范：让团队少走弯路
命名规范看似小事，但做不好能让你崩溃。我见过有人把包名写成ab_1、ab_2，结果半年后谁都不知道里面装了什么。
我推荐一套命名规范，用了好几年，团队反馈都不错：
// 命名格式：模块_子模块_功能_版本
ui_mainpanel_v1
ui_shop_v2
scene_city_buildings_v1
character_hero_sword_v3规则很简单：
- 模块名：ui、scene、character、audio等
- 子模块：mainpanel、shop、city等
- 功能描述：buildings、sword等（可选）
- 版本号：v1、v2等
千万别这样做：
- 用中文命名（跨平台可能出问题）
- 用数字开头（Unity编辑器不识别）
- 用特殊符号（Windows和Mac路径解析不同）
- 名字太长（超过64字符可能被截断）
我曾经接手过一个项目，包名全是a1、b2这种。我花了整整一周，一个个打开看里面是什么资源，然后重新命名。那感觉，就像在垃圾堆里找宝贝。所以，命名规范一定要从项目第一天就定好。
4.4 实战组合策略
说了这么多，到底怎么组合？我一般这样用：
- 公共资源包：按类型分组。所有UI字体、所有场景天空盒、所有通用Shader。这些几乎不更新，打包成一个大包。
- 业务资源包：按逻辑分组。每个功能模块一个包。比如商城界面、角色选择界面、战斗场景。
- 活动资源包：按更新频率分组。每个活动单独一个包。更新时只替换活动包，不动其他包。
// 最终打包结构示例
Assets/AssetBundles/
├── common_textures_v1.unity3d // 公共贴图
├── common_shaders_v1.unity3d // 公共Shader
├── ui_mainpanel_v2.unity3d // 主界面
├── ui_shop_v1.unity3d // 商城界面
├── scene_battle_v3.unity3d // 战斗场景
└── activity_christmas_v1.unity3d // 圣诞节活动这样打包的好处是：用户第一次进游戏，下载公共资源包（约50MB）。然后按需加载业务包。每次更新，只下载活动包（约5MB）。用户开心，你也省心。
最后提醒：打包前一定要用AssetBundleBrowser工具检查依赖。我见过有人把同一个模型打了三个包，每个包都包含这个模型。用户下载了三次，你说冤不冤？
好了，AssetBundle打包策略就聊到这儿。记住：分组是艺术，命名是规范，API是工具。三者结合，才能做出高效的资源管理系统。下一章我们聊聊加载策略，到时候见。