AAB — 是什么，与APK的区别及工作原理

什么是AAB

AAB（Android App Bundle）— 是由Google开发的发布格式，作为通过Google Play分发APK的替代品。AAB内部是一个扩展名为.aab的ZIP存档，包含编译后的代码、资源和元数据。关键区别：AAB不能直接安装在设备上。

工作原理

开发人员将AAB上传到Google Play Console。当用户尝试安装应用程序时，Google Play会分析设备配置：屏幕密度（DPI）、CPU架构、语言和Android版本。基于此分析，生成仅包含必要组件的最小APK。

实施历史

Google在2018年的I/O大会上介绍了AAB。自2021年8月起，该格式成为Google Play中所有新应用程序的强制要求。现有应用程序可以继续使用APK，但新应用程序只能以AAB格式发布。

AAB与APK有何不同

区别在于AAB和APK之间是根本性的：APK是一个完整的安装文件，可以直接安装。AAB是一个带有源组件的容器，需要处理。

APK适用于Google Play之外的分发——通过网站、电子邮件或企业MDM系统。AAB与Google Play基础设施绑定，不能直接安装。测试AAB时使用bundletool工具，它在本地机器上模拟APK生成。

AAB文件的结构

内部结构与APK类似，但包含用于描述模块及其依赖关系的额外目录和文件。

基础模块（base）

base模块——AAB的必需组件。它包含应用程序的主要代码、资源和清单。没有base模块，应用程序无法构建。所有其他模块都是可选的，通过Dynamic Delivery连接。

Protobuf格式

AAB配置使用Protocol Buffers（protobuf）代替XML。.pb文件更紧凑，Google服务器基础架构解析速度更快。bundletool工具将protobuf转换为可读格式以进行调试。

Dynamic Delivery和应用程序模块

Dynamic Delivery——构建AAB的关键技术。它允许仅向用户提供与其设备和语言匹配的应用程序部分，以及按需加载额外的模块。

模块类型

Install-time模块在安装时与基础APK一起加载。Conditional模块仅在满足条件时提供——例如，包含4K屏幕材料的模块。On-demand模块在应用程序内根据用户请求加载。

Play Asset Delivery（PAD）

对于大型资源（高达2 GB），使用Play Asset Delivery代替OBB文件。PAD支持相同的三种交付模式：install-time、fast-follow（安装后立即）和on-demand。

// 通过SplitInstallManager加载按需模块
val manager = SplitInstallManagerFactory
    .create(context)

val request = SplitInstallRequest
    .newBuilder()
    .addModule("level_pack_3")
    .build()

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "模块已安装")
    }

Gradle中的模块配置

每个动态模块由一个单独的build.gradle文件描述，并指定交付类型。模块可以拥有自己的资源、代码和清单，独立于基础应用程序。

通过Gradle构建AAB

构建AAB通过Android Gradle Plugin使用bundleRelease（或bundleDebug）任务完成。结果是一个.aab文件，位于build/outputs/bundle/目录中。

构建配置

构建AAB不需要特殊设置——Android Gradle Plugin默认支持包。只需指定bundle任务而不是assemble即可。

// build.gradle.kts — 使用签名构建AAB
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// 任务：./gradlew bundleRelease

通过bundletool进行本地测试

Google提供bundletool工具，用于在本地机器上从AAB生成APK。命令`bundletool build-apks --bundle=app.aab --output=app.apks`创建一组APK，用于在不同设备配置上进行测试。

bundletool还可以解包AAB，显示其配置，并在上传到Google Play Console之前检查签名的完整性。调试时使用命令`bundletool dump manifest --bundle=app.aab`，它显示基础模块的清单。

AAB中的拆分配置

默认情况下，AAB根据三个维度拆分资源：语言（language）、屏幕密度（density）和CPU架构（abi）。开发人员可以在build.gradle中禁用任何拆分——例如，如果应用程序只支持英语。禁用拆分意味着所有变体的资源都将进入基础APK。

Resource optimisation——AAB自动将PNG转换为WebP而不损失质量，压缩未使用的资源并删除重复的字符串。这些优化在Google Play端生成最终APK时应用。结果，用户收到的APK比完整存档小15–25%。

在Google Play中发布AAB

发布过程在Google Play Console中与APK的区别仅在于上传文件的格式。控制台接受.aab，检查其结构、签名和模块配置，然后为每种设备类型生成APK。

App Signing by Google Play

上传AAB时，Google Play接管签名密钥的管理。开发人员上传使用upload密钥签名的包，Google用自己的密钥重新签名生成的APK。这简化了密钥轮换和在丢失keystore时的访问恢复。

发布前测试

Google Play Console提供内置的AAB测试：可以下载针对特定设备生成的APK，或通过Internal Testing、Closed Alpha和Open Beta track运行内部测试。

AAB的常见问题及其解决方法

迁移到AAB可能会引起问题，特别是在具有大量动态模块或复杂资源配置的项目中。

模块配置错误

如果动态模块以不正确的名称引用基础模块的资源，Google Play会在验证阶段拒绝AAB。解决方法——在构建前使用lint检查，并通过bundletool本地测试所有模块。

语言拆分和性能下降

如果当前本地化的资源是动态加载的，按语言拆分可能会减慢应用程序的启动速度。Google建议——如果语言少于10种，不要拆分，或者对最流行的语言使用install-time。

与第三方SDK的兼容性

某些SDK（分析、广告、地图）需要访问完整的清单和资源。检查与AAB的兼容性是迁移前的强制性步骤。大多数大型SDK（Firebase、Google Ads、Crashlytics）自2022年起完全支持AAB。使用带有--validate标志的bundletool检查兼容性，它模拟服务器端APK生成。

AAB版本控制

AAB使用基础模块清单中的versionCode。与APK不同，AAB还支持每个模块单独的versionCode——这允许更新应用程序的各个部分而无需完全重新安装。Dynamic Delivery跟踪已安装的模块，并在通过Google Play更新时仅提供更改的组件。

AAB监控和分析

Google Play Console为每个AAB提供详细分析：生成了多少APK，哪些拆分被请求，按设备的平均下载大小是多少。Android Vitals显示生成的APK的性能指标。这些数据有助于优化拆分配置并减少不同设备类别的下载大小。