Corona项目Google Billing V2插件在6.0版本库更新后对延迟购买的处理问题分析

问题背景

Corona项目的Google IAP Billing V2插件在升级到Billing Library 6后，出现了对延迟购买（Pending Purchases）处理异常的情况。开发者报告称，当用户进行需要额外验证的延迟购买时，系统无法正常触发storeTransaction回调事件。

技术细节分析

1. 问题表现

在Billing Library 6更新后，插件在处理延迟购买时出现以下异常行为：

• 正常购买流程工作正常
• 延迟购买流程中，storeTransaction事件未被触发
• 日志显示出现NullPointerException异常
• 当购买状态最终变为"purchased"时，transaction.identifier字段才被正确填充

2. 根本原因

经过分析，问题主要源于以下技术变更：

1. Billing Library 6的行为变更：新版库对延迟购买的处理流程有所调整，特别是在订单ID的获取时机上发生了变化。

2. 空指针异常：在StoreTransactionRuntimeTask.executeUsing方法中，尝试推送字符串到Lua状态时出现了空指针，表明在处理延迟购买时某些关键字段未被正确初始化。

3. 订单ID获取时机：在新版本中，getOrderId()方法在购买状态变为"purchased"之前不会返回有效值，这导致在延迟状态下transaction.identifier字段为空。

解决方案与建议

1. 插件修复

开发团队已经发布了修复版本，主要解决了以下问题：

• 正确处理Billing Library 6的延迟购买回调
• 避免在处理过程中出现空指针异常
• 确保storeTransaction事件能够被正常触发

2. 开发者适配建议

对于需要使用延迟购买功能的开发者，建议：

1. 状态处理逻辑：需要区分"pending"和"purchased"两种状态，特别是在依赖transaction.identifier字段时。

2. 数据持久化：考虑使用其他唯一标识符来跟踪延迟购买，因为在新版本中订单ID在购买完成前不可用。

3. 错误处理：增强对异常情况的处理，特别是对空值的检查。

技术实现建议

对于类似IAP系统的实现，建议采用以下模式：

1. 状态机设计：将购买流程建模为状态机，明确区分各个状态（初始化、待处理、已完成、失败等）。

2. 异步处理：确保所有回调都能正确处理，特别是在应用生命周期变化时（如暂停/恢复）。

3. 数据验证：对所有从商店API获取的数据进行严格的空值检查和类型验证。

总结

这次事件凸显了第三方库升级可能带来的兼容性问题。对于移动应用内购这种关键功能，开发者需要：

1. 密切关注依赖库的更新日志和行为变更
2. 建立完善的测试流程，特别是对边界情况的测试
3. 设计健壮的错误处理和数据验证机制

通过这次修复，Corona项目的Google IAP Billing V2插件已经能够更好地处理Billing Library 6的延迟购买场景，为开发者提供了更稳定的应用内购解决方案。