|
移动应用早已不再是某种结构单一、功能简单的工具了。随着网络环境变得越来越复杂，移动应用变得越来越庞杂，此时我们便需要借用监测工具，来定位APP发生的各种性能问题，尤其是初创团队产品上线后首先面临的第一关卡——由于代码问题或内存溢出等原因造成的APP崩溃。崩溃监测之所以很重要，是因为它跟用户流失直接挂钩，用户流失的话就跟你的投资、收入都是挂钩的，所以每个开发者都应该对它非常关注。 目前市面上已经有不少崩溃监测工具可供APP开发团队选择。但事实上，并不是所有APP崩溃监测工具都具备一款好工具具备的技能。如果作为一个APP的开发者，你想知道产品上线后的崩溃情况，崩溃发生后如何快速找到原因，你一定要知道一款监测崩溃的工具应该具备哪些好的技能。。 崩溃监测为什么需要呈现完整、详细的堆栈信息？ 在传统的崩溃监测中，我们通过堆栈信息往往能看到崩溃是发生在系统级的，很多时候是由于应用程序代码产生了问题。而对于Android系统来说，如果想将崩溃信息完整的呈现就需要将堆栈实行反编译（反混淆）的机制，而对于iOS平台则是需要实行符号化机制。如果不进行类似的操作，那么呈现的信息便是不完整的，只有将堆栈信息还原成真实的信息，才能够清楚地了解崩溃发生的真实原因。 在这里，完整的堆栈信息则是指： 1、堆栈信息不能丢，必须要完整的抓到信息 2、抓到的信息要包含应用崩溃的代码，同时也需包含系统信息，比如将崩溃还原后就要看到是系统底层的问题，还是业务代码的影响出现崩溃的 3、将崩溃信息进行还原，即对iOS系统下发生的崩溃进行符号化，Android则需进行反混淆 崩溃发生后，丰富的辅助信息能帮你做什么？ 有时候，出现崩溃并不是因为程序写的有问题，而是由于终端的硬件环境出现了问题。如果此时只看到堆栈信息而看不到辅助信息的话，那么问题就很难被找到。通过辅助信息，我们看到终端的硬件设备情况如何，比如发生崩溃时它所在的设备、CPU型号、系统版本、运营商、剩余内存、CPU指令集、应用版本、接入方式、CPU用量等多种信息维度，即多种情景信息。 崩溃发生后，为了可以及时修复，为什么需要轨迹回放？ 大多数情况下，开发者通过监测工具已经抓到了崩溃信息、辅助信息，但是崩溃是在什么情况发生的，都不得而知。但事实上开发者在抓到崩溃后，除了希望看到代码层面的问题，同时也希望看到表层问题，如崩溃是如何发生的，怎样才能将崩溃发生的场景进行很好的回放。如果此时崩溃监测工具拥有交互轨迹复现的功能，那么就可以按照用户的操作轨迹实际进行操作，这样的话就可以排除兼容性的问题，了解发生崩溃的真实原因，对崩溃发生的情景感同身受，及时对崩溃进行修复，最大力度减少关键业务的损失。 听云App崩溃交互轨迹复现 通过崩溃轨迹可以看到崩溃发生前用户的操作步骤、时间及发生崩溃时的资源ID。比如用户点击了某一个按钮或者在跳转到了某一页后，在某种情境下发生了崩溃。那么通过拥有交互轨迹复现功能的崩溃监测工具则能看到发生崩溃的具体视图、界面、控件操作，即发生崩溃的真实原因。在听云App报表中，用户可通过崩溃汇总、版本分布、设备分布、操作系统分布4个维度以及崩溃率、崩溃数量、启动次数3个指标查看应用的崩溃情况。 总之，一款好的崩溃监测工具首先应该是方便易用的，其次是支持多种崩溃类型的，它具有丰富的周边信息，有一个完善的统计管理功能，可以很好的进行bug管理，最重要的是它可以将崩溃的交互轨迹进行复现，帮助开发者及时将崩溃进行修复，最大限度减少用户流失及关键业务的损失。 正如老罗曾说，时下并不是资本寒冬期，而是产品寒冬期。作为一个初创团队，除了产品可用性、创意、功能外，如果产品上线后崩溃率高的话，那么竞争力就会被打大削弱，这是一个非常重要的软件质量的问题，因此就决定了选择一款好用的监测功能非常有必要。
|
