1. AAB与APK的核心区别

Android App Bundle (AAB) 是 Google 于 2018 年推出的官方发布格式，取代了传统的 APK 成为 Play Console 的默认上传格式。虽然两者最终都在设备上安装为 APK，但它们在构建、签名、分发和安装阶段存在根本性差异。理解这些差异是掌握动态交付技术的基础。

1.1 打包格式的架构差异

• APK：所有资源平铺在 ZIP 根目录，resources.arsc 包含所有字符串、颜色、尺寸等资源 ID 映射；DEX 文件受 64K 方法数限制，需要 MultiDex。
• AAB：使用 resources.pb（Protocol Buffers）代替 resources.arsc，支持更高效的增量编译和资源压缩；模块目录结构清晰，允许多个 DEX 文件按模块拆分。
• 动态交付关键：AAB 的 base/ 目录包含基础模块，feature_xxx/ 目录包含按需分发模块，每个模块都可以独立配置安装条件。

// 应用级 build.gradle
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// 特性模块 build.gradle (dynamic feature)
android {
    defaultConfig {
        moduleId = "feature_camera"
    }
}

1.2 签名机制的玩法区别

• APK 签名：对整个文件内容计算摘要，签名后存储在 APK 的 META-INF/ 目录中；v1 使用 JAR 签名，v2/v3 使用 APK Signature Scheme，覆盖整个 ZIP 内容。
• AAB 签名：上传到 Play Console 的 AAB 本身不包含签名，仅包含签名元数据（BUNDLE-METADATA/com.android.signing/）。Google Play 合成 APK 时使用开发者上传的密钥信息进行重新签名。
• 本地测试：使用 bundletool 时需要显式指定 keystore，否则生成的 APK 无法安装（INSTALL_PARSE_FAILED_NO_CERTIFICATES）。

1.3 安装过程：从 AAB 到设备

1. 上传：开发者将 .aab 文件上传至 Google Play Console。
2. 生成 APK Set：Play 商店（或 bundletool）读取 AAB 的 BundleConfig.pb，根据设备提交的屏幕密度、ABI、语言、API 等级等参数，从 AAB 中提取匹配的资源，合成一个 .apks 压缩包。
3. 签名：对每个生成的 split APK 使用 App Signing by Google Play 或开发者自己的密钥进行签名。
4. 安装：设备接收到一组 split APK（base + 配置 split + 按需 feature），PackageManager 将其视为同一应用，合并安装到 /data/app/ 下。

1.4 多 APK 生成策略对比

1.5 模块分割规则与资源代码拆分

AAB 的模块分割遵循以下规则：

• 资源拆分：按 density、language、mcc、country、screen 等限定符分割，每个 split APK 只包含该设备需要的资源文件。
• 代码拆分：DEX 文件按模块拆分，base 模块包含应用入口和核心代码，dynamic feature 模块的代码只在按需下载后才可用。
• 原生库：按 ABI 拆分，设备只会获取匹配的 lib/ 目录。
• 安装时 vs 按需 vs 条件分发：
  install-time：随 base APK 一同下载安装（合并为初始 APK）；
  on-demand：用户运行时按需下载；
  conditional：根据设备特性（如国家、API 级别、硬件功能）决定是否自动安装。