最近线上测试，发现有2个C（概率复现，对玩家没什么影响）级BUG给到我，虽然一直也有出现，但没找到原因。因昨天打包电脑换工位，外面也刮风下雨。宅在家写点内容。小结下最近看到自己所犯的错误。

一、线上C级BUG

表现：可领取的特效没显示，显示上2/2,也没显示已经领取的打勾显示

分析：看到单子的那一刻，我分析下，我觉得逻辑上，加载对应的特效的肯定没写错。那方向锁定了特效的被UI的层级内容挡住了。看了下是SortingOrder出错了，看了之前的代码，当时为了方便还特地取了当前的界面的canvas,但是获取地方错了，因为在设计上延迟卸载会有UI层级的重新排序。如果放在Open函数中就能决解问题的。

解决方案：在要加载的Node界面中，获取当前打开界面的View，再获取Canvas。规避因UI排序的造成的影响，也让代码可读性提高了。明确这个Node是哪个View的子节点。

二、赛季奖励界面，低概率报错

策划需求，2个PVP活动，要支持热更新，要支持配置多个赛季

程序设计上：一张表分为2个部分请求，一次是框架表的内容，一次是用id关联具体的奖励信息。有依赖关系和先后关系。

表现：有时有的新帐号，打开界面报错。

第一次QA报告过来，觉得是配置问题，让服务器查了配置解决发来的部分是没问题。我觉得是初始化的问题。加了对应的代码保护，作为一个低概率复现的bug给了QA。QA把单子关掉了。

第二次QA报告过来，Unity可以复现这样的表现，但QA复现的情况是，在修改服务器时间（切换赛季的时候出现）。再切换服务器时间，又不复现。

有点陷入困局。逻辑上没问题，函数初始化也做了保护。看到一行UIScorllView的报错，传入数据是null的话，是收到服务器返回协议的时间不对。加了收到两条协议的时间打印。验证我的思考方向，时间打印顺序不对。一般来说都认为服务器协议是队列的，先进先出。这两条协议和服务器交流下来，因为第一条协议内容更多，回来的慢一点。

决解方案：在两条协议都确认收到后刷新界面。

三、开蛋的动画停的帧不对

UE需求：三个蛋分别在不同时间里晃动，0-3、3-6、6-9；
在一个蛋播放完砸开的动画后1s,其他2个也播放砸蛋动画

表现：第三个蛋的砸蛋动画，所停在帧是不对的

分析：播放动画和动画样的代码都没问题，还找同事帮忙确下动画相关的代码没写错。第二天有找另一位同事帮忙看。是协程的问题的。

我个人习惯觉得StartCoroutine(method())比StartCoroutine(“method”),在代码友好和可维护上比后者好。误认为对应的停止函数StopCoroutine(method())和StopCoroutine(“method”)，其实前者这方法是错误的，并不能生效。

决解方案：用StopAllcoroutines()有点粗暴。
正确的写法是
coroutine mCoroutine = Startcoroutine(method())；
StopCoroutine( mCoroutine);

看官方API
public Coroutine StartCoroutine(IEnumerator routine);
public void StopCoroutine(string methodName);
public void StopCoroutine(IEnumerator routine);
public void StopCoroutine(Coroutine routine);
用的时候没看，有点想当然了。

四、龙玉升级当从1级直接升级到9级龙玉的时候会出错

表现：从1级直接合成9级龙玉，显示上扣除数量是对的，但报错了，服务器判断不能升级，并把龙玉扣掉了。如果重新登录，对应扣掉的龙玉又返还回来了。

分析：客户端显示的计算是没错，服务器在返回失败的情况，不应该扣除龙玉。QA复现，服务器定位收到协议数据，我发过去的数据计算错了。
解决方案：为嘛在升9级时候报错，因一种龙玉的最大堆叠数为999,而升9级的超过了，跨堆计算数量的时候，数值减错了。

反思：之前写过类似的代码代码优化,不请记得自己当时是什么状态，但确实不够细心。还是非常感谢QA耐心帮忙测试。对于线上版本影响不大。挨个试，才确定了复现方式。

五、组件的显示不对

表现：根据阵营不同，对应特效的不同节点显示和隐藏。

分析：收到的数据是有没有出错的，分析原因是组件和数据之前关联，那一步出错了。
目前也没有定位到具体问题出在了哪里了。

下周继续死磕了。

更新 : QA后来稳定复现异常的情况。在FadeIn的时候，字典处理当时没理清楚。
处理前的代码

1
2
3
4
5

if(value!= NUll &&!Dic.ContainsKey(key)
{
   Dic.Add(key,value);
   ChangeEffect(key,value);
}

处理后的代码

1
2
3
4
5

if(value!= NUll)
{
   Dic[key]=value;
   ChangeEffect(key,value);
}

完美解决问题了。
反思：通过打印日子看逐步Log才确认问题了。dic加新Key之前先判Key后加入，确实之前养的好习惯。主要还是缺少对于这个地方返回出现FadeIn的情况理解。

六、总结

工作中都会犯错，但通过复盘让自己减少犯同类似的错误，来最大化提高效率。从过去的经验中学习，形成自己遇到新问题解决的方式。

例如重新这个情况，却有三种不同情况出现。一种是卡顿重连，一种是下线重连还有一种是顶号换端重连。