为何Android Billing Library 4的Purchase类getSkus返回数组而非旧版getSku

改动的核心设计原因 #

• 适配Google Play新增的多商品合并支付能力：Billing Library 4发布同步支持了订阅捆绑、权益打包等新售卖模式，原来仅支持返回单个sku的getSku()无法匹配一笔订单对应多个商品的新规则
• 向下兼容无额外适配成本：返回ArrayList<String>的设计完全覆盖旧场景，当列表长度为1时，取第一个元素即可等价于旧版getSku()的返回值，不需要开发者做大面积逻辑改造
• 为后续能力扩展预留空间：后续Google Play如果开放普通内购的批量购买、跨类型商品打包等新能力，不需要再修改Purchase类的核心API结构，减少后续版本迭代的开发者适配工作量

getSkus() 返回多个条目的常见场景 #

• 订阅捆绑包购买：开发者在Google Play后台配置的多订阅项组合售卖包，用户一次支付开通多个订阅权益时，返回的列表会包含捆绑包内所有订阅的sku
• 订阅绑定附属权益：部分订阅在开通时会同步赠送专属内购权益、附加服务等附属sku，两者合并为一笔订单完成支付，此时列表会包含主订阅sku和所有附属权益sku
• 内购商品组合包：活动场景下配置的多件普通内购商品打包售卖的组合包，用户一次购买多个内购商品时，返回列表会包含组合包下所有子商品的sku

迁移小提示：如果你的应用暂不支持多sku合并售卖的场景，直接调用getSkus().get(0)即可获得和旧版getSku()完全一致的返回结果，原有支付逻辑不需要做过多调整。

内容的提问来源于stack exchange，提问作者thisonestackuser