友盟与听云比较

码农十年，跟大多数程序猿一样，我的志向是开发一款没有Bug的App！！！但是理想很丰满现实很骨感。实现之路远没有那么简单~对于一款App产品来说，首先需要追踪最终用户的使用习惯收集需求，其次才是由程序猿开发实现，最后上线供用户使用。那么上线以后我们最关注的不外乎就是应用的稳定性了。很多Bug导致的直接后果就是应用卡死或者发生崩溃！！！那么，当Bug发生后如何复现用户的操作呢？这不仅是一个必须得完成的工作，同时也是一个很大的挑战，尤其是最让人头疼的崩溃！

众所周知的是：iOS、Android 两大智能系统都提供捕获系统崩溃信息的方法，但是如何获得这些信息以及如何挖掘分析信息又完全是另一回事，尤其当用户量大到一定数量的时候，很有可能每天都会面对产生的海量用户信息而手足无措。既然用户反馈对程序猿来说是一件头疼的事情，那么搭建一套收集并分析问题的系统就显得非常重要却又并不像想象的那么简单。这时候我们就要借助“第三方”来相辅相成了。对于App的崩溃监测来说，市面上做有不少提供类似服务的公司，那么今天我们就来讲讲比较有代表性的两家：友盟和听云

友盟是App 行为分析起家，主要是在App 中手动插入各种事件，App启动后会收集用户行为并自动上报，在报表端生成对应的系统报告，开发者就可以从中得到App 活跃设备数和App使用情况等信息。

听云是网络性能管理起家，最初是做网站性能管理，接着增加了App 的性能监控。虽然两者侧重点不同，但是都提供了App 崩溃分析的服务，可见这点对于移动用户开发者来说是一个非常重要的需求。

抛开各家所长不说，我们今天只在这里比较一下两家公司的iOS
App 的崩溃分析服务。

一、代码集成

1、 友盟

（1）到友盟官网注册账号，并添加一个新应用，以获取Appkey。

（2）下载友盟 SDK 并导入工程，也可以使用Cocoapods 安装SDK。

（3）在 AppDelegate.m 中添加如下代码，这里边可以添加对应的渠道号（channelId）。reportPolicy 是定义收集到的信息的发送策略，有 BATCH（启动时发送）和 SEND_INTERVAL（按间隔发送）两种。发送间隔除了可在代码中设置外，也可以在网页上进行配置。 -(BOOL])application:(UIApplication]
*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions

