利用“崩溃轨迹”分析崩溃

版权声明:如需转载请联系听云College团队成员小尹 邮箱:yinhy#tingyun.com

“崩溃,严重伤害用户的情感,严重损害用户体验,罪恶行径简直令人发指,特请xx狮、xx猿火速缉拿案犯归案,刻不容缓,钦此。” 

虽然在“听云App”等类似优秀工具的帮助下,大多数的崩溃都能快速的、轻易的定位问题,如图: 

1.png

上图所示,已经定位到某源文件的某行,再加上崩溃message,崩溃的原因就显而易见了。 

但有些崩溃的原因就不是那么显而易见了,往往需要寻找更多蛛丝马迹来定位问题,要不然也谈不上什么“分析”了。 

本文用两个例子说明“崩溃轨迹”在分析崩溃过程中的重要作用。 

“崩溃轨迹”介绍

遇到难分析的崩溃时,最想得到的信息是:用户当时是怎么操作的?如何能复现崩溃? 

“崩溃轨迹”也即“交互轨迹”,它记录的是崩溃前若干连续的用户操作。利用这些操作,或者能复现崩溃(这是最理想的),或者帮助缩小嫌疑范围。 

下图是一个崩溃轨迹,先来认识一下: 

2.png

好了,我们通过两个例子进一步了解“崩溃轨迹”的作用。 

案例1

今年4月21日,我们的一家客户发现他们的app发生了大量的崩溃,崩溃率很高,其中一个bug导致的崩溃占了总崩溃的63%,可是从堆栈上看不出有价值的信息,如图: 

3.png

我们帮客户分析时发现,这个堆栈没有反映出崩溃的原因,对于分析没有什么帮助。 

这时我们把眼光投向“崩溃轨迹”,如图: 

4.png

请注意,最后两个动作的时间都是“1秒前”,而且触发的函数也一样……猜到啥情况了吗?这是app的使用者快速连续操作了。基于这个推断,我们与客户一起,按照这个轨迹操作,果然,在那个界面只要快速连续点击,必崩! 

能复现就好办了,直接联机调试,问题立即解决。 

案例2:

这个例子是几天刚发生的,栈信息如图: 

5.png

同样的,也是崩溃堆栈只有main函数,也是一头雾水,但崩溃轨迹提供了重要信息,请看轨迹: 

6.png

最后一个操作发生在崩溃前0秒,这意味着崩溃就发生在那个函数里,这一下子范围小多了!虽然这个崩溃不是必现,没有按照轨迹复现出来,但因为“嫌疑”范围就在那几行,客户的开发人员很快就想到了问题所在。 

通过以上两个例子介绍崩溃轨迹的重要作用,希望对大家有帮助。 

想阅读更多技术文章,请访问听云技术博客,访问听云官方网站感受更多应用性能优化魔力。

关于作者

杨凯

我是一段代码

我要评论

评论请先登录,或注册