DateTime时间戳计算
一言蔽之，通常使用DateTime计算时间戳，起始时间点为UTC时间1970年1月1日0点整，需手动设置一个基准DateTime来处理。
DateTime StartDateTime = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
IAP相关问题
-
IOS duplicate transaction 问题： 首先声明的是，这个问题还没有得到一个确定的答案，只能是猜测，先贴个Unity论坛的讨论链接：https://forum.unity.com/threads/ios-duplicate-transaction-error-on-purchases.1024450/ 在IOS沙盒环境下测试，使用Unity IAP进行RestoreTransactions ，会有较长的一段延迟，这段时间内进行iap购买，会导致purchase failed，失败原因就是标题的duplicate transaction，过一段时间后恢复正常。另外，如果是购买过订阅/非消耗型商品的账号，由于恢复收据会将所有的receipt都走一遍ProcessPurchase（也就是发起购买的流程），那么restore行为本身也会产生一堆purchase failed。 解决方法：无，推测是ios沙盒环境的特有问题，直接上线。目前来说没有收到相关反馈，论坛里有个老哥也说发布后没有相关问题出现，只能说有的问题不是人类的心智可以理解的.jpg（唯一的问题就是，跟甲方解释这个bug现象的时候，非常的心虚及自闭，如果可以，谁又想放着问题不管呢） -
IOS订阅收到invalid transaction错误： IOS的IAP是走的苹果商店官方验证，其中订阅型商品需要加上password校验字段，最好再加上字段 data.Add(“exclude-old-transactions”, “true”)，大概验证效率会更好一点。 如果当前处于订阅阶段，并切换订阅的栏目（月卡变周卡，月卡变年卡等），且符合订阅规则下的当前订阅到期后才切换而非立即切换，那么就会收到错误码为21002的具有空receipt-data的transaction，至于IOS的错误码含义，这里就不详述了。 解决办法：这和苹果的订阅策略有关，非立即切换就会发一条空收据表示完成了切换的操作。一般来说这种情况当成成功购买也无所谓，因为实际去判断是否处于订阅状态，是根据该product的最新receipt里的Playload里的······总之是挖出来的订阅信息字段，来校验是否订阅是否终止起止时间等等，所以并不会有什么影响。（就像Server-Client的游戏里，Client不管成功失败，最后结果也全听Server一样） 另：IOS环境下通过restore产生的订阅transaction，发到苹果服务器进行验证的时候很坑爹的会产生和以前不一样的transactionId，进而导致一堆购买失败回调，针对这个问题应该进行如下比对，其中后者receipt是本地的product.receipt，在下是比对成功就直接忽视该条：
response.receipt["original_transaction_id"] == receipt.originalTransactionIdentifier
-
谷歌和苹果不同的预注册奖励策略： 谷歌的方式比较简单粗暴，开发者这边为预注册奖励申请一个额外的iapId，预注册的用户从商店下载app并启动后，会走一个正常的iap流程为这份奖励进行发货。需要注意的地方是要判断用户是否领取过该奖励，至少我在测试的时候遇到过重新安装app之后奖励再次下发的情况。 苹果的方式是，在下载该应用的时候会有一个appReceipt，与iap购买的inAppReceipt有所区别，将appReceipt发往服务器验证，如果回执的receipt中包含 “preorder_date” 字段，则表示是预注册的用户，由开发者自行处理预注册奖励的发货。 我个人相对来说更喜欢谷歌的方式，不需要在原有IAP验证及发货外特地开辟一块逻辑去处理最多只会跑一次的预注册，省时省力。 Unity IAP获取appReceipt可以参考：
var builder = ConfigurationBuilder.Instance(StandardPurchasingModule.Instance());
var appleConfig = builder.Configure<IAppleConfiguration>();
string receiptData = appleConfig.appReceipt;
|