解读

面试官问“区别”时，真正想听的是：

1. 国内开发者日常交付的“包”到底长什么样；
2. 两种格式在构建、签名、分发、安装、动态化、合规审核、渠道统计、崩溃回溯等环节带来的连锁差异；
3. 候选人能否把“Google 官方推荐 AAB”与“国内多渠道必须 APK”这两套并行现实讲清楚，并给出可落地的工程策略。
   回答若只停留在“AAB 是上传格式、APK 是安装格式”会被认为背概念；必须结合国内 OEM 商店、企业分发、合规加固、热修、崩溃符号等真实痛点展开。

知识点

1. 构建产物：

   • APK：单次构建即产出完整 installable Android Package，内含所有 density、abi、language 资源。
   • AAB：构建产物为 *.aab 压缩包（ZIP 格式），内部按模块（base + feature1、2…）和 split 维度（density/abi/language）组织，不能直接安装。

2. 签名时机：

   • APK：本地 Gradle 构建后即可完成 v1/v2/v3 签名，签名块写入 APK。
   • AAB：本地仅进行“伪签名”（签名块位于 aab 的 META-INF 但仅供上传校验），真正对 split-apks 的签名由 Google Play 在云端重新执行，开发者私钥托管于 Google Play App Signing。

3. 分发与安装：

   • APK：开发者直接交付给用户或渠道，PackageInstaller 一次性安装完整包。
   • AAB：仅允许上传到 Google Play（国内华为 AppGallery 亦跟进支持），Play 按设备生成最小化 split-apk 集合（base-master.apk + config.xxhdpi.apk + config.arm64_v8a.apk…）后下发，安装时采用 Session-based 多 apk 原子安装。

4. 动态交付与条件特性：

   • APK：要实现“按需模块”必须自研插件化或 React-Native 动态下发，兼容性问题大。
   • AAB：官方提供 Dynamic Delivery，Play Feature Delivery / Play Asset Delivery，支持“按需下载”“按条件下载”“快速跟进”，无需额外插件框架。

5. 体积收益：

   • 国内实测中等规模 App（arm64+armeabi-v7a、xxhdpi+hdpi、en+zh）转 AAB 后，Google Play 下载体积平均下降 15–30%；APK 则无法自动瘦身。

6. 国内渠道现实：

   • 主流商店（应用宝、小米、OPPO、vivo、华为）目前仍只接受 APK；
   • 企业 MDM、政企专网、地铁 Wi-Fi 缓存、运营商彩信推送等场景均依赖 APK；
   • 因此国内项目普遍采用“aab for Google Play + apk for 国内多渠道”双轨构建，Gradle 插件层通过 bundle{ } 与 flavor + apk 双产物并行输出。

7. 加固与合规：

   • 国内加固厂商（腾讯乐固、360、爱加密）对 AAB 支持尚不完整，多数要求上传 APK；
   • 工信部备案、公安三所检测、小程序跳转校验均基于 APK 的 MD5/SHA-256，需保留对齐与签名信息。

8. 调试与回溯：

   • APK 崩溃堆栈与 mapping.txt 直接对应；
   • AAB 经 Google Play 重签名后 versionCode 可能递增，崩溃报告需结合 Play Console 提供的“Generated APK”重新对齐符号，符号化脚本需额外适配。

9. 构建脚本差异：

   • 任务名称：assembleRelease vs bundleRelease；
   • 混淆映射：R8 在两者中均生效，但 AAB 会额外输出 proguard-mapping 用于 Play 重打包；
   • 资源优化：AAB 强制启用 “android.enableResourceOptimizations=true” 以支持资源拆分。

10. 版本升级策略：

    • APK：开发者完全掌控签名证书，可随时更换渠道重新签名；
    • AAB：一旦启用 Play App Signing，上传密钥与签名证书分离，证书丢失需通过“密钥升级”流程，用户端需接受双签名校验，回滚代价高。

答案

APK 是可直接安装的完整包，构建后即含所有 abi、density、language 资源；AAB 是上传格式，内部按模块与维度拆分，仅用于 Google Play（国内华为已跟进），云端再针对具体设备生成最小化 split-apks 下发。
核心差异体现在四点：

1. 体积：AAB 借助 Play 的 Dynamic Delivery 可省 15–30% 下载量，APK 无法自动瘦身。
2. 签名：APK 本地一次完成，开发者完全掌握；AAB 本地仅伪签名，真正签名由 Play 在云端重做，私钥需托管给 Google。
3. 动态化：AAB 原生支持按需模块与资源，APK 需自研插件化。
4. 国内现实：所有主流渠道、政企分发、合规加固仍强制 APK，因此国内项目普遍“aab 出海 + apk 国内”双轨并行，构建脚本需同时输出 assembleRelease 与 bundleRelease 两套产物，并分别处理签名、对齐、渠道写入与加固流程。

拓展思考

1. 若公司明年要求国内渠道也接入“拆分安装”，你会如何改造构建流水线？（提示：调研华为 AppGallery Bundle、腾讯 App Bundle 插件，评估 split 安装兼容性、崩溃符号回捞、热修方案。）
2. Play 要求 2024 起新应用必须 AAB，但老板担心“证书托管给 Google 后失去控制权”，如何说服管理层？（准备密钥升级流程、双证书机制、上传密钥与签名证书分离的幻灯片，并给出应急回滚预案。）
3. 国内合规加固厂商尚未支持 AAB，若强行输出 aab 再让厂商转 apk，会出现哪些坑？（split 资源合并后体积回弹、重签名导致微信/支付宝指纹变化、渠道号写入位置失效、热修 tinker id 错乱。）