4、Android App Bundle：AAB格式优势、生成AAB文件、Play Console上传要求
好，咱们进入第四章。这一章聊的是 Android App Bundle，也就是 .aab 格式。
说实话，我刚开始接触 AAB 的时候，心里是有点抵触的。毕竟 APK 用了那么多年，突然要换格式，总觉得麻烦。但后来真正用上了，才发现——嗯，真香。
4.1 为什么 Google 要推 AAB？
先说说 AAB 到底解决了什么问题。
你想想看，一个 APK 文件里，其实塞了很多你根本用不到的东西。比如你用的是中文手机，但 APK 里还带着英文、日文、法文的资源。再比如你的手机是 xhdpi 屏幕，但包里还装着 mdpi、hdpi、xxhdpi 的图片。
说白了，APK 是「一刀切」的方案。不管用户是谁，我都给你一整包。
而 AAB 的思路完全不同。它像一个「半成品」——你上传到 Google Play，Google 会根据用户的设备信息，动态生成一个最精简的 APK 给用户下载。
AAB 的核心优势：
- 更小的安装包：用户只下载自己需要的部分，体积平均减少 15%-20%
- 模块化分发：支持按需加载模块，比如游戏里的某些关卡可以后续下载
- Play Feature Delivery：可以把功能拆成模块，用户用到时才下载
- Play Asset Delivery：针对大型资源文件（比如 3D 模型、高清贴图）的优化方案
我在项目中遇到过最典型的案例：一个海外社交 App，之前 APK 有 80MB。改成 AAB 后，大部分用户下载的 APK 只有 55MB 左右。转化率直接提升了 3%。
4.2 生成 AAB 文件
生成 AAB 其实很简单。你不需要改任何代码，只需要在打包时换个命令。
4.2.1 使用 Flutter 命令
我个人习惯直接用命令行。干净利落。
flutter build appbundle这条命令会在 build/app/outputs/bundle/release/ 目录下生成一个 app-release.aab 文件。
如果你需要指定不同的构建变体，比如 debug 或 profile，可以加参数：
flutter build appbundle --debug
flutter build appbundle --profile不过说实话，我几乎只用 release 模式。debug 的 AAB 没什么实际意义。
4.2.2 使用 Android Studio
如果你更习惯图形界面，Android Studio 也支持：
- 打开项目，点击菜单栏 Build → Build Bundle(s) / APK(s) → Build Bundle(s)
- 等待编译完成，右下角会弹出提示
- 点击 locate 就能找到生成的 .aab 文件
嗯，这里要注意：Android Studio 默认生成的是 release 版本。如果你需要签名，记得在 build.gradle 里配置好 signingConfigs。
4.2.3 关于签名
AAB 和 APK 一样，也需要签名。而且签名方式完全一样。
flutter build appbundle --release --sign-key-store=/path/to/keystore.jks或者你可以在 android/app/build.gradle 里配置：
android {
...
signingConfigs {
release {
storeFile file("your_keystore.jks")
storePassword "your_password"
keyAlias "your_alias"
keyPassword "your_key_password"
}
}
buildTypes {
release {
signingConfig signingConfigs.release
}
}
}警告：千万不要把 keystore 文件提交到 Git 仓库！我见过有人把密码写在代码里然后上传到 GitHub，结果被机器人扫描到，直接盗用签名去发布恶意版本。建议把密码放在 key.properties 文件中，并添加到 .gitignore。
4.3 Play Console 上传要求
生成 AAB 只是第一步。上传到 Google Play Console 时，有几个坑你得提前知道。
4.3.1 必须使用 Play App Signing
从 2021 年 8 月开始，Google Play 要求所有新应用必须使用 Play App Signing。说白了，你的签名密钥要交给 Google 保管。
流程是这样的：
- 你生成一个 上传密钥（upload key），用来签名 AAB
- Google 用它的 应用签名密钥（app signing key）重新签名，生成最终分发的 APK
- 如果你丢了上传密钥，可以找 Google 重置。但如果你丢了应用签名密钥……嗯，那就彻底完蛋了
我的建议：一定要把上传密钥的 keystore 文件备份到至少两个不同的地方。我个人的做法是：本地存一份，加密后放云盘一份，再刻一张光盘放保险柜。听起来夸张？等你真丢了密钥就知道有多痛苦了。
4.3.2 AAB 文件大小限制
Google Play 对 AAB 有大小限制：
| 项目 | 限制 |
|---|---|
| AAB 文件总大小 | 不超过 500MB |
| 单个模块大小 | 不超过 150MB |
| Play Asset Delivery 资源包 | 每个包不超过 2GB |
如果你超过了 500MB，就得考虑拆分模块了。我之前做过一个 AR 应用，模型文件特别大，AAB 直接干到了 600MB。后来把 3D 模型拆成 Play Asset Delivery 按需下载，才通过审核。
4.3.3 版本号要求
每次上传的 AAB，versionCode 必须比之前的高。这个在 pubspec.yaml 里配置：
version: 2.0.0+3其中 +3 就是 versionCode。每次发布新版本，记得加 1。
如果你忘了改版本号，Play Console 会直接报错，不会让你上传。嗯，我犯过这个错，当时还以为是网络问题，折腾了半小时才发现是版本号没改。
4.3.4 支持的架构
Google Play 要求 AAB 必须包含至少一种原生架构。对于 Flutter 项目，默认会打包 armeabi-v7a、arm64-v8a 和 x86_64。
如果你想精简体积，可以在 build.gradle 里配置：
android {
...
defaultConfig {
ndk {
abiFilters "armeabi-v7a", "arm64-v8a"
}
}
}我个人建议保留 arm64-v8a 和 armeabi-v7a。x86_64 的模拟器用户很少，可以去掉。但要注意，如果你去掉 x86_64，某些模拟器可能跑不起来。
4.4 验证 AAB 文件
上传之前，最好先验证一下 AAB 文件是否正常。Google 提供了一个工具叫 bundletool。
安装方式：
brew install bundletool # macOS
scoop install bundletool # Windows验证命令：
bundletool validate --bundle app-release.aab如果输出 Bundle 'app-release.aab' is valid，那就没问题了。
你还可以用 bundletool 生成一个测试用的 APK，看看最终用户会下载到什么：
bundletool build-apks --bundle=app-release.aab --output=app.apks
bundletool install-apks --apks=app.apks这样就能在本地模拟 Google Play 的分发逻辑，提前发现资源缺失或配置错误的问题。
总结一下：
- AAB 比 APK 更智能，用户下载体积更小
- 生成命令很简单：
flutter build appbundle - 上传前必须配置 Play App Signing
- 注意版本号、文件大小、架构支持
- 用 bundletool 验证一下，避免踩坑
下一章我们会聊持续集成的基础流程。到时候我会分享怎么用 GitHub Actions 自动打包 AAB 并上传到 Play Console。嗯，那个才是真正的效率提升。