没有代码,就没有bug。程序员在编码时,总会比不避免的出现bug。倒不是因为我们热爱制造bug,创造机会和测试妹子频繁沟通。而是现实情况很复杂,存在着很多不确定性。尤其是那些崩溃从stacktrace上来看,完全想象不到和项目代码之间的直接联系。
在我们的项目崩溃中,有一个比较常见的bug,就是 java.util.concurrent.TimeoutException android.content.res.AssetManager.finalize() timed out after 10 seconds 意思简单明了,就是说在AssetManager析构的时候发生了超时异常。
是的,道理我都懂,可是AssetManager不是我写的啊,这不是Android Framework的东西么,而且在stacktrace中丝毫看不到我项目代码的堆栈信息。这简直是无从下手。遇到这种情况,我们就需要从崩溃后台手机上的信息去分析产生的原因了
出现场景 10s的超时其实是很大的一个值,一般的析构方法很难执行时间达到这个数值,那么就要分析一下这个问题的特征,来总结一下出现场景了。
针对分析了这类的崩溃的数据,不难会得到几个特征
从Stack Overflow上找到了一个相对比较合理的出现场景
注意:应用后台执行的时间越长,出现的概率应该就会越大。
这个问题,并不像NPE那样,可以快速定位解决,甚至来说,这个问题几乎无解。
理论上可能有帮助的措施是
但是这些措施,对于解决该问题起到的作用很微小。
凡事总有但是,但是我们可以缓解这个问题造成的影响。
所谓缓解之法,就是让崩溃悄无声息地发生,不影响用户体验,做到用户无感知崩溃。
前面也提到了,因为这种崩溃只出现在后台,我们可以对于这类的崩溃,稍作处理,就可以让崩溃的对话框不显示。具体可以参考这篇文章Android中实现用户无感知处理后台崩溃
以上。感谢下面的参考文章