一. 问题描述
在几天前,现场技术反馈应用的支付二维码是过期图片(上一笔交易记录的支付二维码).并随时甩了一堆的日志.于是一场耗费4、5天的战斗正式打响.
二. 问题分析
由于版本正在改版阶段,逻辑确实发生了一些变动,初步分析，认为是由于过期的二维码刷新延迟导致用户扫到了前一笔订单的支付二维码信息了.但分析日志后,发现问题并没有那么简单.
1.一般情况下以现在的网络条件.2、3秒内就可以完成二维码的刷新操作.
2.分析日志.
GetInCarDataByOutCarNoRequest>>>{parkid=0, outDspIp=172.19.2.3, serialType=0, outCarNo=xxx, etcNo=000000, extParam=}
....
接口没有返回值,同时拿了后台的日志,也没有任何请求信息.可以发现请求没有被服务器所接收.并且客户端没有任何的异常信息记录.
3.现场有些机子反馈没问题，有些机子反馈有问题.(10台机子,2台运行过程中就不再显示二维码了).
三. 问题排查过程
这让我陷入了两难的境地,深入排查出问题的逻辑方法也看不出什么异常.
我们决定在该请求接口中埋点日志
在主要的调用方法上补上了try/catch,希望能够获取到异常信息
通过对比稳定版本,我们决定取消引入multidex分包(该方案主要解决64K方法数限制问题)
但是很遗憾的是,在以上的努力之后,我们的问题依然在发生,BUG仍在肆孽
是的（主要是Google自家的图片加载引擎Glide 3.7.1,特别注意.回退后的版本在加载GIF图片时存在闪烁的问题.在不跳大版本的情况下推荐使用3.8.0）.
基本已可以确认是第三方库的问题.但是为什么日志上显示不了呢?.在一次无关紧要的复现过程中,激发了一个想法.是不是还有其他地方消费掉了异常信息呢?经过排查EventBus自行消费掉了异常.但它又没强制处理.导致异常无故消失。
void invokeSubscriber(Subscription subscription, Object event) {
try {
subscription.subscriberMethod.method.invoke(subscription.subscriber, event);
} catch (InvocationTargetException e) {
handleSubscriberException(subscription, event, e.getCause());
} catch (IllegalAccessException e) {
throw new IllegalStateException("Unexpected exception", e);
}
}
private void handleSubscriberException(Subscription subscription, Object event, Throwable cause) {
if (event instanceof SubscriberExceptionEvent) {
...
} else {
if (throwSubscriberException) {
throw new EventBusException("Invoking subscriber failed", cause);
}
if (logSubscriberExceptions) {
logger.log(Level.SEVERE, "Could not dispatch event: " + event.getClass() + " to subscribing class "
+ subscription.subscriber.getClass(), cause);
}
if (sendSubscriberExceptionEvent) {
SubscriberExceptionEvent exEvent = new SubscriberExceptionEvent(this, cause, event,subscription.subscriber);
post(exEvent);
}
}
}
可以看到.出现一些异常的情况下,它会处理一些感兴趣的异常,但是不强制用户去处理.我们丢掉的就是这块内容的异常了.(当然截止目前,SubscriberExceptionEvent异常已经会被处理).
四. 经验总结
- 该问题正好进入了我们遗失日志的阴暗角落,给我们排查问题上增加了很大的麻烦.总让人不知所措(超出个人的认知)，无从下手.出现问题的时候,日志是我们最主要的依靠手段.善待日志也是善待自己.
- 做好第一点的情况下，出现大海捞针的情况就会变少.但即使出现了.静下心去排查那些看似无厘头的BUG.
- 遇到无从下手的问题时,又赶上急需发版确实是一种折磨.该版本测试流程已经走完.但是在测试环境上始终无法重现.为定位问题所在增加了很大的困难。通过日志以及领导争取的现场测试环境为该问题的的最终解决带来了很大的帮助.逐渐缩小排查范围.
- 理论上第三方依赖库高版本会修复低版本发现的问题.但是同时也会引入新的问题.特别是跨版本升级.就目前来看应该是在使用新版本Glide(4.3.1)导致引入BUG(但尚无精确判定).所以在使用第三方库时，尽量事先查看该版本修复的BUG,以及issue列表.