2023-10-08 16:38:50 最新的文章修正,请查看
flutter IAP苹果内购总结 - 掘金 (juejin.cn)
这里介绍的是苹果的内购,目前最常用的两个内购
1.谷歌官方出的: in_app_purchase
pub.dev 1151 likes
github.com 这是flutter插件集里的插件,无法看出真正的stars
2.先于谷歌官方出的民间插件 flutter_inapp_purchase
pub.dev 308 likes
github.com 492stars
从长远来看,in_app_purchase获得的支持力度更大,毕竟是官方自己出的,而flutter_inapp_purchase是在那个没有官方插件的年代时,大众们能依靠的最好内购插件.本文,基于项目考虑,还是采用了官方的in_app_purchase插件
使用(这里只使用消耗形的商品购买)
友情提示一下各位,在使用这些有三方的库时,最好都自己封装一层,方便后续替换成其他库.
使用前准备
绝大部分文章都已经介绍了如何配置消耗型商品栏目,以及测试人员配置,这里不再赘述,这里只提示几点,测试人员是账号级别的,同一账号下的测试人员可以直接参与到APP测试,消耗形商品的productID不允许与其他APP相同.
使用
in_app_purchase的使用demo也很简单.我们只需要知道流程顺序:
- 后台展示出可购买的商品清单(这一步可以自己查询出所有清单,但是正常的APP不可能只有系统配置的那些商品信息,所以,商品清单肯定是由后端提供的.
- 选择购买商品id,查询苹果商品详情
if (productDetails.isEmpty) {
ProductDetailsResponse res = await _inAppPurchase.queryProductDetails(IAPProduct.allProducts);
productDetails = res.productDetails;
}
ProductDetails? productDetail = productDetails.firstWhereOrNull((element) => element.id == productId);
3.发起交易请求
final purchaseParam = PurchaseParam(
productDetails: productDetail,
applicationUserName: "${ServerTime.millisecond}");
_inAppPurchase.buyConsumable(
purchaseParam: purchaseParam,
autoConsume: true,
);
4.等待回调
其中有各种状态判断,消耗型只需要注意
pending:
交易中,用于展示loading等信息
error:
交易错误,根据错误码展示相应信息,如未能连接到苹果服务器等等
canceled:
交易取消,吐丝,取消loading等
purchased:
交易成功, 验单,完成交易等
注意点
前面都是大同小异的内容,其他文章也都有.既然我要写,那我就写点别的文章没有提到的,iap要解决的永远不是这种正向逻辑,而是一大堆稀奇古怪的骚操作,比如APP闪退,强杀APP等行为带来的掉单,验单失败问题.
交易清单信息变更
在非正常交易逻辑中,在用户收到交易订单完成后,如果验单未成功,APP闪退或者我们强制杀死APP等其他操作,导致交易中断,那么下次进来的交易信息会发生变更.
下图是第一次交易成功信息回调时的订单,交易id为2000000111028232
下图是强制杀死APP后,重新监听交易队列时获取到的订单信息,可以看到,除了交易id仍然为
2000000111028232之外,serverVerificationData,transactionDate都为新的交易信息,并且我塞进去的applicationUsername也只在第一次交易回调起作用,后续的交易信息直接为null,但是,没关系,验单任然是能成功的.
这也从侧面说明了,仅靠in_app_purchase交易队列的机制,是无法实现我们的额外参数填充,去辅助订单校验.我一开始是想仅依靠消息队列,在完完全全从服务器验完单后,再完成这笔交易.本来,这种方法可以从队列机制上解决掉掉单问题,但是上述的问题,打消了我的想法.而下面的这个问题,也促使我去实现钥匙串自存储订单来解决调单问题.
队列监听时机问题
_inAppPurchase.purchaseStream是用来监听消息队列的回调的,也就是所有订单的状态以及信息回调,我们当然是希望,在用户登录完成后,再开启订单的监听队列,这样,在验单的时候,就能够及时获取到订单的所有信息,但显然,in_app_purchase并不是这么做的,这个属性的文档中这么说到:
文档的意思十分清楚,希望我们在app启动的时候,就开启消息队列的监听,为什么必须要这样做呢,我查看了其源码IMPORTANT! You must subscribe to this stream as soon as your app launches,
preferably before returning your main App Widget in main(). Otherwise you
will miss purchase updated made before this stream is subscribed to.
重要！你必须在应用程序启动后立即订阅此流，
最好在main（）中返回主应用程序小部件之前。否则你
将错过订阅此流之前更新的购买。
发现在InAppPurchase的单例初始化方法里,当streamcontroller建立起与原生的通信后,直接发起了队列的监听,这也就导致我们需要在使用到调用到单例属性的之前,先建立purchaseStream的监听
这与我的业务需求严重不符!
这与我的业务需求严重不符!
这与我的业务需求严重不符!
我希望能自己掌控到队列的监听时机,可in_app_purchase并不给我这个机会.
productId发起异常
如果未能完成上一次的订单,调用请求下一次的交易,会报错
Unhandled Exception: PlatformException(storekit_duplicate_product_object, There is a pending transaction for the same product identifier. Please either wait for it to be finished or finish it manually using completePurchase to avoid edge cases., {applicationUsername: 1658383960024, requestData: null, quantity: 1, productIdentifier: an_coin_6, simulatesAskToBuyInSandbox: false}, null)
如果你的APP不需要那么严格订单的校验机制,比如服务器有预请求接口,验单时需要提交预请求的参数,又或者你的APP允许A支付B账户充值,那么你可以仅依靠交易队列去实现,但我的APP不行.
综上所述,使用谷歌的in_app_purchase插件,在仅靠交易队列机制,我们是无法实现一个精准验单的,所以必须要自己手写验单逻辑.这就跟我原生写iap的逻辑基本完全一致了.
这里仅提几个小点
1.交易完成必须在把订单手写入钥匙串成功后再完成交易.
2.指数时间重复校验这是必不可少的,一般校验失败个两三次后,就可以走上传日志逻辑了,如果掉单行为不能完全抹除,一个好的报错接口可以解决很多问题.
3.后端最好有预创建订单api接口,苹果的iap十分霸道,创建订单,获取订单的serverVerificationData完全是前端自己的行为,这一点其实很不安全,因为订单完成好坏服务器一点都不能知晓,所以最好是让后端先建立一笔自己的订单记录,然后验单时顺便校验这个订单信息,保证前后对照行为一致.
下一篇立个flag,写点啥呢,overlay层级控制?flutter异步任务队列?upyun文件上传?东西其实都解决过了,只不过写blog真是有点懒啊~唉,好了,其他话没什么好说的,祝大家生活愉快
