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就意味着订单对不上，因此我们需要进行凑单机制。
综上，我们对异常处置处罚有了确定方案：
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
