资源包形态：AB、Addressables 与加载方式（入门）
状态：初稿，后续讨论会持续补充
上级导航：<00-热更新学习导航>
相关：<01-整包热更强更与CDN入门>（版本号 / CDN / 热更背景）
这篇先解决什么
- 热更里的「资源」在磁盘上长什么样
- AssetBundle（AB）是什么、为啥能「打成包」
- Addressables 和 AB 什么关系；为啥不只用 Resources
- 一个 Prefab 为啥会依赖多个 AB
1. 设备上可能有几类资源
| 形态 | 在哪 | 热更能改吗 | 人话 |
|---|---|---|---|
| 包内资源 | 装进 apk/ipa 的那份 | 基本不能（除非整包） | 随安装包带来的底货 |
| 热更资源包 | 可写目录里下载来的文件 | 能 | 后来快递来的补丁货 |
| 散文件（配置 json、部分音频等） | CDN → 可写目录 | 能 | 简单或特殊用途；大项目很少靠散文件扛全部资产 |
热更说的「资源包」，多半指：打成包再下载的那一类（Unity 里核心是 AB）。
2. AssetBundle（AB）是什么
AssetBundle = Unity 把若干资产打成的二进制容器（可再压缩）。
不是随便打了个 zip，而是引擎认识的「资源集装箱」：里面有资产数据，以及依赖、加载所需的引擎约定信息。
2.1 外形上常见什么
- 一堆包文件：
ui_hall.ab、shared_tex_xxx.ab...（后缀各项目自定） - 一份清单（旧称 Manifest；Addressables 下常是 Catalog）：有哪些包、依赖谁、hash 多少
示意：
CDN/
Android/
v105/
catalog.json ← 清单
ui_hall_a1b2c3.ab
shared_tex_d4e5f6.ab
config_789abc.ab本地热更后落在可写目录，一般不改安装包内部。
2.2 为啥能把资源「变成这种包」
不是万能压缩任意文件，而是：
走 Unity 构建管线的资产，被序列化进引擎运行时认识的容器 → 这个容器叫 AssetBundle。
- 编辑器里的 Prefab / Texture / Material / Audio... 本就是 Unity 资产
- Build：按依赖收集 → 写成 AB 二进制（可 LZ4/LZMA 等压缩）
- 运行时：用 AB API 加载，才能还原成可用对象
能进 AB： 多数被 Unity 导入、参与构建的资产。
也可不进 AB： 自己读的 json/bytes、部分视频等------可当散文件热更，或打成 TextAsset 再进 AB。
2.3 为啥要打包，而不是全用散文件
- 减少请求次数；按模块增量更新
- 引擎统一处理加载与依赖
- 便于校验、压缩、（可选）加密
代价：要设计怎么拆包（太大难更，太碎难管）------进阶再细讲。
3. Addressables：管理系统，不是另一种压缩格式
| AssetBundle | Addressables | |
|---|---|---|
| 是什么 | 产物 / 格式（集装箱） | 资源管理系统（仓库管理员） |
| 你面对的 | 文件路径 / 包名 | 地址（Address） ，如 "UI/Hall" |
| 磁盘上最终 | AB + 清单 | 常常仍是 AB + Catalog |
人话：AB 是货柜；Addressables 是仓库系统------你喊货架号，它负责找哪个柜、要不要远程下、怎么更新。
3.1 怎么演出来的（Unity 官方迭代）
- Resources --- 最早好用，规模一大就疼
- AssetBundle --- 官方底层：能打、能下、能加载；依赖/打包/更新/引用计数全靠项目自搓，易踩坑
- 中间有过 AssetBundle Manager 等半官方/示例方案
- Addressable Asset System --- Unity 官方 上层方案：分组、寻址、远程、Catalog 更新；底层仍大量落在 AB 上
结论：Addressables ≈ 官方承认「光给 AB 太难用」，送你一套管理工具。
3.2 本质上是不是资源管理工具？
对。 Addressables（以及 YooAsset 等自研/第三方加载器）本质都是资源管理 ：寻址、分组、构建、下载、加载/卸载、更新。
AB 是它们常管理的那种货柜格式。
4. 是不是很少走 Resources，大多走 AB？
正式项目主内容：很少再靠 Resources.Load 扛大头；主因不只是跨平台路径。
| 方式 | 定位 | 热更友好？ |
|---|---|---|
| Resources | 包内固定目录，API 简单 | 差：打进包体，难模块化远程更新，卸载别扭 |
| AssetBundle | 可本地可远程的模块化包 | 好 |
| Addressables | 用地址管理（底下常是 AB） | 好 |
| 散文件 / 自研 | 自己下配置等 | 可以，依赖要自己管 |
弃用 Resources 当主力的更大理由：
- 全进包 → 包体膨胀
- 不好做远程增量热更
- 内存 / 卸载 historically 别扭
- 依赖与打包策略难做细
跨平台路径差异（Android StreamingAssets、jar:file://、iOS 只读包等）会推动你用统一加载层，但是附带痛点，不是唯一原因。
常见折中：登录/热更 UI 等极小底货 可放包内或 Resources；玩法大内容走 AB / Addressables。
5. 为啥 AB 这么热？没有别的打包方式吗？
在 Unity 生态 里，AB 几乎是「从包外/远程加载正式资产」的一等公民（引擎正门）：依赖、序列化、实例化都接得上；文档与第三方方案也围着它。
其它路线（仍要分清层级）：
| 路线 | 说明 |
|---|---|
| Resources | 仍在，适合极小包内资源 |
| Addressables | 官方主流管理法，底下多是 AB |
| YooAsset / xAsset 等 | 另一套管理+构建；产物常仍是 AB 或同类 |
| 散文件热更 | 配置、脚本补丁等；不替代整棵资产依赖树 |
| 其它引擎的 Pak 等 | 别的引擎的正门，不是 Unity 里 AB 的平替 |
不是世界上只有 AB 这一种「打包思想」，而是在 Unity 里做可分发、可热更、带依赖的资产，AB + 其上的管理系统是主航道。
6. 一个 Prefab 为啥会依赖多个 AB
方向正确：UI 用到的图集、字体、公共控件等可能在别的 AB 里，加载这个界面就要把依赖包一并准备好。
再补常见动机：
- 多界面共享同一图集/字体 → 打成独立「共享包」，避免每个界面包各拷一份
- Prefab → 材质 → 贴图，依赖链跨包
因此：不是随便拆，而是故意拆 + 清单记下依赖；加载时按依赖加载相关 AB。Addressables 会尽量把这层麻烦藏起来，但依赖关系仍然存在。
（依赖策略、循环依赖等 → 后续可单独加深。）
7. 三层视角：资源「长什么样」
| 层 | 你看到什么 |
|---|---|
| 编辑器 | 散的 Prefab、图、表... |
| 构建后（给 CDN） | AB 文件们 + 清单；文件名常带 hash |
| 运行时 | 查清单 → 缺则下 → 从 AB Load 出对象；业务最好只关心地址 |
和版本号的关系（见 <01-整包热更强更与CDN入门> §3）：
- resVersion 涨了 → 常指向新清单 / 新目录
- 清单列出各 AB 的 hash 与依赖 → 客户端只下变更包
版本号 = 第几版货单；资源包 = 货单上的集装箱。
8. 脑图收束
编辑器里的散资源
↓ Build
AssetBundle 文件们 + 清单(Catalog/Manifest)
↓ 上传
CDN / 源站
↓ 热更下载
本地可写目录
↓ Load（常经 Addressables 等管理器）
Prefab / 图 / 表 ...9. 迷你自测
- AB 和 Addressables 是两种互斥的包格式吗？
- 热更下来的 AB 改安装包内部，还是可写目录？
- 为啥大项目少把主内容放 Resources？
- Prefab 依赖多个 AB，是否只因为「拆包拆散了」？
参考倾向： 1 不是，Addressables 是管理系统，底下常是 AB；2 可写目录；3 包体/热更/卸载/依赖；4 不单是散，还有共享依赖、链路跨包等故意设计。
10. 待后续补充
- 依赖关系细则、共享包、Shader/字体单独包
- Manifest / Catalog 字段长什么样
- 打包粒度：太大 vs 太碎
- Addressables Group / Label / Remote 配置直觉
修订记录
| 日期 | 变更 |
|---|---|
| 2026-08-06 | 初稿：AB 形态、与 Addressables/Resources 关系、依赖多包直觉、演进出路 |