📚 课程目录第2章 Android App Bundle基础介绍

2、Android App Bundle基础介绍：什么是AAB、它的组成结构与如何生成

好，咱们正式开始聊 App Bundle。说实话，第一次接触这东西的时候，我内心是抗拒的。你想啊，APK 用了这么多年，突然要换个新格式，谁不嘀咕？但真正上手之后，我只能说——真香。

现在很多团队还在纠结要不要切 AAB，我的建议是：别犹豫了，尤其是要做灰度发布的团队。为什么？因为 AAB 天生就是为动态分发设计的。下面我带你从头捋一遍。

2.1 到底什么是 App Bundle？

App Bundle，后缀是 .aab，不是 APK。它不是最终安装包，而是 Google Play 用来生成优化 APK 的“中间产物”。说白了，你把 AAB 上传到 Play Console，Google 服务器会根据用户的设备配置（屏幕密度、CPU 架构、语言等）动态生成最合适的 APK。

关键区别：

APK：最终安装文件，包含所有资源。
AAB：发布文件，只包含原始代码和资源，不包含为各设备优化的副本。

我一开始也觉得这不就是换了个壳吗？直到我看见一个 100MB 的 APK 在 AAB 模式下变成 30MB 的下载包，客户体验直接拉满。灰度发布时，包体越小，用户下载意愿越高，这是铁律。

2.2 AAB 的组成结构

AAB 本质上是一个 ZIP 包（你可以直接解压看看），里面分三个模块：base、feature 和 asset。理解这三个东西，你就掌握了 AAB 的精髓。

模块	作用	是否必须	典型场景
base	应用的核心功能和基础资源	必须	启动页、主界面、核心逻辑
feature	按需加载的功能模块	可选	拍照功能、AR 模块、付费插件
asset	大型资源文件包	可选	游戏贴图、高清视频、离线地图

base 模块

这是 AAB 的基石。任何设备必须安装 base，否则应用跑不起来。你在 build.gradle 里写的所有代码、资源、配置，默认都进 base。灰度发布时，你改动的基础逻辑必须放在这里，但要注意：base 越小，用户首次下载越快。

feature 模块

这个就灵活了。你可以把一些非核心功能塞进 feature 模块，用户用到时才下载。我在项目里就处理过这种情况：一个拍照增强功能，只有 30% 的用户会使用。于是把它做成 feature 模块，灰度期间只向白名单用户下发——完美控制流量。

我的经验：灰度发布时，把实验性功能放在 feature 模块里，可以做到按用户维度动态下发，而不用发新版。配合 Play Feature Delivery API，体验非常顺滑。

asset 模块

专门存放大型资源。比如游戏厂商会把高清贴图放在 asset 模块里，用户安装基础包后，可在 Wi-Fi 环境下手动下载这些资源。不占初始安装包大小，也不影响首次进入体验。

2.3 如何生成 AAB？

生成 AAB 不难，难的是正确配置。我见过很多人直接把 APK 打包方式改个后缀就完事——这肯定不行。下面说两种常用方式。

方式一：Android Studio 直接构建

从 Build 菜单选择 Build Bundle(s) / APK(s) → Build Bundle(s)。Gradle 会自动执行 bundleRelease。最终产物在 app/build/outputs/bundle/release/ 目录下。

嗯，这里要注意一点：默认生成的 AAB 是未签名的。上传到 Play Console 之前必须签名。你可以让 Gradle 自动签名，也可以在构建后通过 jarsigner 手动签。

方式二：命令行 + bundletool

这是 CI/CD 场景下的首选。先确保安装了 bundletool，然后执行：

// 构建 AAB
./gradlew bundleRelease

// 使用 bundletool 生成 APK（用于本地测试）
java -jar bundletool.jar build-apks \
  --bundle=app/build/outputs/bundle/release/app-release.aab \
  --output=app.apks \
  --ks=my-release-key.jks \
  --ks-pass=pass:your_password \
  --ks-key-alias=your_alias \
  --key-pass=pass:your_password

为什么要用 bundletool 生成 APK？我问你：你在灰度发布前需要测试吧？AAB 不能直接安装到手机上。通过 bundletool 生成的 APK 集合，你可以指定设备类型、分辨率、语言，模拟真实分发场景。

我曾经踩过的坑：本地测试时直接拿 bundletool 生成的通用 APK 安装，结果上了灰度发现部分机型的资源加载失败。后来才发现——测试时必须指定设备规格（通过 --connected-device 参数），否则 bundletool 默认生成的是“万能版”，起不到验证效果。

Gradle 配置要点

在 app/build.gradle 里，你需要启用 AAB 支持并配置签名。这里给个最小模板：

android {
    // ...
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
    signingConfigs {
        release {
            storeFile file("my-release-key.jks")
            storePassword "your_store_password"
            keyAlias "your_key_alias"
            keyPassword "your_key_password"
        }
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
    }
}

关于 bundle 里的三项配置，说白了就是决定要不要为不同语言、屏幕密度、CPU 架构生成独立 APK。我都建议设为 true，这是 AAB 的优势所在。灰度发布时，你只需控制单一 AAB 文件的上传，Play Store 会自动处理后续分发。

2.4 小结

App Bundle 不是替换 APK，而是替换你的发布流程。记住三个模块的职责：base 是根、feature 是枝干、asset 是果实。生成 AAB 很简单，但测试和灰度策略才是重头戏。后面我会详细讲怎么用 feature 模块做精细化的灰度控制——不过那是后话了。