Unity发布aab(Android App Bundle)详解(一)从APK到AAB：Unity版本支持与打包配置全解析

1. Android App Bundle 是什么？为什么 Unity 开发者需要关注它？

如果你是一名 Unity 开发者，最近准备在 Google Play 上发布游戏，可能会遇到一个强制要求：必须使用 Android App Bundle（简称 AAB）格式提交应用。这可不是什么可选项，而是 Google 从 2021 年 8 月开始实施的硬性规定。

简单来说，AAB 是 Google 推出的新一代应用发布格式，用来取代传统的 APK+OBB 组合。它的核心优势在于能够根据用户设备的具体配置（CPU 架构、语言、屏幕分辨率等）动态生成最优化的 APK，让用户只下载他们真正需要的资源。想象一下，你的游戏有高清纹理包，但用户的手机屏幕只有 720p 分辨率，传统方式下用户不得不下载所有资源，而 AAB 则可以智能地只分发 720p 版本的资源。

在实际项目中，我发现 AAB 带来的好处非常明显。以我们团队的一款休闲游戏为例，改用 AAB 后，用户平均下载体积减少了 35%，安装成功率提升了 15%。特别是在新兴市场，很多用户还在使用存储空间有限的低端设备，这种优化效果更加显著。

2. Unity 各版本对 AAB 的支持情况

2.1 官方支持时间线

Unity 对 AAB 的支持经历了一个逐步完善的过程。根据我的实际测试和经验，以下是各 LTS 版本的关键支持节点：

• Unity 2019 LTS：从 2019.4.29f1 开始提供完整支持
• Unity 2020 LTS：2020.3.15f2 是第一个稳定支持的版本
• Unity 2021 LTS：2021.2.0b4 及以上版本支持最佳

这里有个坑我踩过：早期版本虽然能生成 AAB 文件，但在处理大资源包时会出现各种问题。比如在 Unity 2019.4.28 上，超过 150MB 的资源包会导致上传失败，而升级到 2019.4.29f1 后问题就解决了。

2.2 版本选择建议

如果你正在开始一个新项目，我的建议是直接使用最新的 Unity 2021 LTS 版本。不仅因为它的 AAB 支持最完善，还因为它集成了 Play Asset Delivery 的最新功能。对于维护中的老项目，至少要升级到上述提到的各版本最低支持版本。

有个实际案例：我们有个使用 Unity 2018 的老项目，为了上架 Google Play 不得不升级到 2019.4.29f1。升级过程还算顺利，主要工作量集中在解决一些过时的 API 和 Shader 兼容性问题上。

3. 基础打包配置详解

3.1 必须开启的关键设置

要让 Unity 生成 AAB 文件，有两个关键设置必须配置正确：

1. Build App Bundle (Google Play)：在 Build Settings 窗口中勾选
2. Split Application Binary：在 Player Settings > Android > Publish Settings 底部

这里有个有趣的细节：Split Application Binary 原本是用来生成 APK+OBB 的选项，但在构建 AAB 时它的作用变成了启用 Play Asset Delivery。我第一次看到这个设置时也很困惑，实测后发现确实如此。

配置步骤：

1. 打开 Build Settings（File > Build Settings）
2. 选择 Android 平台
3. 勾选 "Build App Bundle (Google Play)"
4. 打开 Player Settings（Edit > Project Settings > Player）
5. 找到 Android 平台的 Publish Settings
6. 勾选最底部的 "Split Application Binary"

3.2 常见配置错误及解决方案

在实际项目中，我遇到过几个典型的配置问题：

问题1：勾选了 Build App Bundle 但忘记开启 Split Application Binary，结果生成的 AAB 文件无法处理大资源包。

解决方案：两个选项必须同时启用，缺一不可。

问题2：使用旧版 Unity 打包时遇到 "initial install would exceed the maximum size of 150MB" 错误。

解决方案：升级 Unity 到支持版本，或者使用 Addressables + Play Asset Delivery 方案（这个我们会在后续文章详细介绍）。

问题3：构建过程卡住不动，特别是使用非英语系统时。

解决方案：这是一个已知的 Unity 构建系统问题，临时方案是将系统显示语言切换为英语，或者升级到最新 Unity 版本。

4. 处理超过 150MB 的资源包

4.1 150MB 限制的实质

