感觉 App Bundles 的设计属于学了不该学的对象

以前我在想，aab 明明可以设计成像民间 xapk 那样，一个 zip 包里面一个清单再加一组已经由 deployment key 签名的 split apk ，这样商店根据目标机器的情况挑选一组 apk 下发就行，不需要重新签名，但现在：

aab 需要一个单独的 upload key 来签名，这玩意除了让 GP 验证打包上传者是否控制 upload key 之外没任何意义，因为得先登开发者账号才能上传 aab ，都不知道这个重复验证有何意义
从 aab 生成 apk 需要 deployment key 重新签名，所以也没法通过验证 aab 签名来确定是否是同一来源
为了“证明”GP 自己在重签名是没篡改，还煞有介事的在 apksigner 搞了个 code transparency 签名，但分发和最终用户都不会管这玩意，都不知道谁会用
清单和签名用的格式五花八门，aab 的清单(BundleConfig.pb)是 protobuf ，签名继续用 jar sign ，元数据有 plaintext 有 json ，code transparency 签名是 JWT ，apk 里继续用非标 binary xml
由于需要重签名，所以商店必须托管 deployment key ，等于强制加入 Play Signing 计划，所有使用 aab 的商店都需要托管 deployment key ，增加了泄漏风险，也丧失了通过签名验证来源的有效性
因为需要支持运行时按需加载，强制依赖专有的 Play Core 库，受此限制等于强制淘汰 5.1 以下的系统（虽然影响是很小），而且因为调用商店并非 Android 公有 API ，包含 play core 的包一般不能用于第三方渠道，
因为 aab 不流通，所以 AOSP 的包安装器只有 API 支持但没有 UI 功能支持，个别厂商甚至拒绝修复 API 实现缺陷

我感觉 aab 这玩意把流程设计成这样子是跟 App Store 学的，从开发测试到分发整一堆不知道要防谁验证谁的签名，还跟最终用户部署没关系，现在 aab 流程最多搞出了三套证书，我是不是还得谢谷隆恩没把 mobileprovision 审批公文和推送证书整出来？

kkocdko

9 月 22 日

有同感。

另外，aab 很多时候似乎“解决了不存在的问题”。如今随着矢量图资源等的广泛使用，对不同 dpi 的分包变得不那么必要了（只剩下多语言还有分包必要）。架构也只剩下 arm64-v8a 。

我前阵子尝试了一下，保持原生库不压缩，用 http content-encoding zstd ，已经能做到非常好的分发节省效果。用户侧的安装速度也快很多（ xapk/apkm 下载后需要额外重组步骤。官方 aab 我不清楚）。

jim9606

9 月 26 日

@kkocdko

实际上完全可以按功能模块(dynamic feature)划分，arch 语言 dpi 这些只是 Play 和 AGP 预先定义好的划分 dimension 。

至于全面转用矢量贴图我觉得跟现在的指望现在主流 ui 设计工作流做到这个（通常要跨平台）不太现实，就说转用 webp 贴图这点都不怎么普及，别说让 ui 输出 svg 资产再转换了。

按功能划分其实大有可为，现在支付宝微信的 aab 就是按功能模块+arch+dpi 划分的，虽然我个人不怎么喜欢（因为我不想在外用到一半突然要花流量去下缺的 split ）

原生库不压缩这个也是一大槽点，明明是一个省安装空间的优化楞是被说成是负优化（什么开压缩立省 30%包体这种，实际只有 6.0 以下的系统和多架构 apk 有收益），我就没看到 google 以外的 blog 说清楚这个的，似乎也只有 play 知道应该按有传输层压缩的情况算流量而不是盯着那个 apk 大小。