iOS 关于Bugly与友盟的错误分析的比较

我先介绍Bugly的使用，然后再介绍友盟的使用，来比较这两个的优缺点，分析一下哪个SDK对于开发者更加友好。

image.png

一、Bugly的集成使用

• 注册账号，创建应用，获取Appid 和 Appkey这种基本操作我就不说了，下面才是重点。

  
  Bugly01.png

Bugly02.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显示时间很短，可以说是即时的，因为这个方面要和友盟进行对比。)

Bugly03.png

• 但是我们发现，这里只能看到是因为什么崩溃了，并不能确定是具体哪个类哪一行报错，下面有请我们的符号表闪亮登场！！！
  关于符号表请仔细阅读Bugly的官方文档，非常详细。
  配置符号表有两种方法：1.自动配置 2.手动配置，在这里我只讲一下自动配置，以及一些需要注意的点，因为手动配置太麻烦，原谅我这么懒。。。

• 注意点：
  （1）当我们下载完 自动配置符号表工具包后，我们要将Appid Appkey BundleId分别替换掉dSYMUpload.sh文件中的字段。将下面这两个字段的值全部改成1，不然会一直提示你，符号表未配置。
  

  Bugly04.png

（2）当你用模拟器或者Debug模式运行，一定要注意文档中的这段话，我是将值都改成了1。

• Debug模式编译是否上传，1＝上传 0＝不上传，默认不上传
  UPLOAD_DEBUG_SYMBOLS=0
• 模拟器编译是否上传，1＝上传 0＝不上传，默认不上传
  UPLOAD_SIMULATOR_SYMBOLS=0

再次运行后，当然也是崩溃，查看Bugly后台，很清晰的为我们分析出是哪一行出现错误。是不是很棒棒！！！

Bugly05.png

二、友盟错误分析

• 如果你对友盟的产品不是很熟悉的话，建议先看看新手上路

  
  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。下面开始说说如何使用。
点击这里可以看到错误工具的使用

UM05.png
具体分析我们需要两件东西，1.umcrashtool 2.错误列表的.csv文件
我们可以通过链接下载umcrashtool，关于.csv文件我们在哪里去找
UM06.png

在这里进行下载，在桌面新建一个文件夹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是修改后的文件名称）再次执行上面的命令。

image.png

之前的警告就消失了，但是新的问题出现了，这里为什么没有具体显示哪一行有错误呢？通过查找资料发现，友盟关于数组越界这种bug并不能准确分析出是哪一行代码出现问题，so。。。刚才是白做了，此时心中一万只草泥马路过，看到这里的朋友不要打我，我是无辜的。

image.png

通过实际操作两者比较：

• 时间：Bugly可以堪称即时性，友盟。。等的我花儿都谢了；
• 定位准确度：从刚开的分析也可以看出，Bugly明显是优于友盟的；
• 操作难易度：Bugly可以进行自动配置符号表，但友盟只能进行手动操作，并且友盟的文档关于umcrashtool的介绍使用说明并不是那么明显；
• 友盟只能统计1000个错误，而Bugly并没有限制；
  关于错误分析只是友盟的一个小分支，这里也没有贬低友盟的意思，只是对两者进行错误分析的比较，当然友盟的分享和统计做的还是相当牛逼的，有时间再讲讲统计，这个挺有意思的。