| 近日，有网友在国内知名移动开发社区发表帖子《听云App&友盟iOS 崩溃报告对比》，引起了网友们的热议。作为一名iOS开发者，作者对听云App以及友盟错误分析功能进行对比，从部署方式到报表解读，最后对听云App和友盟就崩溃功能进行了对比评分。作为国内老牌应用性能管理提供商，听云一直很关心用户的反馈，在此对该作者测评文章中对听云App的关注表示感谢。
但事实上，虽然该测评维度较为细致，或由于作者对听云产品使用深度还不够，文中相关细节内容存在一些事实上的错误，为了避免用户被不完整的信息进行误导，听云在此发表简单说明，对文章中较错误内容进行更正。
文章几个错误： 1、首先，作者在文章中称：听云汇总了错误，以列表的形式展示出来，点击每一个错误后将进入错误详情页面。这部分呈现的比较详细，甚至可以看到具体由什么动作最终触发了崩溃都展现的比较详细。但这里有个明显的缺陷，即看不到1个bug在不同机型下的适配情况。
可能本文作者并没有清楚的看到，上文里面提到的“看不到1个bug在不同机型下的适配情况”是不存在的。在这里，要向大家解释其实BUG与崩溃（Crash）并不相同。几个Crash可能是属于1个BUG。在听云App崩溃信息详情中,我们可以看到在1个BUG在不同 iOS下的分布情况，以及不同设备类型上的分布情况。
2、作者称：由于听云是性能监测出身，所以这里给出了在崩溃发生时，整个步骤的时间轨迹，虽然看起来上面的信息用处很大，但如果测试人员不按照以上的步骤进行操作，那么可能就不会发生相应的崩溃，因此人工操作起来工作量还是会比较大。
上图为听云App崩溃交互轨迹详情图。该功能可以打破传统崩溃监测工具只能记录视图之间跳转的劣势，它可以清晰地列举出发生崩溃时的控件、方法，帮助研发人员还原发生崩溃的每一步信息。
同时，通过崩溃轨迹我们可以看到崩溃发生前用户的操作步骤以及崩溃发生的时间、资源ID。比如用户点击了某一个按钮或在跳转到了某一页后，在某种情境下发生了崩溃。那么通过崩溃轨迹回放功能则能看到发生崩溃的具体视图、界面、控件操作，即发生崩溃的真实原因。
该测评称“虽然信息用处很大，但在还原崩溃轨迹时人工操作量较大”，这个说法有些片面。“交互轨迹复现”的核心在于能够完全还原崩溃发生时用户的操作轨迹，虽然在后期需要在排查时人工就崩溃还原进行操作，但由于信息搜集全面，此做法只需要简单的操作就能帮助技术人员第一时间找到崩溃发生的真正原因，及时对崩溃进行修复，以便减少损失的发生，人工操作量较大说法不太准确。
3、作者称：崩溃发生的一些上下文信息，比友盟的信息量强一些，可以很好的看到发生崩溃的设备情况，以及运营商的情况，有时候这也会是一个非常有用的信息。除了以上2个信息，其他信息对崩溃情况的体现作用不大。
事实上，这个说法并不准确。很多时候，崩溃的发生并不是由于代码层的问题，而是源于终端的硬件环境。如果只看到崩溃的堆栈信息而看不到与硬件环境相关的上下文信息，那么出现的问题就很难被找到。
尤其是测评中“只有设备信息和运营商情况才是有用的，其他信息对崩溃情况的帮助并不大”这个说法，丰富的辅助信息可以帮助我们看到终端的硬件设备情况如何，如发生崩溃时所在的设备、CPU型号、系统版本、运营商、剩余内存、CPU指令集、应用版本、接入方式、CPU用量都是非常重要的信息维度。
总而言之，听云非常欢迎大家使用听云全线产品并提供建议，并且也会汲取大家的建议以不断完善产品，但是为了避免用户被不完整的信息误导，我们会就产品描述中较明显的事实错误予以纠正，只为还原真实的听云产品原貌，让更多人认识到产品的真正价值。 |
