3、构建可发布的APK/AAB：Android App Bundle (AAB) 介绍、使用Android Studio生成签名AAB、多维度构建配置
好，咱们进入第三章。这一章聊的是打包发布前的最后一步——构建可发布的产物。说白了，就是把你写的代码变成能上架Google Play的安装包。
我记得刚入行那会儿，大家还都在用APK。后来Google推了AAB，我一开始还挺抗拒的，觉得多此一举。直到有一次我负责的一个应用包体超过了150MB，APK上传直接被Google Play拒了……嗯，从那以后我就老老实实研究AAB了。
3.1 Android App Bundle (AAB) 介绍
AAB，全称Android App Bundle，是Google在2018年推出的官方发布格式。它和APK最大的区别是什么？
APK是一个“一刀切”的包——里面包含了所有设备的资源、代码、库。不管你的手机是x86还是ARM，是中文还是英文，APK里全都有。而AAB呢？它更像是一个“原材料包”，你把它上传到Google Play，Play会根据用户的设备配置，动态生成最合适的APK。
举个例子：
- 你的应用支持中文和英文。AAB里两种语言资源都有。
- 用户A的手机是中文系统，Google Play只把中文资源打包进APK给他。
- 用户B是英文系统，那就只给英文资源。
这样做的好处很明显——用户下载的APK更小，安装更快。我在项目中实测过，一个原本80MB的APK，通过AAB分发后，用户实际下载的包体只有40MB左右。省了一半流量，用户留存率都高了一些。
核心要点：从2021年8月起，Google Play要求所有新应用必须使用AAB格式发布。APK只能用于内部测试或侧载安装。
3.2 使用Android Studio生成签名AAB
生成签名AAB，说白了就是给你的安装包打上“身份证”。没有签名的包，Google Play是不认的。
我个人习惯用Android Studio的图形界面来做，因为直观、不容易出错。步骤如下：
- 在Android Studio中，点击菜单栏 Build → Generate Signed Bundle / APK。
- 弹窗里选择 Android App Bundle，然后点Next。
- 这里会让你选择签名文件。如果你之前没有创建过，点 Create new 新建一个。
- 填写签名信息：Key store path（存储路径）、Password（密码）、Key alias（别名）、Key password（密钥密码）。
- 填写证书信息：至少填一个，比如你的名字或公司名。
- 选好签名文件后，点Next，选择 release 构建变体。
- 勾选 Signature Versions：建议两个都勾上（V1和V2）。V1是旧版签名，V2是新版，兼容性更好。
- 点Finish，等几秒钟，你的.aab文件就生成好了。
小提示：签名文件一定要备份好！我曾经有个同事把签名文件弄丢了，结果应用更新时只能换签名，导致用户需要卸载旧版再安装新版，流失了一大波用户。建议把.jks文件放到Git仓库的私有分支里，或者用密码管理器保存。
如果你喜欢命令行，也可以用 gradle 任务来生成：
./gradlew bundleRelease这个命令会在 app/build/outputs/bundle/release/ 目录下生成 app-release.aab 文件。前提是你已经在 build.gradle 里配置好了签名信息。
3.3 多维度构建配置
多维度构建配置，说白了就是让你能“一套代码，打出不同版本的包”。比如：
- 免费版 vs 付费版
- 国内版 vs 海外版
- 开发环境 vs 生产环境
Android Studio通过 Build Variants 来实现这个功能。它由两个维度组成：Build Type 和 Product Flavor。
3.4 Build Type（构建类型）
默认情况下，Android项目有两个Build Type：
- debug：用于开发调试，默认不签名，可调试。
- release：用于发布，需要签名，不可调试。
你可以自定义更多，比如：
android {
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
debug {
applicationIdSuffix ".debug"
versionNameSuffix "-debug"
}
staging {
initWith debug
applicationIdSuffix ".staging"
versionNameSuffix "-staging"
}
}
}这里我加了一个 staging 类型，用于预发布环境。注意 initWith debug 表示继承debug的配置，然后覆盖部分属性。
3.5 Product Flavor（产品风味）
Product Flavor 用来区分不同版本的应用。比如免费版和付费版：
android {
flavorDimensions "version"
productFlavors {
free {
dimension "version"
applicationId "com.example.app.free"
versionName "1.0-free"
}
paid {
dimension "version"
applicationId "com.example.app.paid"
versionName "1.0-paid"
}
}
}配置好之后，Android Studio的Build Variants面板里就会出现 freeDebug、freeRelease、paidDebug、paidRelease 四个变体。你可以根据需要选择打包哪个。
注意：Product Flavor 和 Build Type 是组合关系，不是覆盖关系。比如 free 和 release 组合成 freeRelease。如果某个配置在两个维度里都有定义，Build Type 的优先级更高。
3.6 多维度组合的实际应用
我在项目中遇到过这样一个场景：需要同时区分“免费版/付费版”和“国内版/海外版”。这时候就需要两个维度：
android {
flavorDimensions "version", "region"
productFlavors {
free {
dimension "version"
}
paid {
dimension "version"
}
china {
dimension "region"
}
global {
dimension "region"
}
}
}这样组合出来的变体就有：freeChinaDebug、freeChinaRelease、freeGlobalDebug……一共8个。每个变体可以有自己的资源文件、代码、依赖库。
比如，你可以在 src/freeChina/ 目录下放国内免费版的专属资源，在 src/paidGlobal/ 下放海外付费版的资源。Gradle会自动帮你合并。
总结一下：多维度构建配置的核心就是“一次配置，多包输出”。它让你的发布流程更灵活，也更容易维护。我个人建议，哪怕你的应用现在只有一个版本，也提前把 flavorDimensions 和 productFlavors 搭好。因为一旦应用做大了，再回头重构构建配置，那叫一个痛苦。
好了，这一章的内容就到这里。下一章我们会聊如何把AAB上传到Google Play Console，以及那些容易踩的坑。到时候见。