作者:scott
【天天开铺子】主程序,没事儿就撸个小游戏!
此文背景:
修改一个bug耗时几个小时,确实解决了调试中发现的另一个隐藏问题,但实际上并未解决该bug本身。而是经过几个小时后,看过一个复现视频才知道走偏了。于是有感!(有感的时候会很多,但有时间有心思总结的次数却很少。)
具体经历如下:
1、收到bug,如下图:
(图片上的字有点小,看这里:店铺中员工全部派出时升级店铺会卡死)
简单的文字描述,无日志、无截图、无录屏,无详细复现步骤。——(这是一种不良习惯)
2、根据上述描述不确定,因此找提供者确认步骤和关键信息,比如微信沟通:
3、经过多次沟通,并且有这个功能的开发者提供建议,感觉像是get到关键点:比如要把所有员工派出去再升级,似乎与店铺没关系。于是就第一个店铺开始,把人合成到可以升级的条件,这个过程刚好可以触发一个订单,只是派出去的人数不是全员。Ok,在关键地方打上断点,跟踪这个过程是怎么进行的,必要时再看数据。其中,跟到这里:
这个函数是将要派遣的员工类型和数量传递过来,因此要达到全员派出,这里的event.role是可以调试修改,比如改成event.role[5] = 6, 第一次合成可升级时刚好是6个店长; 原值是event.role[5]=4。经过这个调试,所有员工都走出去,并且出现’node of undefined’ 这样的报错,意思是某个对象不存在了,还在取上面的node属性。通常遇到很多很频繁的报错都会导致卡死。但是这一次在pc上调试时并没有卡死。于是在代码中写死上述调试代码,打包发布微信体验版测试。经测试,同样没有卡死,确实有报错。
4、至此,似乎解决了这个bug。顺带向其他同事分享、分析这个报错的原因。
截图说明修改前后对比,再分析原因:
5、再返回这个bug本身,说是要卡死,但是这边复测修改都没有,可能不是同一个问题,于是再次确认:
经过沟通,终于提供了一个视频
看了这个视频,才恍然大悟,确实不是同一个问题。走偏了。从准备开始修改这个bug下午五点多开始,到晚上八点多,消耗的时间比较长,几个小时过去了。
6、废话少说,根据视频反馈和视屏查看的日志,均不是什么报错导致的卡死。要来账号,调试身份登录尝试同视屏相同操作复现。
但是此时要求合成前面的员工,切换到要求的店铺还是类似要求。Ok,这种情况下是不可能正常操作去合成已达成条件的,于是断点,尝试通过修改内存值来绕过条件,如上图红色箭头:命中断点后修改this.isLevelUpEnable的值。
修改值:
可以成功绕过,于是发送相关事件后来到ui层处理:
注意红色箭头,这个是将事件拦截层显示出来,意在拦截在升级动画播放时的其他ui操作。此时要留意,这种操作若是不能顺利完成这个过程,则可能导致这个拦截层不消失而导致下层点击无响应。于是再联想到视屏中的反应,有点像。于是继续跟进下面的流程。比如什么地方将这个拦截层给隐藏的,通过本类搜索。
正好,相关接口就在附近,看样子是在各种回调之后执行隐藏事件拦截层。于是跟进函数内部看怎么实现的,很有可能回调没有被正常执行到。于是来到curShop.onShopLevelUp的实现:
仔细阅读这个函数的实现,想要外部传进来的cb被正常执行,则势必要执行_cb,如上图所示。在chrome中调试时,选中关键字,在ctrl+f 就会将相同关键字选中,即有个外框,如红色箭头处。再看具体逻辑,_cb要执行是有条件的,看箭头处的几处调用,再看视屏中反应的特点:无任何员工、顾客事件、订单派送员、广告推销员等,于是一目了然:这个_cb根本不会执行,因为条件不满足。至此,这个bug很明显了,也是一种常见bug,容易被忽视的bug,考虑不周或者测试深度不够,均容易埋藏此bug到以后某天才会被发现:外部传入回调参数,若是条件不满足时,也要根据实际情况来回调;若是外部并不特别关心这个回调结果,则可以不用调用。
为了验证分析结果,调试如图:
几处关键点都不满足,于是_cb确实没有执行。最后放开断点,如下图:
7、此时,并没有结束。再点击店铺升级和桌子附近区域,均无反应。此时很容易想到应该有什么地方事件被拦截了,于是去ccnode中断点,查看具体是哪个拦截了。
最后再2064行断住,查看this的值
确实印证了上面推测事件拦截层永久显示了。
8、有了上述这些分析过程,解决起来自然好办,其实该bug是一种比较低级的错误。解决如下:
即增加执行标记,到最后发现没有一处执行,则此时也要执行_cb,这样就能正常执行外部逻辑。如图:
升级完成,终于把事件拦截层隐藏了,逻辑正常了。
9、终于,招募可以再点击了
10、至此,这个bug应该是解决了,去除所有断点多次复测均未再出现视屏中的问题。到此,可以发布版本供验收者复测。
写在最后,小结几点:
1、统一几个概念,概念不统一,执行人的方向可能出错。
卡死:即因为什么原因导致整个游戏任何地方点击都无响应,不管怎么操作都不响应。一般都是由于代码出错或者内存严重不足,或者某个功能消耗巨大时间开销或者死循环,或者全屏事件拦截。
卡顿:因性能问题导致游戏画面不流畅,即一顿一顿的感觉。有时可见持续性的,也有间断性的。
区域性事件拦截或点击无响应:即部分操作点击了没有反应,但是其他地方还可以正常点击。
全屏事件拦截或点任何位置都无响应:这种也可能被当做上述卡死认定。
2、强烈要求提bug时尽量详细,如复现步骤、截图或录屏、最好能提供日志;
3、改bug时要多使用断点调试、修改内存值以满足条件、及时和bug详情确认当前所做是否是越来越接近bug的结论、或者和提bug者核实步骤和结论;
4、若是经过一番工作,确实也解决了调试发现的问题,但是是否是解决了bug,这也要及时确认;
5、开发人员注意逻辑严谨性、多自测;
6、测试人员要更深入的测试,最好能根据策划需求做测试用例,再根据测试用例对照测试,而不是只是表面走玩玩就罢了;
7、在确认问题时,若条件允许尽量当面沟通,文字的含义不同人理解起来分歧较大;
8、一边解决问题,一边总结问题,不断优化工作流,达到一个目的:用最少的人力时间干出最有价值的事情。
——刀锋scott 2020.2.25
本文分享自 Creator星球游戏开发社区 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!