很多开发者第一次接触 AAB 时都会困惑：为什么会有 150MB 的限制？其实这个限制指的是"初始安装大小"，即用户首次下载时必须安装的核心内容体积。超过这个限制的部分，必须通过 Play Asset Delivery (PAD) 来分发。

在实际项目中，我们的游戏资源包有 1.2GB，通过合理配置，初始安装包控制在 120MB 左右，其余资源在玩家进入游戏后按需下载。

4.2 三种资源分发模式

Play Asset Delivery 提供了三种资源分发策略：

1. Install-time：随应用安装时下载，适合必须的启动资源
2. Fast-follow：应用安装后立即后台下载，适合首屏后需要的资源
3. On-demand：运行时按需下载，适合非必要内容

配置示例（在 Unity 2021 LTS 中）：

// 创建资产包配置 var assetPackConfig = new AssetPackConfig(); // 添加install-time资源包 assetPackConfig.AddAssetBundle("essential_assets", AssetPackDeliveryMode.InstallTime); // 添加fast-follow资源包 assetPackConfig.AddAssetBundle("level_1_assets", AssetPackDeliveryMode.FastFollow); // 应用配置 AssetPackConfigSerializer.SaveConfig(assetPackConfig);

4.3 实际项目中的最佳实践

根据我们团队的经验，处理大资源包时要注意：

1. 合理划分资源包：不要把所有资源打成一个包，按场景/功能模块拆分
2. 控制单个包大小：Fast-follow 包最好控制在 500MB 以内
3. 提供下载进度反馈：特别是对于 fast-follow 包，要有清晰的进度提示
4. 处理下载失败情况：网络环境差的用户可能需要多次重试

一个实用的技巧：使用 Unity 的 Addressables 系统配合 Play Asset Delivery，可以更灵活地管理资源。我们会在本系列后续文章中详细介绍这种方案的具体实现。

5. 构建与调试技巧

5.1 加速构建过程

构建 AAB 比构建 APK 更耗时，特别是大型项目。我们总结了几条加速技巧：

1. 使用增量构建：只重新构建发生变化的资源
2. 关闭不必要的构建后处理：如不必要的贴图压缩
3. 优化脚本编译：合理使用程序集定义文件
4. 使用性能更强的构建机器：特别是 CPU 和 SSD 要够快

5.2 本地测试 AAB

虽然 AAB 不能直接安装到设备上，但可以通过 bundletool 转换为可测试的 APKS 文件：

java -jar bundletool.jar build-apks --bundle=app.aab --output=app.apks java -jar bundletool.jar install-apks --apks=app.apks

5.3 常见错误排查

错误1："Could not determine the dependencies of task"

这通常是 Android SDK 许可问题，解决方案：

1. 打开 Android Studio 的 SDK Manager
2. 接受所有未接受的许可
3. 确保安装了所需的 SDK 平台工具

错误2：构建卡在 "Building APK" 阶段

尝试以下步骤：

1. 删除 Library/Bee 文件夹
2. 重启 Unity
3. 确保磁盘空间充足

错误3：上传到 Google Play 后报资源包过大

检查是否：

1. 正确配置了 Play Asset Delivery
2. 初始安装包控制在 150MB 以内
3. 使用了正确的资源分发模式

6. 从 APK 迁移到 AAB 的实战经验

去年我们团队将一个上线两年的游戏从 APK+OBB 迁移到 AAB，整个过程花了约三周时间。以下是关键经验：

1. 资源重组：将原来放在 StreamingAssets 的资源重新组织，划分为 install-time、fast-follow 和 on-demand 三类
2. 加载逻辑改造：原来的 WWW.LoadFromCacheOrDownload 需要替换为 Play Asset Delivery 的 API
3. 测试方案调整：建立新的测试流程，特别是针对资源下载和更新的测试用例
4. 监控指标新增：增加了资源下载成功率、下载时长等新的监控维度

迁移后最明显的变化是用户留存率提升了 8%，特别是存储空间有限的低端设备用户。同时，Google Play 的后台数据显示，我们的应用评分平均提高了 0.3 分，很多用户特别提到了"安装更快"、"占用空间更小"等改进。

对于正在考虑迁移的团队，我的建议是：

1. 预留足够的测试时间，特别是各种网络环境下的测试
2. 逐步迁移，可以先从新版本开始，保持老版本 APK 的更新
3. 做好数据监控，及时发现和解决可能出现的问题