前言
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 格式更新应用；
使用 App Bundle 格式发布应用
由于 Google Play 的两个举措，特别是第一个，导致负责的 Waka 应用直接增加 13M 的大小，这是非常不利于市场的推广的，所以经历了两三个版本之后，决定使用 App Bundle 格式发布应用。
关于 App Bundle 格式比较详细的格式，网上也比较多介绍文章，本文不作过多介绍，如果不是很了解的话，推荐阅读 16 个使用 App Bundle 发布应用和游戏的理由。
本文主要跟大家分享在 App Bundle 探索实践过程中的一些心得体会，让大家对于使用 App Bundle 发布应用有比较清楚的认知，主要包含几点：
- 使用 App Bundle 格式对项目配置有哪些要求；
- 如何Google Play 后台为应用开启支持 App Bundle 格式发布应用；
- 采用 App Bundle 格式之后，发包流程如何做到自动化提高效率【主要经验分享】；
PS：本文分享的经验 AppBundleDemo 已开源在 Github 上 ，建议向 clone 该项目到本地对照着操作。
项目支持打包 App Bundle 格式
如果项目要输出 App Bundle 格式的包，需要满足两个条件：
- Android Studio 3.2 以上版本
- gradle 版本要大于：3.2.1，比如：
classpath 'com.android.tools.build:gradle:3.2.1'
在 Google Play 后台为应用开启应用签名
由于 App Bundle 实际是采用独有的 AAB 后缀格式【实际也是一个 ZIP 包】，当用户实际从 Google Play Store 点击安装应用的时候，再根据用户的设备信息 GP 后台服务器使用 bundletool 工具生成符合这个设备的 *.apks 文件，流程如下：
GP 安装应用流程
从 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 后台也会有相应的数据面板，能够方便跟踪各个版本应用大小的变化情况；
[图片上传失败...(image-26bda9-1568986397970)] - 应用从 GP 安装时，将不会包含所有的语言包和 SO 包，仅包含：对应架构的 SO 包、对应的英语和手机的语言【支持多种语言，则有会安装多种语言包】，如下：
[图片上传失败...(image-81fcd4-1568986397970)] - 处理发包流程会有些变化，因为 fir 只能上传 apk 格式的安装包，所以上传到 GP 后台的发布包不再从 fir 下载，只能手动打包并且手动验证，然后上传发布；
对于第三点变化是不太能接受的，过程过于繁琐，而且容易出错，要是出现把含有测试环境切换入口的包发布到 GP，伤害将是灾难性的。
经过一番思考，开发测试阶段，依然使用 fir 出 apk 包，方便测试更新版本进行测试，GP 发包则决定使用 gradle task，然后结合 shell 脚本完成自动出包、生成 aab 包、自动安装到手机，然后验证，buildGooglePlayAAB.sh 基本流程如下：
构建 aab 包流程.jpg
本文原创于微信公众号「fireantzhang」，欢迎关注第一时间获取出海开发经验。
网友评论