3. App Bundle vs APK：四大核心差异

3.1 核心概念定义

APK (Android Package Kit) 是 Android 系统的标准安装包格式，它将应用的所有资源、代码和原生库打包成一个单一文件。用户下载的 APK 通常包含所有屏幕密度、CPU 架构和语言资源的全部副本。

App Bundle (AAB, Android App Bundle) 是 Google Play 在 2018 年推出的官方发布格式，后缀为 .aab。它不直接安装到设备，而是作为“分发包”上传到 Google Play 商店；商店根据用户设备的屏幕密度、CPU 架构和语言，只分发所需的部分（即“动态交付”）。

两者最本质的区别：APK 是“全量打包”，AAB 是“按需分发”。

3.2 原理图：构建与分发流程对比

下面对比 APK 和 App Bundle 从构建到用户安装的完整路径。左半部分展示传统 APK 构建与分发，右半部分展示 AAB 流程。

3.3 四大维度详细对比

维度	APK	App Bundle (AAB)
体积优势	固定全量包；包含所有屏幕密度（mdpi/hdpi/xhdpi/xxhdpi/xxxhdpi）、所有 CPU 架构（armeabi-v7a/arm64-v8a/x86/x86_64）和所有语言资源。用户会下载大量无用资源。	按设备属性切片分发；仅包含当前设备所需的屏幕密度资源（如 arm64-v8a 设备只下载 arm64-v8a 的原生库），语言只下载系统语言对应的部分。平均体积减少 35%~50%。
构建方式差异	Gradle 构建产出 APK；开发者可直接使用 ./gradlew assembleRelease 生成。APK 可直接安装到任何设备（侧载或发布）。	Gradle 构建产出 AAB；需要使用 Android Gradle Plugin 3.2+，并启用 bundle 任务（./gradlew bundleRelease）。AAB 不能直接安装，必须通过 Google Play 或使用 bundletool 转换为 APK 后安装。
分发路径不同	可通过商店、网页、邮件、文件共享等多种渠道分发。任何第三方应用商店均支持 APK 分发。	官方仅支持通过 Google Play 分发（是 Google Play 的独占格式）。其他商店需要自行处理切片逻辑或直接使用 APK。开发者可使用 bundletool 生成本地测试 APK，但非主流分发方式。
用户体验差异	下载体积大，安装前即可确认已有完整应用；安装速度取决于设备 I/O，安装后首次启动通常无需额外下载（除非应用内置动态下载逻辑）。	下载体积小，首次安装快；但部分功能可能采用“按需加载”（Play Feature Delivery / Play Asset Delivery），首次使用某些功能可能需要额外下载模块。对用户而言，应用下载速度显著提升，但存在功能访问延迟的可能。

3.4 生活化类比

全菜单外卖 vs 定制点餐

想象你走进一家中餐厅：

• APK 像是一份“全菜单豪华套餐”：餐厅把所有菜品（川菜、粤菜、湘菜、甜点、饮品）都打包在一个大食盒里送给你，其中 80% 你根本不想吃 ── 但你得为整个食盒付钱并拎回家。
• AAB 像是“按需点餐”：你只需要告诉餐厅你的口味偏好（“米饭、不要辣、配例汤”），厨房只为你做这几样，用最小盒子包装配送 ── 你吃到的每一口都是你想要的。

类比到 App：用户设备上的屏幕密度、CPU 架构、语言偏好就相当于“口味偏好”，AAB 只配送用户真正需要的资源。

3.5 常见误区与关键区别

• 关键区别 1： APK 是最终安装包，AAB 是分发中间包。AAB 不能直接安装到设备。
• 关键区别 2： APK 可以侧载（从任意渠道安装），AAB 依赖 Google Play 商店的切片服务（Google Play Dynamic Delivery）。
• 关键区别 3： APK 的构建任务为 assemble*，AAB 的构建任务为 bundle*。二者互不兼容。

3.6 自测练习题

题 1（概念理解）
以下关于 APK 和 AAB 的说法，正确的是？

1. App Bundle 可以直接安装到 Android 设备上。
2. AAB 构建速度比 APK 构建速度更快，因为它跳过了资源合并步骤。
3. 使用 AAB 后，用户永远不会下载不需要的屏幕密度资源。
4. 以上都不对。

答案：c。AAB 通过 Google Play 的切片机制确保用户只下载匹配其设备屏幕密度的资源。a 错，AAB 不可直接安装；b 错，AAB 构建过程与 APK 类似，甚至更复杂。

题 2（实际应用）
你的应用支持 5 种屏幕密度（ldpi到xxxhdpi）、3 种 CPU 架构（armv7/arm64/x86_64）和 10 种语言。若不使用 App Bundle，传统 APK 中大约有多少比例的资源可能是冗余的（假设用户群均匀分布）？

1. 约 20%
2. 约 50%
3. 约 87%
4. 约 95%

答案：c。假设每种属性权重相同：5种密度中只有1种被使用（20%），3种架构中只有1种（33%），10种语言中只有1种（10%）。有效资源比例 = 20% × 33% × 10% = 0.66%，冗余 ≈ 99.34%，但实际应用中一些资源（如通用代码）无法切片，因此实际冗余通常在 80%~90% 之间。

3.7 实际应用边界

• 适用场景：仅在 Google Play 商店分发的应用。如果你的应用同时上架华为、小米、三星等第三方商店，这些商店可能不支持 AAB 分发，你需要为它们单独构建 APK。
• 测试限制：本地测试 AAB 时必须使用 bundletool build-apks 生成 APK 集，再用 bundletool install-apks 安装。该流程比直接安装 APK 复杂，且不能完全模拟商店的按需分发行为。
• 按需模块（Dynamic Feature）：AAB 支持 Play Feature Delivery（按需交付模块），但要求应用必须遵循模块化架构，并在 Play Console 中配置分发条件。该功能适用于大型应用（如游戏、办公套件），对中小型应用收益不大。
• 回退机制：如果用户从非 Google Play 渠道获取应用（例如通过网页下载），则必须提供 APK。所以即使启用了 AAB，仍需保留 APK 构建流程用于侧载。