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

[jim9606]

以前我在想，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 审批公文和推送证书整出来？

[mgrddsj]

感觉就是为了开发者和用户绑在 Play Store 吧，毕竟现在部分地区要求支持第三方应用商店。这些措施美名其曰安全，实际上最近各种动作（比如限制侧载）都是想限制第三方应用分发。

[kkocdko]

有同感。

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

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

[jim9606]

@mgrddsj App Bundles 的设计初衷跟捆绑商店没啥关系，但后面确实是拿这东西当手段了

[jim9606]

@kkocdko

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

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

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

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