Activity销毁延迟10s执行回调的踩坑之路

现象

某一天应用出现bug,看日志后,发现activity回调onstop和ondestroy很慢,导致单例持有的资源未及时释放。经过测试,发现在7.0以及以上版本系统,A界面跳转B界面后(B可以是任何界面),点击返回键等回到A界面,B执行了onpause后,等了10秒B界面才会执行onstop和ondestroy。

分析问题:

由于我是一个首页的子fragment,所以一开始怀疑继承项目的basefragment被人写了啥,然后对比其它几个子fragment的代码,没发现差异,然后看承载fragment的主页activity,仍然没有。之后注释大数据埋点等一些acitivity里的耗时动作,所有onstart和onresume方法都注释了,仍然不行。最后把fragment的列表注释不加载,发现不出现延迟了。然后排查数据刷新动作以及绑定,最后开始注释掉适配器的adapter的bind方法,ok,无bug了。然后逐步恢复代码,最后发现是下面的代码导致的onstop延迟10秒,最终定位到adapter里,有下面AnimationUtils代码导致的。怀疑是系统7.0后从缓存里取出A界面的view重新绘制到界面时有什么优化改动,然后AnimationUtils影响到了。
初步推测:是A界面离开onpause后,没有停止循环动画。

开始验证:

1.方案1在activityA里,放一个控件循环动画,然后启动B,此时再从B返回,看是否B界面等了10秒才触发onstop
2.方案2扩展思路验证,在B界面放置一个循环动画,然后离开界面时不停止,看是否会导致B界面onstop出现延迟10秒左右才触发。


Activity销毁延迟10s执行回调的踩坑之路_第1张图片
image.png

上图中模拟的是1,A界面TransparencyActivity启动B界面MainActivity,然后16:01:10.578离开MainActivity,看日志已经恢复TransparencyActivity。但是等到16:01:20.607才开始走onstop和ondestroy。验证动画确实影响界面销毁成功,那么解决方案很明显了。
模拟2发现一切都正常,日志如下。


Activity销毁延迟10s执行回调的踩坑之路_第2张图片
image.png

解决方案

离开界面A时要停止循环动画,然后从B界面返回时,B的生命周期才会正常。
由于离开界面A时要停止循环动画,所以再次从B返回A界面时,需要恢复动画。

总结

7.0以上系统开启动画后,在离开当前界面onpause一定暂停动画,不然会影响当前界面跳转的下一级页面B的销毁,会造成B页面离开onpause回调后,10秒后才触发onstop和ondestroy。至于源码目前还未探索,如果有后续查阅,会更新本文。

你可能感兴趣的:(Activity销毁延迟10s执行回调的踩坑之路)