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

原文出自【听云技术博客】：http://blog.tingyun.com/web/article/detail/777

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

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

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

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

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

“崩溃轨迹”介绍

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

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

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

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

案例1

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

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

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

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

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

案例2:

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

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

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

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

一文带你了解如何排查内存泄漏导致的页面卡顿现象（上） 不知道在座的各位有没有被问到过这样一个问题：如果页面卡顿，你觉得可能是什么原因造成的？有什么办法锁定原因并解决吗？
崩溃堆栈还原技术大揭秘 岳鹰全景监控平台，具备分布式的符号化系统，独有的C++崩溃堆栈还原，完美支持inline函数、行号还原。这样强大的系统是如何涉及到呢？本文为您揭秘！
系统诊断小技巧（11）：如何解决“问题复现了，但是捕捉数据进程因为CPU打满没有运行”？ 曾经搞过一个尴尬的案例。排查过一个CPU打满的问题。因为问题是在凌晨出现，而且非常随机。所以我们就准备了一个脚本，用来捕获占用CPU高的线程。但尴尬的是，问题复现了，我们的脚本偏偏在问题复现的时候，没有记录。