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

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

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

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

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

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

“崩溃轨迹”介绍

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

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

下图是一个崩溃轨迹，先来认识一下：

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

案例1

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

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

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

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

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

案例2:

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

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

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

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

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