阅读 2077

【吐血🤮】一次生产环境NPE崩溃的排查记录

直接说引起NPE的根本原因(有被自己菜到):

rx订阅没有取消,回调时Fragment已经被回收,引用view调更新方法,自然NPE。

就这?是的,就是这么简单的基础错误,我排查了一天,,rx订阅要取消这可是常识:

  • 要么引入生命周期管理;
  • 要么定义CompositeSubscription,在Activity、Fragment销毁时clear()
  • 要么单独取消订阅,RxJava2用unsubscribe(),RxJava1用dispose();

我以为的开发常识,却被老项目打脸,接着我来捋一捋事情的前因后果,望大家吸取教训,排查BUG时少走弯路,错误原因已经给出了,对排查过程不感兴趣的可以直接略过了~


0x1、阴差阳错解了另一个BUG

昨日早上十一点半+,打开疼讯视频,准备边看剧边干饭,结果组长钉钉甩来一个:

打开一看,我擦,刚上线的版本,爆了两千多次这个错误:

打开详细日志一看:

NPE,空指针异常,调用刷新组件的关闭刷新方法报空,排查下日志的其他部分,用 自己的写的脚本 去下混淆,看下是否得到更多有帮助的信息。

没有什么卵用,不过奇怪的是,这个BUG的报错数还在不断增加,却没有用户反馈这个问题。

集成测试测三轮没发现,我们自己自测也不复现不了。

只能看进行更多的日志排查,一条日志引起我的注意:

UnknownHostException: Unable to resolve host "xxx.xxx.com": No address associated with hostname
复制代码

然后报NPE,指向异常处理里的finishRefresh():

em?难不成错误处理的代码有问题?测试人员人手不够,漏掉 网络异常边界 测试也很正常,而且可能都不懂怎么 模拟网络异常和弱网情况

Charles 抓包模拟一波,定位到列表接口,下断点,请求后,直接把请求给 Abort 掉(丢弃):

果然应用崩溃了,心中窃喜,这么快就定位到了问题了?看下错误日志:

擦,怎么不是NPE,而是数组越界,看了下代码,原来是setEmptyView()后没有notifyDataSetChanged()一下。

好家伙,没解决BUG,却解了另外一个BUG,这...算是因祸得福吗?


0x2、真的是KAE的锅吗?

NPE的问题还没解决,但是 干饭要紧,下午睡醒再说,控件为null,隐隐觉得可能是 kotlin-android-extensions (后面都简称KAE) 的锅,因为以前也遇到过根据id获取View实例为空的情况,不过那是因为id重复,于是干饭前在群里问了下小伙伴:

大家都很热情地劝我不要用KAE,坑多,官方推荐ViewBinding,手写findViewById稳等,这些我都知道...

但是哪能说话就换,项目里那么地方用到了,而且换一个方式,并没有真的解决问题,起码得搞清楚问题发生原因吧...

午睡完,继续排查,直接源码看下KAE是怎么让你免去findViewById的,随手写个测试项目,写个TestActivity,里面引用下某个控件,依次点击 Tools → Show Kotlin ByteCode → Decompile

也是调 Activity.findViewById() 查找控件,没毛病,试试Fragment的情况:

和Activity实现方式如出一辙,唯二的区别是:

  • ① 调用Fragment的getView()方法的布局 (onCreateView返回的View);
  • ② 重写onDestroyView()方法,清空map中的实例;

你可能有疑问,为啥要在onDestroyView()里清空Map,而不是onDestory()里?

答:考虑到Fragment复用的场景,具体如下:

replace() Fragment 后会执行 onDestoryView(),而不是执行onDestory()完全销毁,目的是在销毁视图的同时,保留View状态和Fragment成员状态,下次加载时可以直接走onCreateView(),更快加载以达到复用的目的。

关于View状态的保存机制,笔者也不是特别了解,大概瞄下TextView的源码(onSaveInstanceStateonRestoreInstanceState),看到了实现Parcelable重写了一些方法,猜测是 序列化。而序列化和反序列化前后,对象实例是不相等的,此时Map里还保留这之前的键值对(id → 实例),此时根据id拿到的View实例肯定是不对的,所以这里做了清空操作。

所以这里也没毛病,所以不是KAE的锅,虽然这里不涉及,但也把Adapter情况如何findViewById也过一下~

KAE不支持直接在adapter里直接用,需要在build.gradle添加下述实验性配置:

// 主要是为了启用LayoutContainer   
androidExtensions {
    experimental = true
}
复制代码

而调用方式其实分两种,第一种是这样:

看下字节码转Java:

直接findViewById的,看看另一种,让ViewHolder实现LayoutContainer的方式:

