什么是 Android App Bundle？
我第一次听到 App Bundle 这个概念时，心里想的是：这不就是又一种打包格式吗？后来深入了解才发现，我错了。它不仅仅是格式变化，更是一种发布理念的升级。
从“胖”APK 到智能分发
说白了，传统 APK 就像一个大礼包。你把所有资源、代码、语言包都塞进去。用户下载时，不管他用什么设备，都得完整下载这个大包。你想想看，这有多浪费？
之前我做的一个应用，光是为了适配不同屏幕密度，就塞了好几套图片资源。用户明明用的是 320dpi 的设备，却得把 xxhdpi 的资源也一起下载下来。安装包硬生生被撑到 60MB。
App Bundle 的核心思路很简单：把决定权交给 Google Play。你只管上传一种发布格式，Google Play 会自动为每台设备生成最合适的 APK。
关键认知： App Bundle 不是一个最终安装文件。它是一种发布格式。就像源代码一样，需要经过处理才能变成可执行文件。
与传统 APK 的核心区别
我习惯用对比表来理解新概念。下面这个表格，基本涵盖了它们的核心差异：
| 对比维度 | 传统 APK | Android App Bundle |
|---|---|---|
| 文件格式 | .apk（已签名、已对齐） | .aab（未签名、未对齐） |
| 分发方式 | 用户下载完整 APK | Google Play 按需组装 APK |
| 资源管理 | 所有资源打包在一个文件中 | 资源拆分为多个模块 |
| 用户受众 | 所有用户下载同一版本 | 每台设备获得定制版 |
| 动态加载 | 需要自行实现功能模块下载 | 原生支持动态功能模块 |
| 构建时间 | 每次完整构建较慢 | 增量构建更快 |
为什么会这样？因为 App Bundle 把 APK 分成了两种角色：基础 APK 和 配置 APK。基础 APK 包含核心代码，用户必须安装。配置 APK 则按需下载，比如针对 mdpi、hdpi、xhdpi 的图片资源，只下发对应部分。
App Bundle 的工作原理
嗯，这里要注意。App Bundle 不是魔法。它背后有一套清晰的流程：
- 构建阶段： 你用 Android Studio 或命令行打包出 .aab 文件。这个文件包含了所有模块的原始资源。
- 上传阶段： 把 .aab 上传到 Google Play Console。此时它还没签名，需要 Google Play 帮你完成签名。
- 分发阶段： 用户点击安装时，Google Play 服务器根据设备信息（屏幕密度、语言、CPU 架构）从 .aab 中提取对应资源，组装成一个精简的 APK。
- 安装阶段： 用户安装的是这个定制后的 APK，而非原始的 .aab 文件。
我个人觉得，最妙的一点是：你作为开发者，完全不需要关心用户设备的具体参数。一切交给 Play 动态分发。你只管确保 .aab 结构正确即可。
为什么要迁移到 App Bundle？
说实话，我一开始也犹豫过。毕竟迁移总会带来一些风险。但真正上手后，好处很明显：
- 应用大小平均减少 20% 以上。 我经历过最夸张的一次，一个 120MB 的 APK 最终降到 45MB。用户下载体验好了不少。
- 支持动态功能模块。 你想想看，有些功能只有 10% 的用户会用。传统做法要么全部打包，要么自己写一套下载逻辑。App Bundle 直接内置了这套机制。
- Play 签名更安全。 签名密钥由 Google Play 保管，你不需要再操心密钥泄露问题。
- 增量构建更快。 每次改完代码，只编译改动部分。开发效率提升明显。
一个小建议： 如果项目正在从零开始，直接用 App Bundle。如果是老项目迁移，建议先从模块化拆分做起，再切换到 .aab 格式。
迁移时要注意什么？
嗯，这里有几个坑，我踩过：
我曾经犯过的错误：
- 忘记在 Google Play Console 开启 Play App Signing。后果是上传 .aab 总是失败。
- 使用了一些第三方加固工具，但没检查是否支持 .aab 格式。结果构建通过了，但应用闪退。
- 动态功能模块的清单文件配置错了依赖关系。用户安装基础 APK 后，功能模块怎么都加载不上。
说白了，App Bundle 是 Google 推动的未来方向。2021 年开始，新应用必须使用 .aab 格式上传。你现在接触它，不是跟风，而是适应必然趋势。
一句话总结： App Bundle 让你只做一次构建，Google Play 帮你做最精细化的分发。用户省流量，你省时间。