不能“倒带”的监测工具怎能是真正的BUG杀手？

当你开发了完一款APP后，其实你的苦日子才刚刚开始，开发、测试、上线、再开发，总有你躲不过去的坎在等着你。问题往往更容易发生在APP上线以后，各式各样的BUG、错误、崩溃躲也躲不掉，这时候你也许会想，用点工具来减轻工作压力吧。然后你打开浏览器输入 “APP优化工具”、“BUG监测工具”、“崩溃监测工具”，铺天盖地的免费的、开源的、收费的工具映入你的眼眶，你试了又试，用了又用，时间花掉了，但真的有用吗？

其实也不能说完全没用，如今我们市面上很多BUG监测工具确实是可以帮助技术人员监测APP的崩溃情况的，但是他们都有一个共同也很明显的特点——只能统计。他们都会简单的告诉你：“亲，你在10点有1000个用户发送了崩溃哦~”，然而这并没有什么用，当你再回头去寻找问题的根源时，有可能客服也会给你带来同样的噩耗：“有人投诉崩溃啦！”。那么问题到底怎么解决。

其实我们稍作分析就能得出答案，我们先来看看目前市面上的崩溃监测工具都有哪几种：

第一种肯定就是最简单的崩溃统计，类似崩溃率、用户分布、次数等多维度数据展示，这是崩溃统计的最基本功能，所有的同类工具都有。

在此基础上更进一步的便是带有崩溃日志收集并简单分析功能的工具，这算是进阶的功能，但是收集上来的Crash log如果不能符号化，也没有什么用。

最后一种便是今天我们想要说的真正崩溃大杀器，现在市面上绝大多数监测工具都不具备的重要功能——将崩溃发生时的场景复现，能够神奇“倒带”的听云App崩溃轨迹复现功能，这才是真正的BUG杀手。

崩溃轨迹复现——第一时间找到崩溃发生原因

APP出现崩溃后，开发者对于崩溃的原因往往并不十分明了。如果此时可以将崩溃场景进行还原，了解崩溃发生的真实原因，那么便会第一时间对崩溃进行处理和修复，减少用户流失。在过去，通过监测后台的报表只能看到崩溃报告，但却无法了解到手机在何种环境下发生了崩溃，那么此时如果能将交互轨迹进行复现，即把用户交互轨迹还原，则能看到发生崩溃的具体视图、界面、控件操作，即发生崩溃的真实原因。

在听云App报表中，用户可通过崩溃汇总、版本分布、设备分布、操作系统分布4个维度以及崩溃率、崩溃数量、启动次数3个指标查看应用的崩溃情况。

用户可进入Bug摘要可查看具体崩溃信息，从应用启动时间、崩溃时间、应用版本、SDK版本、操作系统版本及设备型号等几个维度看到发生崩溃的交互轨迹。崩溃交互轨迹的实现极大的节省了研发人员的时间，一针见血地解决了问题，极大的缩小排查崩溃的范围。

听云App的交互轨迹复现功能打破了只能记录视图之间跳转的功能劣势，可清晰列举出发生崩溃时的方法、控件，帮助研发人员还原发生崩溃的每一步信息。

反混淆——发现崩溃真实面貌

除了崩溃发生时的场景外，当用户希望找到崩溃的堆栈调用情况时，如果没有反混淆文件，即dSYM文件（iOS称为符号表），那么捕捉到的崩溃异常是经过混淆的，也就是说无法得到真实崩溃发生时的代码地址。在听云App的控制台中，用户只要将iOS（符号表）或Android（Mappingfile）文件上传到报表端，便可对堆栈信息进行反混淆、符号化，看到真实的堆栈异常信息，同时不存在地址偏移。

由于堆栈本身是经过步步调用的，那么在发生崩溃后便可通过反混淆功能得知具体是由于调用的步骤、方法，执行代码的具体信息导致的崩溃发生，以此看来崩溃原因一目了然，反混淆功能对于研发人员具有重要意义。

也许你看完了对“倒带”功能的神奇还不够了解，其实你可以自己真正来尝试一下，只需要几步就能够让你的App完成“倒带”：

(参与链接：https://account.tingyun.com/cas/login?service=https://saas.tingyun.com/j_acegi_cas_security_check?loginView=casLoginTingyun)

下面教你如何有效快速使用听云App崩溃功能

1、 登陆报表查看APP健康状态

2、 点击查看崩溃详情

3、 查看崩溃历史纪录

4、 进入Bug分析，查看崩溃详情

5、 崩溃轨迹复现，帮助研发人员复现崩溃发生的场景

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!