【天天开铺子】BUG修改记

作者：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