DateTime时间戳计算

一言蔽之，通常使用DateTime计算时间戳，起始时间点为UTC时间1970年1月1日0点整，需手动设置一个基准DateTime来处理。

DateTime StartDateTime = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

IAP相关问题

1. 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现象的时候，非常的心虚及自闭，如果可以，谁又想放着问题不管呢）

2. 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

3. 谷歌和苹果不同的预注册奖励策略：

谷歌的方式比较简单粗暴，开发者这边为预注册奖励申请一个额外的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;

4. 示例文件IAPDemo中存在的bug：developerPayload

在下用的是unity 2019系列，目前IAP能更到的最新版本是2.3.0，无法更新到传说中的3以上版本，所以不知道3以上这个问题是否还存在。如果是跟着官方的这个实例文件做IAP系统尤其是订阅系统的话，在Android端会遇到调用下文代码始终返回错误的bug。注意从warn处开始的代码，对developerPayload字段进行了验证和处理，然而谷歌商店已经将这个字段废弃且置为null，所以···你懂的。
解决方法的话，一种是自己copy这段代码去用的时候去掉任何关于developerPayload的处理，另一种是通过某某手段自己添加该字段到数据里并保证能通过验证，一般来说要验证订阅其实并不太需要这个字段，所以用前一种方式也没什么问题。

