个人最近踩的坑

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#这边多参数事件初始化的报错

[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 :0
  at XLua.OverloadMethodWrap.Call (IntPtr L) [0x00000] in :0
  at XLua.MethodWrap.Call (IntPtr L) [0x00000] in :0
  at XLua.StaticLuaCallbacks.FixCSFunction (IntPtr L) [0x00000] in :0
  at XLua.DelegateBridge.PCall (IntPtr L, Int32 nArgs, Int32 nResults, Int32 errFunc) [0x00000] in :0
  at XLua.DelegateBridge.__Gen_Delegate_Imp30 (IMessage p0) [0x00000] in :0
  at SDGame.MessageManager.ExecuteAction (System.Collections.Generic.List`1 actionList, IMessage message) [0x00000] in :0
  at SDGame.MessageManager.ProcessMessage (IMessage message) [0x00000] in :0
  at SDGame.MessageManager.SendMessage (IMessage message, Boolean autoRecycle) [0x00000] in :0
  at SDGame.ReceiverManager.Notify (SDGame.Reflect.Rsb rsb) [0x00000] in :0
  at SDGame.NetworkManager.OnRecvMsgNormal () [0x00000] in :0
  at SDGame.NetworkManager.Update () [0x00000] in :0
stack traceback:

——————————————————————————————
[14:57:33:836]
[Error]  at XLua.LuaEnv.ThrowExceptionFromError (Int32 oldTop) [0x00000] in :0
  at XLua.DelegateBridge.__Gen_Delegate_Imp30 (IMessage p0) [0x00000] in :0
  at SDGame.MessageManager.ExecuteAction (System.Collections.Generic.List`1 actionList, IMessage message) [0x00000] in :0
  at SDGame.MessageManager.ProcessMessage (IMessage message) [0x00000] in :0
  at SDGame.MessageManager.SendMessage (IMessage message, Boolean autoRecycle) [0x00000] in :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去取值也不会报错的。

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

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

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

本文标题:个人最近踩的坑

文章作者:zhutaorun

发布时间:2020-09-06, 20:23:25

最后更新:2020-09-06, 20:31:18

原始链接:http://zhutaorun.github.io/2020/09/06/个人最近踩的坑/
许可协议: “署名-非商用-相同方式共享 4.0” 转载请保留原文链接及作者。

你可能感兴趣的:(工作反思,Debug,游戏开发)