为什么 Google 推荐使用 AAB 而非 APK 进行发布？
解读
面试官问“为什么推荐 AAB”并不是想听“Google 强制”这种表面答案，而是考察候选人对国内多渠道生态、包体体积、动态交付、签名机制、合规风险以及后台自动化能力的综合理解。回答时要体现“国内开发者真实痛点+AAB 技术价值+落地经验”。
知识点
- 包体体积：AAB 通过 split-APK 机制按 ABI/语言/密度自动拆分，用户下载体积平均减少 15-20%，对国内 64 位升级、商店流量计费、用户转化有直接收益。
- 动态功能模块（Dynamic Feature Module）：国内直播、电商、教育类 App 常用“先下基础模块，用户进直播间再下解码器”，用 AAB 可把 so 库、模型文件做成条件分发，避免首次安装包超 200 MB 被商店拦截。
- 签名一致性：AAB 采用 Google 统一签名（Upload Key + App Signing Key），国内上架华为、OPPO、vivo 时，只要上传同一签名的 APK 派生包，即可保证指纹一致，避免“双签名”导致微信、支付宝 SDK 校验失败。
- 合规与自动化：AAB 在 Google Play 后台可自动做压缩、64 位剥离、合规 SDK 扫描，减少国内团队手动写 Gradle 脚本适配《工信部 164 号文》的隐性成本。
- 国内多渠道兼容：虽然国内商店暂不支持 AAB 直投，但 bundletool 可本地生成针对各商店的“伪拆分 APK”并自动对齐签名，CI 上一条命令即可产出多渠道包，比传统
assembleRelease + Python 多渠道写入更稳更快。 - 安全与回滚：App Signing Key 由 Google 硬件加密模块保管，即使 Upload Key 泄露也可一键轮换；国内团队以往把 release.jks 放 GitLab 导致泄漏的事件频发，AAB 机制天然降低密钥泄漏面。
- 未来演进：从 2023 年 8 月起，Play 强制 64 位、targetSdk 34、AIDL 沙盒，AAB 是唯一能在后台自动完成 64 位剥离并生成 32 位兼容包的官方方案，APK 手动维护将越来越重。
答案
“Google 推荐 AAB 的核心原因是‘以更小、更安全的包体，实现按需分发与自动化合规’。
第一，体积收益：AAB 通过 split-APK 按 ABI、密度、语言自动拆分，国内实测抖音 Lite 版下载体积减少 18%，直接提升商店转化率。
第二，动态模块：我们把直播礼物特效 so 与 ML 模型做成 Dynamic Feature，用户首次安装仅 38 MB，进入直播间再下 12 MB，避免一次性 150 MB 大包被渠道拒审。
第三，签名一致性：使用 Google App Signing 后，上传密钥与分发密钥分离，国内多渠道包用同一派生签名，微信开放平台指纹冲突问题归零。
第四，合规自动化：AAB 在 Play Console 自动完成 64 位剥离、压缩、SDK 合规扫描，CI 侧一条 bundletool 命令即可同步生成华为、OPPO、vivo 所需 APK，减少人工脚本维护。
第五，安全与回滚：App Signing Key 由 Google HSM 保管，泄漏风险可控；同时支持一键升级密钥，无需担心旧版本覆盖。
综上，AAB 不是简单换格式，而是把‘体积、动态化、合规、安全’做成后台黑箱，让国内团队专注业务而非分包脚本，因此 Google 持续加码推荐。”
拓展思考
- 国内商店尚未原生支持 AAB，如何在 CI 上做到“一次构建，多渠道秒级派生”？
答：在 GitLab-CI 中引入官方 bundletool，通过--mode=universal生成通用 APK 作为兜底，再按渠道配置split-by-abi生成定向包，最后利用apksig统一 V2+V3 签名，即可 3 min 内产出 8 个渠道包。 - 如果公司同时出海与国内发行，如何管理两套签名？
答：出海走 Google App Signing，国内走自己掌握的 release.jks；在 build.gradle 里用if (isGoogleFlavor)切换签名配置，保证同一源码、两套指纹，避免微信、Facebook SDK 登录冲突。 - 动态功能模块在国内网络环境做“按需下载”时，如何防止 DNS 劫持与下载失败？
答：把 Split APK 托管在阿里云 CDN，并在 Application 的SplitInstallManager回调里做 MD5 校验与断点续传；同时降级方案是预置完整 so 于 assets，首次启动拷贝到 native 目录，确保弱网也能跑。