天天开铺子修改教程_天天开铺子金币越花越有版[通俗易懂]

作者：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到以后某天才会被发现：外部传入回调参数，若是条件不满足时，也要根据实际情况来回调；若是外部并不特别关心这个回调结果，则可以不用调用。

为了验证分析结果，调试如图：