void dispose() {
WidgetsBinding.instance.removeObserver(this); //销毁观察者
super.dispose();
}
/// 应用状态监听
@override
void didChangeAppLifecycleState(AppLifecycleState state) {
switch (state) {
case AppLifecycleState.resumed:
{
if (Platform.isAndroid && _isPaying) {
_isPaying = false;
// 监听到时安卓设备并且支付还在举行中，步伐员要根据业务做一下处理
break;
}
default:
break;
}
super.didChangeAppLifecycleState(state);
}
}
到此，微信支付很舒畅的解决了，以上代码是抽象出来的工具类，可以直接使用；但是不涉及任何业务流程的开发，这个须要使用者自己去补充。 综上，微信支付流程主线可简单粗暴总结为：服务端生成订单 → 客户端调起支付 → 客户端关照服务端核验订单 → 客户端拿到最终结果 → 客户端final支付。 整个过程形成闭环，有理有据，数据都由后端去操纵安全合理。(最重点是前端工作量简直不要太少)。
但是，iOS就不一样了，简直不要太恶心！
iOS IAP应用内支付
- IAP，即in-app Purchase，苹果推出的App内购买假造商品的方式，基于AppStore账户的支付方式。由于iOS整个体系都是基于自己的一套系统的（不像上面的微信支付，是第三方支付平台），因此在开发之前，我们须要到Apple开发者中心完成以下步骤：
1. 签署协议和银行业务 2. 在配景创建App内购买项目，这里所有的代价都是Apple规定好的，我们只有选择的资格，没办法自定代价。创建完成后，每个项目会有sku和productId 3. 添加沙盒测试员Apple 以上步骤参考内容引自站内大神：Geniune
- 支付流程：应用通过sku向服务端获取商品列表 → 列表中取出对应产物请求支付 → 进入appStore支付 → 页面监听支付回调拿到验证单子 → 业务配景拿到应用接收到的单子后去Apple官网举行校验即可。
流程很简单，简单到险些不用跟业务配景打交代，但是坑却随之而来：
① 支付数据完全依赖前端应用，很难跟业务配景的订单系统逐一对应；
② 针对①的问题，IAP支付支持传递skPayment对象，里面的applicationUsername经常用来保存系统的OrderId；
但是应用支付乐成后收到的回调中，applicationUsername却偶尔会出现为null的情况，没有了对应关系，就没办法核销业务系统中的订单从而为用户充值；
③ iOS支付回调非常不稳定，有时延迟严肃；且没有任何注定查询的方法；
④ iOS应用内支付有很多非常情况要处理，最常见的就是没有登录、没有同意最新的iOS支付协议等，都会发送给app支付失败的回调；
但是当用户登录或是同意后，iOS系统又会触发新的支付，导致旧的附带业务订单号的支付无效，莫名又多出一个没有订单号的新支付；
⑤ 国内网上资料非常缺乏，根本都是19年从前的，Flutter的文章更是少的可怜，可参考性不强。
⑥ 测试文档对于中断购买的测试流程有巨坑，背面菜单一定不要错过~
通过查看文档和不断调试，我们发现：
① 支付错误的回调，根本能马上收到； ② 上面流程说到IAP支付须要手动竣事支付流程。同时iOS规定不能对同一个skuId重复发起多次支付的，只要当前skuId有没有final的支付，再次发起都会失败； ② 无论支付乐成或失败，只要app没有自动对当前支付举行final，每次启动app后，app都会收到这个支付信息的关照； ③ 关于applicationUsername，只有在支付完成马上收到回调的情况下，回调信息才会有这个信息；到②中的情况，肯定不会返回applicationUsername； ④ 没有applicationUsername就意味着订单对不上，因此我们须要举行凑单机制。
综上，我们对非常处理有了确定方案：
① app发起支付后，须要将业务OrderId和skuId举行持久化存储（即卸载应用都不会删除的数据）&#
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
