我先介绍Bugly的使用，然后再介绍友盟的使用，来比较这两个的优缺点，分析一下哪个SDK对于开发者更加友好。
一、Bugly的集成使用
-
注册账号，创建应用，获取Appid 和 Appkey这种基本操作我就不说了，下面才是重点。
Bugly01.png
- 集成SDK可以手动或者pods，官方文档写的很清楚，而且很简单。我们只要在，设置appid即可，在
APPDelegate中写上一段数组越界崩溃代码。
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[Bugly startWithAppId:@"d31aeda785"];
NSArray *array = @[@"1",@"2",@"3"];
NSLog(@"%@",array[3]);
return YES;
}
运行之后我们可以在Bugly的后台看到崩溃信息，大约不到一分钟，就可以在后台看到崩溃信息了。(这里请注意：这里在Bugly显示时间很短，可以说是即时的，因为这个方面要和友盟进行对比。)
但是我们发现，这里只能看到是因为什么崩溃了，并不能确定是具体哪个类哪一行报错，下面有请我们的符号表闪亮登场！！！
关于符号表请仔细阅读Bugly的官方文档，非常详细。
配置符号表有两种方法：1.自动配置 2.手动配置，在这里我只讲一下自动配置，以及一些需要注意的点，因为手动配置太麻烦，原谅我这么懒。。。-
注意点：
（1）当我们下载完 自动配置符号表工具包后，我们要将AppidAppkeyBundleId分别替换掉dSYMUpload.sh文件中的字段。将下面这两个字段的值全部改成1，不然会一直提示你，符号表未配置。
Bugly04.png
（2）当你用模拟器或者Debug模式运行，一定要注意文档中的这段话，我是将值都改成了1。
- Debug模式编译是否上传，1＝上传 0＝不上传，默认不上传
UPLOAD_DEBUG_SYMBOLS=0- 模拟器编译是否上传，1＝上传 0＝不上传，默认不上传
UPLOAD_SIMULATOR_SYMBOLS=0
再次运行后，当然也是崩溃，查看Bugly后台，很清晰的为我们分析出是哪一行出现错误。是不是很棒棒！！！
二、友盟错误分析
-
如果你对友盟的产品不是很熟悉的话，建议先看看新手上路
UM01.png -
同样很老套的注册应用获取appkey
UM02.png
然后下载SDK，根据文档集成
UM03.png
解压之后是下面4个文件夹，实在不明白只想进行错误分析，这添加的framework有点多啊。。。
UM04.png 初始化SDK，并且添加崩溃代码
#import "AppDelegate.h"
#import <UMCommonLog/UMCommonLogHeaders.h>
#import <UMCommon/UMConfigure.h>
@interface AppDelegate ()
@end
@implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[UMCommonLogManager setUpUMCommonLogManager];
[UMConfigure setLogEnabled:YES];//设置打开日志
[UMConfigure initWithAppkey:@"5ae870e88f4a9d72f70004d3" channel:@"App Store"];
NSArray *array = @[@"1",@"2",@"3"];
NSLog(@"%@",array[3]);
return YES;
}
就文档而言，感觉友盟的文档很乱，东西很杂，对于初次使用友盟的开发者来说可能会有一点麻烦，也许是因为友盟的产品太多了吧。
当我们运行完有bug的程序之后，在友盟的后台并没有及时显示出崩溃信息，我也就不等了，因为昨天就等了两个小时才在后台看到，友盟这效率有点低啊。
如果我们想看到底是哪一行代码引起的崩溃我们需要借助工具umcrashtool。下面开始说说如何使用。
点击这里可以看到错误工具的使用
具体分析我们需要两件东西，1.umcrashtool 2.错误列表的.csv文件
我们可以通过链接下载umcrashtool，关于.csv文件我们在哪里去找
在这里进行下载，在桌面新建一个文件夹crash，将umcrashtool和.csv文件一同放入crash中。
- (1)执行命令，cd 到
crash中
UM07.png
(2)输入./umcrashtool先不要敲回车，继续把.csv文件拖到终端中，注意：./umcrashtool 与.csv文件路径之间要有空格
UM08.png
此时回车，会出现下面的结果
UM09.png
红框内标识你的dsym文件并不是以69DA4615...命名的，那么这个dsym是在哪里找到的，我们在打包的时候，会生成一个Archive文件,Show in Finder，显示包内容找到BugDemo.app.dsym文件
UM10.png
UM11.png
UM12.png
UM13.png
UM14.png
此时我们发现.dSYM文件的名称和终端上要求的名称不一样，要将.dSYM文件命名为终端上的名称，（UM14.png是修改后的文件名称）再次执行上面的命令。
之前的警告就消失了，但是新的问题出现了，这里为什么没有具体显示哪一行有错误呢？通过查找资料发现，友盟关于数组越界这种bug并不能准确分析出是哪一行代码出现问题，so。。。刚才是白做了，此时心中一万只草泥马路过，看到这里的朋友不要打我，我是无辜的。
通过实际操作两者比较：
- 时间：Bugly可以堪称即时性，友盟。。等的我花儿都谢了；
- 定位准确度：从刚开的分析也可以看出，Bugly明显是优于友盟的；
- 操作难易度：Bugly可以进行自动配置符号表，但友盟只能进行手动操作，并且友盟的文档关于
umcrashtool的介绍使用说明并不是那么明显； -
友盟只能统计1000个错误，而Bugly并没有限制；
关于错误分析只是友盟的一个小分支，这里也没有贬低友盟的意思，只是对两者进行错误分析的比较，当然友盟的分享和统计做的还是相当牛逼的，有时间再讲讲统计，这个挺有意思的。
