6月份初稿，在6月-8月遇到的问题,总结反思.也是目前都已经解决掉的问题

一、半圆组件初始化显示异常

在用一个半圆组件。让item分布在恰当的位置显示，只有一个的时候居中，有2个时候在偏移30度的地方显示。但是打开界面第一次的时候，位置总是异常。
当时UE加组件的时候，并不清楚要这样。只是让2个角中一个显示就行了。后来UE告诉要程序控制一下组件。

看了给外部调用的组件，就一个RefreshAll()函数，很简单。但界面打开第一次就异常了。当时着急回家参加好兄弟的婚礼，就没细去看组件的代码。
婚礼结束回来看了下代码，关键点在activeInHierarchy。

这里补充下相关的官方内容:

根据注释，引擎已丢弃active用法，并推荐我们使用activeInHierarchy和activeSelf

activeInHierarchy（read only只读）表示gameobject在场景中的是否显示，也就是说要使这个值为true，这个物体及其所有父物体(及祖先物体)的activeself状态都为true。

activeSelf（read only只读）代表gameobjectin的inspector中的checkbox是否被勾选

一个物体要在场景中是可见的（不是隐藏的），那么不仅仅其本身的activeSelf要为true，其所有父物体(及祖先物体)的activeself状态都要为true。

总结：

activeInHierarchy状态代表物体在场景中的实际的active状态。实际上代表的是物体及其所有祖先物体的activeSelf状态。而activeSelf对应于其在inspector中的checkbox是否被勾选

activeSelf状态代表物体自身的activeSelf状态，所以当物体本身activeSelf为true，而其所有祖先物体的activeSelf状态不全为true时，这个物体的activeInHierarchy状态为false。

activeSelf==物体自身
activeInHierarchy==物体自身及其所有父节点==物体在场景中实际上是否激活

如果在不改动组件的情况，对于一些节点的activeInHierarchy，要保持正确，需要调整下一些节点SetActive(true)的先后顺序。在和写组件的人聊了下，确实改成activeSelf更好一点的。activeInHierarchy 对于外部调用的代码很严格。任何一个没管理到就会让显示异常出现了。

二、特效的layer设置

写了通用的加载一个特效加载接口的。在取得GameObject的后要设置下Layer，在设置特效的sortOrder后，有时不用掉代码设置Layer，特效显示也是正常的，后来就去掉一些设置Layer的。

最近在测试的分支中，特效却显示异常了，看不到了。确实要设置Layer，为嘛同样的代码，为嘛分支却出现问题有点无法理解。

还是要设置一下layer层因强制肯定是对的，确保效果是正确的。还是有点没搞明白为嘛会出现。

三、C#这边多参数事件初始化的报错

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

[Error]c# exception:Attempting to call method 'SDGame.ClientMessage::SendMessageOneArg' for which no ahead of time (AOT) code was generated.,stack:  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  at XLua.OverloadMethodWrap.Call (IntPtr L) [0x00000] in <filename unknown>:0
  at XLua.MethodWrap.Call (IntPtr L) [0x00000] in <filename unknown>:0
  at XLua.StaticLuaCallbacks.FixCSFunction (IntPtr L) [0x00000] in <filename unknown>:0
  at XLua.DelegateBridge.PCall (IntPtr L, Int32 nArgs, Int32 nResults, Int32 errFunc) [0x00000] in <filename unknown>:0
  at XLua.DelegateBridge.__Gen_Delegate_Imp30 (IMessage p0) [0x00000] in <filename unknown>:0
  at SDGame.MessageManager.ExecuteAction (System.Collections.Generic.List`1 actionList, IMessage message) [0x00000] in <filename unknown>:0
  at SDGame.MessageManager.ProcessMessage (IMessage message) [0x00000] in <filename unknown>:0
  at SDGame.MessageManager.SendMessage (IMessage message, Boolean autoRecycle) [0x00000] in <filename unknown>:0
  at SDGame.ReceiverManager.Notify (SDGame.Reflect.Rsb rsb) [0x00000] in <filename unknown>:0
  at SDGame.NetworkManager.OnRecvMsgNormal () [0x00000] in <filename unknown>:0
  at SDGame.NetworkManager.Update () [0x00000] in <filename unknown>:0
——————————————————————————————
[14:57:33:836]
[Error]  at XLua.LuaEnv.ThrowExceptionFromError (Int32 oldTop) [0x00000] in <filename unknown>:0
  at XLua.DelegateBridge.__Gen_Delegate_Imp30 (IMessage p0) [0x00000] in <filename unknown>:0
  at SDGame.MessageManager.ExecuteAction (System.Collections.Generic.List`1 actionList, IMessage message) [0x00000] in <filename unknown>:0
  at SDGame.MessageManager.ProcessMessage (IMessage message) [0x00000] in <filename unknown>:0

在内网用PC包测试，是没问题的。但安卓手机包上，出错了。梳理下是有4个参数的事件方法，是客户端没有调用过，C#这边没有初始化过。Lua那边直接调用，会出错的，因为还没有Invoke。

System.action，4个参数的方法，在.net4.6上不会报错。因为打包机是.net2.6，会对引用库进行裁剪，打包机报错了。以为是代码裁切的问题的,重新出手机包看还是报错。

原因是IL2CPP中无此参数实例的代码，在这里调用一下以保证此泛型参数的方法存在。

解决方式是代码不做裁切，同时手动调用一次。解决初始化报错的问题。后来确保新的版本包没问题搞到凌晨2点多才回去的，这包大概是6月底先游测试要给出去的。

后来需要用4个参数的方法，被替换用的成Lua事件，我做了架构调整，这种情况也就不会出现的了

四、PVP活动攻略要塞，据点占领状态出错了

跟踪数据解析下来是ourGroudID是12个位数字id，解析协议内容使用int去解析的，Json解析报错，导致接下来的部分都出错了。在单个服务器是不可能的出现，因为不会有那么多场比赛。但是上线后就不行了。

pvp活动的groudID，随着上线后玩家不断的玩，int32被迅速耗完了。而在做的时候完全没想到这个问题。客户端用int32来解析JSON的数据的，如果超过int32,解析就会一直失败的。所以能做的就是在主线处理，分支如果有需要进行hotfixed

后续遇到新的问题，因为初始化的写-1，对应脚步的lua是int32，客户端直接用int解析是没问题的，但现在改成了int64解析就会报错。这是LitJson在数值的情况下是判断是不是int，再判断是其他类型的。

项目中用的LitJson，可以先判断数据类型，在用对应数据类型就解析就行了。当然也看到有人修改这一块的代码，及时用long去取值也不会报错的。

五、设计上没有考虑到跨时区玩家的处理

那会造成一些海外玩家在玩游戏的时候是在错误的时间去玩，而活动没开启。而活动开启的时候却活动结束了。准确来一开始我以为是过度设计，其实是有真实的其他时区玩家反馈。

在通用的函数来加入时区的换算就可以解决了。获取当地的时区和东八区相差就可以解决问题了。