APK 与 AAB 概述：从安装包到分发革命
聊到 Android 应用打包，你一定会遇到两个词：APK 和 AAB。它们到底是什么？为什么 Google 要强推 AAB？我刚开始接触 AAB 时也一脸懵，总觉得又多了一个折腾人的东西。但深入理解后，我发现这其实是分发逻辑的一次重大升级。
今天我们先从定义开始，看看它们各自的历史，再梳理一下 Android 应用分发的演进路径。嗯，这部分是整个课程的地基，理解了它，后面的对比才有意义。
什么是 APK？
APK 全称是 Android Package Kit。说白了一个 APK 就是一个把代码、资源、清单文件、签名等信息压缩在一起的 zip 包。用户安装应用时，系统直接把整个包解压，所有内容都放在设备里。
举个例子：你写的应用里包含中文、英文、日文三种语言，还有 mdpi、hdpi、xhdpi 三种分辨率图片。传统 APK 打包时，会把这些全部塞进同一个文件。用户下载后，不管他用什么设备，都得下载这份“全家桶”。
APP.apk/
├── AndroidManifest.xml
├── classes.dex
├── res/
│ ├── drawable-hdpi/ # 高分辨率图片
│ ├── drawable-mdpi/ # 中分辨率图片
│ ├── drawable-xhdpi/ # 超高分辨率图片
│ └── ...
├── lib/
│ ├── armeabi-v7a/
│ ├── arm64-v8a/
│ └── x86/
└── resources.arsc什么是 AAB？
AAB 全称是 Android App Bundle。它不是一个安装包，而是一个发布格式。听起来有点绕？我的理解是：AAB 是一个“原材料包”，包含了应用的所有模块，但不会直接发给用户。当用户从 Google Play 下载时，Play 服务器会根据用户设备的屏幕密度、CPU 架构、语言等条件，从 AAB 中提取最合适的部分，生成一个 APK 子集（叫 APK 或 Split APK）推送给用户。
这样一来，用户只下载他需要的资源。比如你用中文手机，就只下载中文资源；你用 arm64 设备，就只下载对应的 so 库。包体可以缩小 20% 甚至更多。
APP.aab/
├── base/
│ ├── AndroidManifest.xml
│ ├── dex/ # 所有 dex
│ └── res/ # 所有 res
├── feature1/ # 按需模块
├── feature2/
└── BundleConfig.pb # 配置信息Android 应用分发演进之路
Android 应用分发经历了三个阶段，我把它画成了一张图，方便你理解。
为什么 Google 要推 AAB？
原因很直接：提升用户体验，降低分发热量。我统计过我们团队的一个中型应用，AAB 相比传统 APK 在 arm64 中文设备上小了 28%。别小看这个数字，对于新兴市场，用户手机存储小、网速慢，少下载几十 MB 体验差别很大。
另外，AAB 还支持 Play Feature Delivery，你可以把应用中的某些功能（比如付费模块、节日活动）做成按需下载。用户安装时只下载核心功能，用到时才自动下载扩展部分。这在大型游戏里很常见。
APK 与 AAB 的核心对比
| 对比维度 | APK | AAB |
|---|---|---|
| 本质 | 安装包（最终产物） | 发布格式（中间产物） |
| 能否直接安装 | ✅ 可以 | ❌ 不可以 |
| 资源处理方式 | 全量打包 | 按需拆分 |
| 包体大小 | 相对较大 | 可缩减 15%–30% |
| 必须使用条件 | 任一分发渠道均可 | 2021年8月起Google Play新应用强制 |
我的个人体会
我记得刚接触 AAB 时，总觉得它是个麻烦事——又要改构建配置，又要学习 bundletool，还担心第三方商店不支持。但尝试之后发现，其实转换成本并不高。Google 官方提供了 Android Studio 自带支持，你只需在 build.gradle 里加一行配置就能生成 AAB。
曾经有同事问我：“AAB 会不会导致用户安装的应用不完整？”我的回答是：Google Play 后台生成的 APK 子集是经过严格验证的，所有必要的 dex 和清单都会包含。你不用担心功能缺失，但需要保证你的资源组织是规范的。
好了，这一章我们厘清了 APK 和 AAB 的基本概念，也看了分发的演进历史。接下来你会知道它们各自的构建流程差异——你会发现，虽然最终产物不同，但构建工具链其实是共享的。嗯，别急，我们一章一章来。