Part1背景

周二晚上上线了新版本，在周三早上收到产品反馈，说用户在结算页点击提交订单支付不了，并附上了视频

Part2分析

既然是崩溃，那还不简单？去听云上看上报记录，不过有点蹊跷的是听云并没有上报该异常（这里怀疑听云出问题了，又人为去触发异常，发现是可以上报的）。

好吧，既然没有崩溃日志，那就只能发动脑筋猜了：1、机型适配问题；2、后台个别商品数据问题！接下来就是尝试复现了，通过后台同事找到用户的 usercode，同时去神策上查用户的操作以及上报数据，查到用户的手机型号，然而我们并没有同型号的测试机

那就只好上云测去验证了，验证发现并不会出现异常，排除第一个猜测。继续验证第二个猜想，找出用户下单的商品，用同样的商品及数量去下单，也正常，排除第二个猜测。

还好之前的版本解决奔溃后，新增了不少日志上报，接下来就只好看我们之前为了帮助定位问题上报的 log 事件'androidDev_log_Error', 'androidDev_log_Debug' ，结合这两个事件，加上上面的异常视频，基本确定崩溃是在接口请求之前就发生了。后续就反复的看代码，带着不信任的目光看每一行代码，大概能够确定是在点击提交订单的时候，我们为了埋点上报到神策，在进行数据组装的时候出现了异常。问题到这里进行不下去了，只知道这一块有问题，但又不知道哪里有问题。很不幸的是到 10 点多以后，BD 通过产品又陆续反馈有用户加不了购物车，幸运的是云测有上报，而且是上报了同一个异常

有日志了就好办了

可以看到是这个类 PitLocationManager 现了异常，而这个类正是处理上报数据坑位的，结合混淆后的 mapping 文件定位到是在解析的时候出现了问题，目标类型是 int，但是碰到了一个""空字符，所以导致了异常

同时了解到新版本对 DetailStatParams 这个类的字段有改动，去掉了 string 类型的 recommendtag，加上了 int 类型的 recommend_product_type 字段

（这里不要纠结命名规范，因为这些字段是数据组定的）

可以确定的是就是因为这个改动导致了问题，但是为什么会出现这个问题还是一个很大的问号。因为即使有这个改动，原有的本地缓存有 recommendtag 字段也不会影响，新版去除这个字段就不会去解析，而 recommen_product_type 由于老缓存没有这个字段，解析出来也会是默认的 0，似乎也就不会出问题。同时下午测试有台机器可以复现这个问题，但由于是 release 版本，看不到日志，所以安装了一个 debug 版本，因为覆盖安装并不会影响缓存数据，可是神奇的是，装上 debug 版本后异常又消失了。现在问题找到了，可以解决，但又没解决。为了不影响用户使用，下午的时候出了一个新版本的包，开始给应用市场审核，但并没有给用户强更，同时观察神策和听云的数据。直到晚上，1.1.4 版本也没有任何异常，看神策数据也有用户通过 1.1.4 下单购买成功，但这也并不能说明什么，因为这个问题本来就是很少的用户会出现。问题也就只能这样了？

Part3复现

到周四的时候，去神策上查看 1.1.4 的上报数据，因为在这个版本我们新增了 log 来确认问题，其中有一条就是会上报用户的缓存，正好我们看到了几条异常的缓存数据

这几条数据有两个问题：

1. 有实体被混淆了，正常来说实体不应该被混淆；
2. 这两条数据的 f 值类型不一致，一个是 string，一个是 int；第 2 个问题就佐证了听云上报的异常，现在我们来看第 1 个问题，既然是混淆了，那么我们就看 1.1.2 和 1.1.3 的 mapping 文件，这是一个混淆映射文件

我们可以看到，在 1.1.2 版本 recommendtag 混淆成了 f，是 string 类型；在 1.1.3 版本 recommend_product_type 也被混淆成了 f，是 int 型。所以 1.1.2 缓存的 recommendtag 会被解析成 recommend_product_type，由于类型不对，所以报错了。既然我们知道是这个数据问题引起的，那么用户这些数据是怎么来的呢？联想到只有少数的用户有这个问题，我们推测应该是我们发版当日用老版本操作引起的。在周二我们后台发了版，去掉了 recommendtag，而用户用 1.1.2 版本去加购了，那么缓存的 recommendtag 自然就变成了""，所以等到我们强推 1.1.3 的时候，再去操作就碰到了这条数据，引起了异常。既然有了这个推测，那我们就很好复现了，先用 1.1.2app 加购，然后再用 1.1.3 版本加购，两个版本都加上混淆，果然问题出现了，看日志

跟听云以及神策上报的数据表现一致，至此整个问题就清楚了，同时也确认 1.1.4 版本这个问题解决。

Part4总结

整个排查过程其实是非常曲折，因为正常场景下是不会现，但是用户侧又有多个用户有这个问题。所以只能一步步推测，一步步验证来解决这个问题。到周四 1.1.4 版本强推后，周五已经没有崩溃上报，这个问题总共影响 10 个用户。其实问题并不深奥，但找到问题的来龙去脉才是最关键往往也是最困难的，解决bug的过程就像是破案，一点一点的找线索，合理假设验证，最终找到那个真相并解决。