版权声明:如需转载请联系听云College团队成员小尹 邮箱:yinhy#tingyun.com
“崩溃,严重伤害用户的情感,严重损害用户体验,罪恶行径简直令人发指,特请xx狮、xx猿火速缉拿案犯归案,刻不容缓,钦此。”
虽然在“听云App”等类似优秀工具的帮助下,大多数的崩溃都能快速的、轻易的定位问题,如图:
上图所示,已经定位到某源文件的某行,再加上崩溃message,崩溃的原因就显而易见了。
但有些崩溃的原因就不是那么显而易见了,往往需要寻找更多蛛丝马迹来定位问题,要不然也谈不上什么“分析”了。
本文用两个例子说明“崩溃轨迹”在分析崩溃过程中的重要作用。
“崩溃轨迹”介绍
遇到难分析的崩溃时,最想得到的信息是:用户当时是怎么操作的?如何能复现崩溃?
“崩溃轨迹”也即“交互轨迹”,它记录的是崩溃前若干连续的用户操作。利用这些操作,或者能复现崩溃(这是最理想的),或者帮助缩小嫌疑范围。
下图是一个崩溃轨迹,先来认识一下:
好了,我们通过两个例子进一步了解“崩溃轨迹”的作用。
案例1
今年4月21日,我们的一家客户发现他们的app发生了大量的崩溃,崩溃率很高,其中一个bug导致的崩溃占了总崩溃的63%,可是从堆栈上看不出有价值的信息,如图:
我们帮客户分析时发现,这个堆栈没有反映出崩溃的原因,对于分析没有什么帮助。
这时我们把眼光投向“崩溃轨迹”,如图:
请注意,最后两个动作的时间都是“1秒前”,而且触发的函数也一样……猜到啥情况了吗?这是app的使用者快速连续操作了。基于这个推断,我们与客户一起,按照这个轨迹操作,果然,在那个界面只要快速连续点击,必崩!
能复现就好办了,直接联机调试,问题立即解决。
案例2:
这个例子是几天刚发生的,栈信息如图:
同样的,也是崩溃堆栈只有main函数,也是一头雾水,但崩溃轨迹提供了重要信息,请看轨迹:
最后一个操作发生在崩溃前0秒,这意味着崩溃就发生在那个函数里,这一下子范围小多了!虽然这个崩溃不是必现,没有按照轨迹复现出来,但因为“嫌疑”范围就在那几行,客户的开发人员很快就想到了问题所在。
通过以上两个例子介绍崩溃轨迹的重要作用,希望对大家有帮助。