private bool checkIfProductIsAvailableForSubscriptionManager(string receipt) {... // some codes hereif (payload != null ) {switch (store) {case GooglePlay.Name:{var payload_wrapper = (Dictionary<string, object>)MiniJson.JsonDecode(payload);if (!payload_wrapper.ContainsKey("json")) {return false;}var original_json_payload_wrapper = (Dictionary<string, object>)MiniJson.JsonDecode((string)payload_wrapper["json"]);// !!warnif (original_json_payload_wrapper == null || !original_json_payload_wrapper.ContainsKey("developerPayload")) {return false;}var developerPayloadJSON = (string)original_json_payload_wrapper["developerPayload"];var developerPayload_wrapper = (Dictionary<string, object>)MiniJson.JsonDecode(developerPayloadJSON);if (developerPayload_wrapper == null || !developerPayload_wrapper.ContainsKey("is_free_trial") || !developerPayload_wrapper.ContainsKey("has_introductory_price_trial")) {return false;}return true;}... // some codes her}}return false;}

ContentSizeFitter及其嵌套导致的RectTransform尺寸计算不正常

排除全手算的大佬，相信UGUI用得多的朋友都遇到过这个问题，为了保证动态添加的组件排版美观，常用各种LayoutGroup及ContentSizeFitter，界面复杂度高了，横的竖的不同版面的，难免会产生嵌套，这时候如果需要第一时间操作高层组件的transform（比如在下遇到的一个需求就是，进入ScrollView界面后自动滚动到指定位置），往往获取的rect值是尚未计算好的，有点糟心。单个节点的话，最直接的解决方法是，对需要计算的RectTransform trans 调用：
LayoutRebuilder.ForceRebuildLayoutImmediate(trans);
但嵌套的根本问题在于子节点的Fitter计算并不一定在父节点之前，只处理父节点同样无法同步计算出最终的大小，所以目前想到的方法是获取子节点的所有Fitter，给它们全刷一遍，最后再刷需要的这个节点。参考代码如下：

        public static void RefreshContentSizeFitter(Transform target){ContentSizeFitter[] fitters = target.GetComponentsInChildren<ContentSizeFitter>();foreach (var fitter in fitters){LayoutRebuilder.ForceRebuildLayoutImmediate(fitter.GetComponent<RectTransform>());}LayoutRebuilder.ForceRebuildLayoutImmediate(target.GetComponent<RectTransform>());}

TMPro处理本地化字体，中日文编码相同问题

当专家告诉我，日语本地化的汉字有问题的时候，我整个人都惊了，深感自己的塑料日语不愧如斯完全没有注意到。
首先这是在同一客户端下做本地化才可能会有的苦恼。TMP通过FontAsset渲染字符，当首选asset找不到对应字符时，会顺序查找Fallback List列表，直到找到第一个有编码的asset并使用，否则显示方框。这里插一嘴，有的字符显示一片空白连方框都没有，至少说明编码是在字体里面的，可以试试在FontAsset里面调整该字符的位置或者重新渲染看看。
那么最最吃瘪的问题在于，对于大部分字体的编码来说，中文和日文的部分字符都是一样的。具体文字的外观由该字体是中文字体还是日文字体而定。所以TMP去查表的时候，如果中文的asset排列在日文asset之前，那对应编码就永远会显示中文写法了。
解决办法：设置本地化的时候根据语言重排首选FontAsset的Fallback List。我这边主要是在lua端绑定操作的asset，同时使用的是xlua中间件，代码大致如下，因为是套用旧的字体文件，为了避免某些字符丢失，只是交换了中文日文的顺序。
虽然没有那个精力去处理，不过这个思路可以扩展开来：基于TMPro，如果在同一个客户端下想做优质的语言本地化，也许可以使用一个字符少甚至空白的首选FontAsset，每种语言单独维护某种特定风格的字体，并包含所UI需要的全字符，在设置语言的时候就只需要添加该asset到fallback列表就行了，如果包含用户输入，最多再添加一张通用的全字符的asset。这样就能避免字符风格不统一的问题。
当然如果有更好的处理办法也欢迎读者不吝赐教。

LuaTable variables = fontTable.GetComponent<LuaBinder>().GetVariables();List<TMPro.TMP_FontAsset> fallbackList = new List<TMPro.TMP_FontAsset>();// add other assetsif (language == "Japanese"){fallbackList.Add(variables.Get<TMPro.TMP_FontAsset>("jp"));fallbackList.Add(variables.Get<TMPro.TMP_FontAsset>("cn"));}else{fallbackList.Add(variables.Get<TMPro.TMP_FontAsset>("cn"));fallbackList.Add(variables.Get<TMPro.TMP_FontAsset>("jp"));}// add other assetsvariables.Get<TMPro.TMP_FontAsset>("base").fallbackFontAssetTable = fallbackList;

单选Toggle实现UI显示的切换

基本的使用方式是，对某个组件A添加Toggle Group组件，需要的单选框组件添加Toggle组件，并将属性的group绑定到组件A，这么一来同一group的Toggle就是互斥的了。
Toggle包含一个isOn的属性，来表示该组件是否处于选中状态。那么自然而然的，设计ui的时候就会想到，将需要显示的默认值勾选，其他的不勾选，进去不就该是默认状态了吗？然而实际与期望并不一样，在编辑模式下勾选没有任何的作用。那么操作就变成了通过代码来设置默认组件的isOn值。但是就我接触的代码来看，不少人都在设置isOn的基础上手动再给ui赋值到默认状态，而这对绑定事件的Toggle来说是完全没有必要的。先看看Toggle切换的源码吧：

void Set(bool value, bool sendCallback = true){if (m_IsOn == value)return;// if we are in a group and set to true, do group logicm_IsOn = value;if (m_Group != null && IsActive()){if (m_IsOn || (!m_Group.AnyTogglesOn() && !m_Group.allowSwitchOff)){m_IsOn = true;m_Group.NotifyToggleOn(this, sendCallback);}}// Always send event when toggle is clicked, even if value didn't change// due to already active toggle in a toggle group being clicked.// Controls like Dropdown rely on this.// It's up to the user to ignore a selection being set to the same value it already was, if desired.PlayEffect(toggleTransition == ToggleTransition.None);if (sendCallback){UISystemProfilerApi.AddMarker("Toggle.value", this);onValueChanged.Invoke(m_IsOn);}}

一开头就找到了编辑模式下勾选没用的罪魁祸首，在已经赋值的情况下运行起来自然是不会触发事件的了。那么反过来讲，只要编辑模式不勾选，且对isOn赋值并非使用SetIsOnWithoutNotify方法的话，就必然会触发事件。
那么比较合适的使用方式就显而易见了：首先在编辑模式下不勾选任何Toggle的isOn，并且ui组件都设置为默认非勾选状态；然后代码里绑定事件，之后再将对应默认显示的Toggle的isOn设置为true，all over. 这样下来代码就只需要关注ui元素是怎么切换的，默认显示的赋值交给事件去触发，结构清晰简洁。

Unity个人开发中的踩坑记录（混沌式更新）相关推荐

Laya小游戏上架Vivo平台踩坑记录（持续更新）
Laya小游戏上架Vivo平台踩坑记录(持续更新) 个人踩坑的一些记录,大佬留情! 一些快捷键: Ctrl+P 搜索脚本文件 Ctrl+Y 恢复操作 Ctrl+Z 撤回操作 Ctrl+F 搜索字段 C ...
Laya小游戏上架Oppo平台踩坑记录（持续更新）
Laya小游戏上架Oppo平台踩坑记录(持续更新) 个人踩坑的一些记录,大佬留情! 一些快捷键: Ctrl+P 搜索脚本文件 Ctrl+Y 恢复操作 Ctrl+Z 撤回操作 Ctrl+F 搜索字段 C ...
微信退款 java工具类,微信支付中退款踩坑记录
首先附上微信支付的开发者文档其实这里所说的踩坑记录,无非就是微信在开发者文档上的写不太明确,也没有比较官方的demo,在此列出一个可行的demo,供大家下载使用. 主要问题就是在这几步解密上微信的 ...
uniapp开发聊天APP踩坑记录
最近工作重心转移到了uniapp上,有一说一,这个框架跨端确实牛逼,一套代码能一次编译到多端使用.但随之而来的兼容性问题也是层出不穷,同样的在面临APP底层的改动也显得力不从心.同时,uniapp的性 ...
开源大数据开发平台DataSphereStudioLinkis踩坑记录
Linkis:https://github.com/WeBankFinTech/Linkis DataSphereStudio:https://github.com/WeBankFinTech/Dat ...
德卡D3读卡器C#开发中的填坑记录
记录德卡D3读卡器的一些小坑.公司近期项目有IC卡的读写需求,买的是深圳德卡的D3U,开发语言用的是C#.帮助文档上写的动态类库函数与asp demo上有很大的区别,如果你也是用C#开发(Java d ...
安装KeOps过程中的踩坑记录
由于需要跑一篇论文的代码,需要安装KeOps.这里忍不住再吐槽一次:Python开发环境的版本依赖管理太混乱了,加上各种操作系统,驱动,CUDA版本等等,太浪费生命.所以,如果要写论文,发布open ...
uni-app 开发安卓app踩坑记录
uni-app离线打包android -- 官方文档 Android studio打包apk后弹窗提示"打包时未添加ui模块" 在工程应用目录的build.gradle文件中bui ...
flutter boost使用简介（踩坑记录，持续更新）
前言最近在研究android和flutter的混合开发.插件模式调用原生的混合模式已经在项目中使用,也暴露出一些问题, 最突出的问题就是flutter中对webview的支持,会出现各种各样奇怪的问 ...

Unity个人开发中的踩坑记录（混沌式更新）