说到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
高级设置里居然还能有错误回调，
看到这个回调，我想到了知乎还是哪，有篇文章是：“如何让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/
ios开发交流群：486468672