说到crash上传工具,大家肯定会第一时间想到umeng,不错,umeng 是最早推出 crash 上报的工具之一,在刚推出来的时候,特别受到ios开发人员的喜爱。
因为个时候,内存是手动管理的,很容易发生重复是释放内存导致crash,所以umeng的这个工具能够上传已经发布的产品的crash 日志,非常受开发者喜欢。 虽然现在苹果推出了ARC了,解放了iOS开发人员的内存管理工作,但crash还是不可避免的。
umeng推出 crash上报工具有3年多了,主题核心功能基本没做大的改进,最近因为需要实时查看crash 日志,对,是实时,希望app crash 后,能够马上看到错误,方便解决crash问题,发现了bugly工具(这个工具还是腾讯提供的,大公司提供的,不会像小的创业团队,随时会关闭),
以下是对umeng crash 和 bugly 做的一些对比分析
1. crash 日志上报的及时性方面
umeng的太慢了,需要1-2小时才能显示当日的bug,而且有**,每天只能**1000个 crash 日志,bugly 宣称的是实时,经过我的测试,比较及时,基本在1分钟之内就能看到bug 的错误
从错误的及时性来收,bugly 完胜。
2. 错误筛选功能
看下2个页面的bug 赛选对比
umeng: 版本,类型,以及uuid,操作系统等
我们来看看 bugly的
版本,类型,机型也可以选择,我最喜欢的功能是用户功能,红色标记的地方,因为你可以设置一个id,比如用户id,uuid等,而不像umeng只有uuid。
查找bug 方面,bugly要稍微方便些。
3. 错误的定位
基本上2者都能提供的比较详细,但是仍然有些错误的提示信息不够,相应的堆栈信息显示不全。
umeng 提供了错误定位工具:详细请查看网址,
http://dev.umeng.com/analytics/reports/errors#2
基本步骤是:
(1)将错误导出csv文件
(2)下载umeng crash分析工具:umcrashtool
(3) 在terminal中运行umcrashtool,提示如下: Usage: umcrashtool [export-file-path],定位后的代码及行数会写入错误分析-symbol.csv文件,与原文件在同一目录下。用工具打开新生成的xxx-symbol.csv文件,便可查看错误发生的源码文件及行数。
步骤有点麻烦,来看看bugly是怎么解决的
在 产品->设置->版本管理 可以上传符号表。
我没有上传过符号表,但是看到这个功能,是不是感觉很贴心, 不用自己下载工具,分析。
bugly还提供自动上传符号表功能,可以在编译后,自动进行。
具体的功能在bugly高级设置里 http://bugly.qq.com/iosmore
高级设置里居然还能有错误回调,
在异常发生后进行调用,应用可以设置回调函数,并在回调中保存异常现场信息等信息,异常现场等信息可以通过 getCrashXXX 接口获取
使用示例:
static int exceptioncallbackhandler() { NSLog(@"Crash occur in the app"); [... setAttachLog:@""]; return 1; }
exp_call_back_func=&exception_callback_handler;
看到这个回调,我想到了知乎还是哪,有篇文章是:“如何让app 实现优雅的奔溃” 在app 奔溃的时候,提示下用户:由于不可预知的问题,导致程序奔溃,我们深表歉意。这样用户体验是不是很好!
错误定位来看,还是bugly来的方便。
从总体对比来说,bugly还是不错的,做的相当深入 ,umeng 更定位在统计分析,而crash 上报这块没投入太多的精力。
但是bugly也有问题:
(1)产品稳定,靠谱不?
刚推出好像不到2个月吧,看看宣传
手机QQ,qq浏览器 ,各种游戏什么的都接入了,你相信吗?我是不相信的 。
没有被认可的第三方出名的应用采用这个工具,其稳定性,不晓得。
上百万,千万的用户的应用,使用之前最好还是慎重。
最新消息,据说,滴滴打车,唯品会也使用了这个
(2)会导致app增加多大?
应用接入会导致app 有多大的增加,因为基本上所有的应用都使用了umeng ,统计是刚需,里面已经有个crash 上报了,再接入这个bugly 会导致ipa 增加多少,起码要有个数据。
整个静态库有5.1M,应该增加的app的大小比较小吧,这块没对比过,应该不超过100K吧。
文章来源:http://appask.cn/article/7
相关链接:
umeng http://www.umeng.com/ 接入umeng统计,自动开启crash
bugly http://bugly.qq.com/