看字节码转Java:

原理同样是创建一个hashMap来保存引用,通过ViewHolder传进的View进行绑定,真要在adapter里用KAE,建议使用第二种。

《Kotlin Android Extensions遭废弃,官方推荐使用ViewBinding》 一问中说到KAE的问题:

除此之外空间换时间,用一个额外的HashMap来存储View实例,更重要的是这部分内容对大部分使用者而言是黑盒,有时会踩上一些莫名其妙的"坑"。

官方提了一嘴使用ViewBinding替代KAE,其实就是启用ViewBinding功能后,AS自动为每个布局文件生成一个对应的Binding类,在里面完成View绑定(包含判空),文件输出目录:/build/generated/data_binding_base_class_source_out

具体玩法可以参见:《kotlin-android-extensions插件也被废弃了?扶我起来》


0x3、灵光乍现的瞬间

排查完不是KAE的锅,那到底是什么原因导致的控件为空呢?排查进展一下子陷入了僵局,只能从用户行为入手了,友盟上不知道为何看到不到用户的行为日志。

好在有自家全埋点,打开 Kibana,过滤错误类型日志,找到错误日志,获取deviceid,然后查询用户行为。

通过分析多个用户报错的情况,我发现了一个规律:

都是一次首页的Loading,然后崩溃,而距离用户上次打开APP的时间一般都会很久。

脑子里突然蹦出一个想法,该不会是因为APP被回收,重新打开Activity重建的问题把,因为APP中有一个跟很多APP一样的鸡贼操作,虽然提示了 "再按一次退出程序",但其实是调用moveTaskToBack()退到后台而已。

模拟APP被回收就简单了,AS跑下程序,来到出问题的页面,APP退到后台,直接在Logcat把程序干掉,接着重新打开程序,静待片刻,果然,崩溃了,看下日志信息:

好家伙,果然复现了,因为Activity重建导致的刷新控件为空,噼里啪啦跟组长解释一波崩溃的原因,然后应急处理方式就是调用前先判空,保证不崩溃先。

本来快到下班的点了(6点),正常情况应该是吃点东西摸鱼等下班了,不过没搞清楚引发这个问题的具体原因,回家也是念念不忘,索性加班排查下吧。


0x4、加班加点排查

涉及Activity重建,那估计也跟Fragment生命周期,Fragment多层嵌套之类的脱不了干系,在BaseActivity和BaseFragment中把生命周期相关的回调都加上日志。

页面的话三层嵌套:CustomerFragment → ThirdAgentListFragment → CustomerChildNewFragment

接着模拟崩溃,看日志输出结果分析:

不难看出Activity重建的时候把Fragment都恢复了,但是很快又销毁掉了,正常来说恢复Fragment的流程:

onCreateView() → onViewCreated() → onActivityCreated() → 各种初始化操作

这里却直接马上走onDestoryView()也走了onDestory(),发生这个原因其实是replace,看回代码:

调用FragmentManager的replace()方法,而正常两个Fragment走的生命周期(未调用addToBackStack):

  • 被替换Fragment:onPause() → onStop() → onDestroyView() → onDestroy() → onDetach()
  • 替换Fragment:onAttach() → onCreate() → onCreateView() → onViewCreated() → onActivityCreated() → onStart() → onResume()

所以,这里的实际逻辑是这样:

恢复的方式创建了Fragment → 创建新的Fragment → 替换掉Fragment → 恢复创建的Fragment被干掉

然后,我在Fragment的onActivityCreated()中又发起了一个请求,那就存在一种情况:请求发出去了,响应还没回来,Fragment就被替换干掉了,这个时候去调已经销毁的Fragment里的View实例,妥妥滴空指针啊!

一种看似取巧的解决方式:savedInstanceState(Bundle) 方法中判断参数是否为空,不为空就不加载请求:

当然,治本的方法肯定是从网络请求入手,当Activity或Fragment销毁时,需要把rx的订阅都取消掉,方法就是开头说的几种。

项目都四五年了,竟然一直没爆这个BUG,大概的原因是:

单Activity、多Fragment玩法,没有频繁的replace() Fragment的场景,而且大部分请求都有不可取消的Loading。

排查了一天,原来就是这样一个简单的BUG,前人挖坑,后人填坑,真是一口老血...

不过在排查过程中也收获不少:

  • 了解KAE不用findViewById的原理,以后可以放心使用了;
  • ViewBinding有个大概了解;
  • 对Fragment生命周期的验证(平时都是死记);
  • 了解了一下Activity具体重建机制;

就说这么多,解BUG之路道阻且跻,希望本文对你日常的Debug定位错误有所帮助,谢谢~


文章分类
Android
文章标签