Google 官方推出 App Bundle 已经有一年多时间，虽然从时间进程上来看，已经算是一个比较成熟的官方动态化组件技术，不过对于在国内上线的应用来说，基本感受不到这个技术带来的便利。

我自己所在的公司，主要做的是出海社交娱乐业务，所以应用主要是在 Google Play 上架，不过即使 App Bundle 已经推出一年多时间，公司的项目都还没有用上这个格式，相信大部分出海业务的公司项目也是这个情况。

不过近期 Google Play 的两个动作起到了催化剂的作用：

第一个是：从 2019 年 8 月 1 日 开始，在 Google Play 上发布的应用必现支持 64 位架构，这个意味着上架的应用要包含多份架构的 SO 包，导致应用大小大幅度增加，以我所在的项目数据为例，以前只有 armeabi -v7a 一种 CPU 架构，但是为支持 64 位，增加 arm64-v8a 架构，导致 APK 增加 13M
更新应用的时候，如果还是使用 APK 格式，则会有未优化的警告，强烈提议使用 App Bundle 格式更新应用；

由于 Google Play 的两个举措，特别是第一个，导致负责的 Waka 应用直接增加 13M 的大小，这是非常不利于市场的推广的，所以经历了两三个版本之后，决定使用 App Bundle 格式发布应用。

关于 App Bundle 格式比较详细的格式，网上也比较多介绍文章，本文不作过多介绍，如果不是很了解的话，推荐阅读 16 个使用 App Bundle 发布应用和游戏的理由。

本文主要跟大家分享在 App Bundle 探索实践过程中的一些心得体会，让大家对于使用 App Bundle 发布应用有比较清楚的认知，主要包含几点：

PS：本文分享的经验 AppBundleDemo 已开源在 Github 上，建议向 clone 该项目到本地对照着操作。

如果项目要输出 App Bundle 格式的包，需要满足两个条件：

gradle 版本要大于：3.2.1，比如：

classpath 'com.android.tools.build:gradle:3.2.1'

从 Google Play 后台的某个应用页面的菜单：版本管理 --> 应用签名，可以查看一个应用是否已经开启应用签名，如下是未开启的状态：

当然开启方式也是蛮简单的，推荐使用第一种方式：上传从 Android Studio 导出的密钥，这种方式操作极其简单，步骤如下：

选择 build --> Generate Signed Bundle or APK --> 勾选 Android App Bundle，然后下一步；
下一步之后，填好你的签名密钥信息之后，勾选：Export encrypted key for enrolling published app in Google App Signing，选择好输出路径，点击 Next 打包完成之后即可获得一个：private_key.pepk 文件
把这个文件上传到 GP 后台即可开启成功

已经成功开启的状态则如下：

经过上面操作，我们已经可以打包 App Bundle 格式，并且在 Google Play 后台发布，我们看下，带来了哪些变化：

应用大小：完整 apk 大概 52M，aab 的范围大概是：35M ~ 37M，带来大概 15M ~ 17M 的降幅，同时 GP 后台也会有相应的数据面板，能够方便跟踪各个版本应用大小的变化情况；
应用从 GP 安装时，将不会包含所有的语言包和 SO 包，仅包含：对应架构的 SO 包、对应的英语和手机的语言【支持多种语言，则有会安装多种语言包】，如下：
处理发包流程会有些变化，因为 fir 只能上传 apk 格式的安装包，所以上传到 GP 后台的发布包不再从 fir 下载，只能手动打包并且手动验证，然后上传发布；

对于第三点变化是不太能接受的，过程过于繁琐，而且容易出错，要是出现把含有测试环境切换入口的包发布到 GP，伤害将是灾难性的。

经过一番思考，开发测试阶段，依然使用 fir 出 apk 包，方便测试更新版本进行测试，GP 发包则决定使用 gradle task，然后结合 shell 脚本完成自动出包、生成 aab 包、自动安装到手机，然后验证，buildGooglePlayAAB.sh 基本流程如下：

ps：./buildw clean bGPA 中的 bGPA 是缩写，这里有个小技巧 gradle 任务命名符合驼峰法，则可以用首字母缩写调用【注意区分大小写】