{

[MobClickstartWithAppkey:@"xxxxxxxxxxxxxxx"
reportPolicy:BATCH channelId:@“App
Store"];

}

2、听云

（1）到听云官网注册账号，在听云 App 首页中添加一个应用，以获取 Appkey。

（2）下载 iOS 平台的 SDK 安装包并导入工程，也可以使用Cocoapods 安装SDK。

（3）在 main.m 文件中加入如下代码

intmain(int
argc, char * argv[]) {

@autoreleasepool
{

[NBSAppAgent
startWithAppID:@"AppKey "];

return
UIApplicationMain(argc, argv, nil,NSStringFromClass([AppDelegate class]));

}

}

（4）听云还提供 crash 符号化的功能，你只需要上传对应 App 的 dSYM 文件就行了

3 、对比

两家公司的产品在集成的时候都非常简单，基本就是添加 SDK，写一行注册代码就完成了。

友盟由于是信息统计起家，所以提供了渠道这一功能。虽然对 iOS
App 来说，一般就 App
Store 一个推广渠道，但对于 Android 来说，因为市场很多，所以很可能需要知道 App 是来自哪个渠道。

听云最大的优势是提供了 crash 符号化功能，这样就可以在崩溃报告里直接看到出错的函数名，这对于开发来说是非常便利的。

打分（25分满分，下同）：

友盟：18（缺乏 crash 符号化功能）

听云：20（无渠道号这一维度）

二、崩溃报告

1、友盟

友盟的 App 崩溃报告主要有两个页面，一个是错误趋势，另一个是错误列表。

1.1 错误趋势



错误趋势给出了每天崩溃数量汇总消息，点击折线图中的每一个点，下方列表会显示出当天主要错误摘要，便于快速分析目前 App 的稳定情况。总的来说这是一个还不错的视图，但是在这张图里面，信息量太少，崩溃信息汇总的元素不够详细，看不到bug数量，影响的用户数量，这是比较欠缺的。

点击下方每一个错误后会进入到该错误的详细报告页面。这个我们后边再一起看。

1.2 错误列表



错误列表是对崩溃数据进行收集分析，提供了很多维度的排序过滤规则。比如你可以根据 App 的版本进行筛选，也可以将错误标记为已修复后，过滤掉所有已修复的崩溃报告，同时也提供针对 iOS 的版本以及设备的机型进行过滤。利用好各种过滤，将非常容易的帮你定位用户的具体问题。

但在这块，虽然错误筛选做的比较好，可是只是简单的罗列错误，意义并不大，看不到具体某条崩溃所反应的代码，那么在实际解决崩溃的过程中，可能就没办法很快去修复崩溃。同样，点击每一个错误后，也会进入到该错误的详细报告页面。

1.3 错误详情

这个页面主要展示了单一一个错误的所有详细信息，主要分为以下几个部分。



这里主要汇总了该错误的历史趋势，里边可以看到随时间变化的错误数量情况。



这部分是对开发来说最重要的信息，这里就是从设备中得到的 crash
log，开发利用这个数据，就可以还原崩溃的调用现场，非常有利于修复问题。不过遗憾的是，友盟没有提供 crash
log 的符号化，所以需要开发自己导出报告到本地，然后利用 Apple 的开发工具来手动符号化。



最后是基本信息部分，这里能看到错误的一些基本数据，比如首次发生时间，设备分布情况等。

2 、听云

听云的 App 崩溃报告集中在了一个页面，其中主要有如下几个部分。

2.1 错误概况



这一部分是崩溃发生的主要信息汇总。主要信息维度有 App 启动次数，崩溃次数，以及两者的比值-崩溃率。同时也支持基于时间和 App 版本的过滤功能。

2.2 错误列表



这一部分汇总了错误，以列表的形式展示出来，点击每一个错误后将进入错误详情页面。这部分呈现的比较详细，甚至可以看到具体由什么动作最终触发了崩溃都展现的比较详细。但这里有个明显的缺陷，即看不到1个bug在不同机型下的适配情况。

2.3 错误详情

这个页面展示了某一个错误的所有详细信息，主要分为以下几个部分。



这部分分为两块，一块是简单的信息汇总，报告了崩溃数量，修复情况等基本信息。然后是很有特色的崩溃轨迹功能。由于听云是性能监测出身，所以这里给出了在崩溃发生时，整个步骤的时间轨迹，虽然看起来上面的信息用处很大，但如果测试人员不按照以上的步骤进行操作，那么可能就不会发生相应的崩溃，因此人工操作起来工作量还是会比较大。



这部分就是设备崩溃时所收集到的 crash
log，听云对其进行了格式化，阅读性不错。当然同时也提供未格式化的版本供开发使用。如之前所说，听云支持崩溃的符号化，所以可以在这里就直接看到符号化后的版本。能够做出很好的提高开发的效率。



这里提供了崩溃发生的一些上下文信息，比友盟的信息量强一些，可以很好的看到发生崩溃的设备情况，以及运营商的情况，有时候这也会是一个非常有用的信息。除了以上2个信息，其他信息对崩溃情况的体现作用不大。

3 对比

3.1错误总览

友盟 20

听云 19

在这一项，友盟展示的更直观。听云不能根据设备机型以及操作系统来过滤错误信息，虽然在详情页面可以看到对应信息，但是有时是需要一个对应设备或者系统下的汇总信息的。听云包含有一个错误汇总报告，可以看到bug 数，崩溃发生次数，影响用户等，可以让你很简单的对 App 的总体情况有一个概念，友盟则缺乏这个统计，当需要建立一个总体概念时就要做一些数据收集工作。

3.2错误列表

友盟 19

听云19

两者都很好的完成了错误收集这个功能。不过友盟在错误的摘要信息上比听云略差一点，听云的摘要信息可以看到崩溃报告的第一行信息，友盟的摘要信息就有点简略，有时候需要进入详情页面才能明白是什么错误。

3.3错误详情

友盟 18

听云 24+1

两者都很好的收集了 crash
log，然而友盟不能符号化 crash
log 是一个弱点。

另外就是听云独有的崩溃轨迹是一个亮点，可以很好的看到是什么具体动作出发了崩溃，而友盟要得到同样的信息就必须得开发自己去分析 crash
log 了，这个真的算是一个很方便的内容，额外加一分我觉得不过分。

最后就是听云还有崩溃发生时的上下文信息，具体到设备剩余内存，设备剩余空间，用户设备接入的运营商等，友盟则缺乏这些相关信息，有时候上下文信息对定位问题是非常有用的。

三、总结

最后总得分，听云比友盟：83比75。总的来看，听云和友盟两家公司在崩溃报告服务上都完成度都比较高，都能很好的胜任工作，可以很大程度上减轻开发者的负担，而一些细节的处理上，两家各有千秋，至于分数上的差距都是累加过后的效果，我也不想为了平衡什么去修改，见仁见智吧。希望他们能继续进步，给开发者带来更好的服务。