一次线上bug的追踪

      最近快要过年了，项目上也不是很忙，就是做些修修补补的工作，下午组长给我一个任务，把我拉进一个风控部门建立的群。看了下问题描述：

       线上某壳拉新时大约有三分之二的新用户升级到2.3.0版本时上报的某盟id为null。接到这个任务后头脑里一片空白，竟然不知如何下手，线上apk没法调试，而且是偶现的bug。

        线上bug，能做的就是先下载线上有bug的apk本地安装，抓去启动log日志。这里抓取apk启动日志的方法在某想用过几次，但是这次遇到这个问题时却没有第一时间想到用这个方法，我先采用的方法就是将2.3.0本地代码更新到最新，本地运行却没有发现这个bug，试了好几个手机和复现bug的测试机都没有再现bug，当时我有点没思路了，虽然东哥和娜姐一再建议遇到问题要多思考，这时不知道是没有解决这类问题的经验还是没有过多的思考，就是毫无头绪。在一旁看着我解决问题的东哥说你把启动的log抓取出来看一下，当时我听了脑袋里竟然第一反应是线上apk的启动log日志，这怎么抓？ 真是傻逼了，以前用过好几次的方法这个时候竟然想不起来。看着东哥的操作，顿时觉得原来就是这个操作？mmp，到关键时候竟然忘的一干二净。

        拿到启动log，搜了一下启动优化同事埋下的log发现初始化和获取某盟id的逻辑是执行了的，当初我们还猜测是不是某盟id的逻辑由于不满足指定的条件没有执行呢，这下排出了这个猜测。使用某盟的包名搜索了一下log，发现中间还有获取某盟id过程中sdk抛出的异常信息，被我们捕获了。太高兴了，这下可以甩锅给数盟id了，我们把结果告诉数盟和东哥，东哥告诉我接下来验证产生这个问题的原因是什么，这这这。。。你要使用出问题的包的那套代码打包来分析问题，好吧继续追下去，我找到b端开发人员确认打线上包所使用的分支，便去拉分支代码打本地包试试看效果，我让QA给我打包的链接，我直接打的是线上环境的包，代码没有复现，我给东哥汇报了这个结果，线上包的代码打的release包没有复现bug, 和线上apk的区别就是没有加渠道号。东哥说你要比对一下两个apk的代码是否一模一样，包大小是不是一模一样。找b端开发人员确认了一下，原来我获取的代码不是线上出了bug的代码，而是后来又提交了部分代码后的master分支，b端人员通过tag找到了出问题的分支，然后我用这个分支拉了一个新的分支来测试。使用打线上包一样的步骤打了个线上包，本地测试bug没有复现，瞬间懵逼了，那就只能加渠道号了，联系了打渠道号的同事使用刚才的母包给我打了个渠道号包，本地运行，天啦，bug复现了复现了。我喜出望外，终于得出结论：打线上包没有问题，加了渠道号出了问题，这个锅是由于加渠道号导致的，看这回某盟怎么解释。

       第二天某盟派人来配合连调，首先我把上面的现象给他描述了一番，然后把我们的代码逻辑给他看了一下。然后他折腾了好久，也没说出个所以然就说要不你把代码的初始化恢复到2.2.0版本的样子，也就是把某盟的初始化放到Application.onCreate()里面，获取某盟id放在闪屏页，线上出bug的代码逻辑是将初始化和获取某盟id的逻辑一前一后，只是获取某盟id又开启了一个线程。初始化提前后打了线上渠道包，bug没有复现了，难道问题就出在初始化和获取某盟id放在一起的缘故？继续向东哥汇报进展情况。东哥听后，那你把初始化和获取某盟id都提前放在一起试试，结果bug又复现了，截止目前我们得出的结论是初始化和获取某盟id放在一块执行且开启了子线程同步调用某盟id出现bug。

貌似目前的解决方案有：

1. 初始化和获取某盟id不放在一块，但有获取失败的概率；

2. 使用某盟异步获取id的接口，稍微耗时影响前面的启动优化时间。

 

总结一下这次bug的完整过程：

1. 下载线上有bug的apk本地运行；

2. 抓取log日志；

3. 使用案发现场的apk本地调试，保证和线上环境一样，比如源代码、打包环境、渠道号、测试手机；

4. 对出现的问题，多种假设再验证归纳，找出root cause。