我先介紹Bugly的使用，然后再介紹友盟的使用，來比較這兩個(gè)的優(yōu)缺點(diǎn)，分析一下哪個(gè)SDK對于開發(fā)者更加友好。

image.png

一、Bugly的集成使用

• 注冊賬號，創(chuàng)建應(yīng)用，獲取Appid 和 Appkey這種基本操作我就不說了，下面才是重點(diǎn)。

  
  
  Bugly01.png

Bugly02.png

• 集成SDK可以手動(dòng)或者pods，官方文檔寫的很清楚，而且很簡單。我們只要在，設(shè)置appid即可，在APPDelegate中寫上一段數(shù)組越界崩潰代碼。

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [Bugly startWithAppId:@"d31aeda785"];
    NSArray *array = @[@"1",@"2",@"3"];
    NSLog(@"%@",array[3]);
    return YES;
}

運(yùn)行之后我們可以在Bugly的后臺看到崩潰信息，大約不到一分鐘，就可以在后臺看到崩潰信息了。(這里請注意：這里在Bugly顯示時(shí)間很短，可以說是即時(shí)的，因?yàn)檫@個(gè)方面要和友盟進(jìn)行對比。)

Bugly03.png

• 但是我們發(fā)現(xiàn)，這里只能看到是因?yàn)槭裁幢罎⒘耍⒉荒艽_定是具體哪個(gè)類哪一行報(bào)錯(cuò)，下面有請我們的符號表閃亮登場?。。?br> 關(guān)于符號表請仔細(xì)閱讀Bugly的官方文檔，非常詳細(xì)。
  配置符號表有兩種方法：1.自動(dòng)配置 2.手動(dòng)配置，在這里我只講一下自動(dòng)配置，以及一些需要注意的點(diǎn)，因?yàn)槭謩?dòng)配置太麻煩，原諒我這么懶。。。

• 注意點(diǎn)：
  （1）當(dāng)我們下載完 自動(dòng)配置符號表工具包后，我們要將Appid Appkey BundleId分別替換掉dSYMUpload.sh文件中的字段。將下面這兩個(gè)字段的值全部改成1，不然會(huì)一直提示你，符號表未配置。
  

  Bugly04.png

（2）當(dāng)你用模擬器或者Debug模式運(yùn)行，一定要注意文檔中的這段話，我是將值都改成了1。

• Debug模式編譯是否上傳，1＝上傳 0＝不上傳，默認(rèn)不上傳
  UPLOAD_DEBUG_SYMBOLS=0
• 模擬器編譯是否上傳，1＝上傳 0＝不上傳，默認(rèn)不上傳
  UPLOAD_SIMULATOR_SYMBOLS=0

再次運(yùn)行后，當(dāng)然也是崩潰，查看Bugly后臺，很清晰的為我們分析出是哪一行出現(xiàn)錯(cuò)誤。是不是很棒棒?。?！

Bugly05.png

二、友盟錯(cuò)誤分析

• 如果你對友盟的產(chǎn)品不是很熟悉的話，建議先看看新手上路

  
  
  UM01.png

• 同樣很老套的注冊應(yīng)用獲取appkey

  
  
  UM02.png
  
  

  然后下載SDK，根據(jù)文檔集成

  
  
  UM03.png
  
  解壓之后是下面4個(gè)文件夾，實(shí)在不明白只想進(jìn)行錯(cuò)誤分析，這添加的framework有點(diǎn)多啊。。。
  
  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];//設(shè)置打開日志
    [UMConfigure initWithAppkey:@"5ae870e88f4a9d72f70004d3" channel:@"App Store"];
    NSArray *array = @[@"1",@"2",@"3"];
    NSLog(@"%@",array[3]);
    return YES;
}

就文檔而言，感覺友盟的文檔很亂，東西很雜，對于初次使用友盟的開發(fā)者來說可能會(huì)有一點(diǎn)麻煩，也許是因?yàn)橛衙说漠a(chǎn)品太多了吧。
當(dāng)我們運(yùn)行完有bug的程序之后，在友盟的后臺并沒有及時(shí)顯示出崩潰信息，我也就不等了，因?yàn)樽蛱炀偷攘藘蓚€(gè)小時(shí)才在后臺看到，友盟這效率有點(diǎn)低啊。
如果我們想看到底是哪一行代碼引起的崩潰我們需要借助工具umcrashtool。下面開始說說如何使用。
點(diǎn)擊這里可以看到錯(cuò)誤工具的使用

UM05.png

UM06.png

在這里進(jìn)行下載，在桌面新建一個(gè)文件夾crash，將umcrashtool和.csv文件一同放入crash中。

• (1)執(zhí)行命令，cd 到crash中
  
  UM07.png
  
  (2)輸入./umcrashtool 先不要敲回車，繼續(xù)把.csv文件拖到終端中，注意：./umcrashtool 與.csv文件路徑之間要有空格
  
  UM08.png
  
  此時(shí)回車，會(huì)出現(xiàn)下面的結(jié)果
  
  UM09.png
  
  紅框內(nèi)標(biāo)識你的dsym文件并不是以69DA4615...命名的，那么這個(gè)dsym是在哪里找到的，我們在打包的時(shí)候，會(huì)生成一個(gè)Archive文件,Show in Finder，顯示包內(nèi)容找到BugDemo.app.dsym文件
  
  UM10.png
  
  
  UM11.png
  
  
  UM12.png
  
  
  UM13.png
  
  
  UM14.png

此時(shí)我們發(fā)現(xiàn).dSYM文件的名稱和終端上要求的名稱不一樣，要將.dSYM文件命名為終端上的名稱，（UM14.png是修改后的文件名稱）再次執(zhí)行上面的命令。

image.png

之前的警告就消失了，但是新的問題出現(xiàn)了，這里為什么沒有具體顯示哪一行有錯(cuò)誤呢？通過查找資料發(fā)現(xiàn)，友盟關(guān)于數(shù)組越界這種bug并不能準(zhǔn)確分析出是哪一行代碼出現(xiàn)問題，so。。。剛才是白做了，此時(shí)心中一萬只草泥馬路過，看到這里的朋友不要打我，我是無辜的。

image.png

通過實(shí)際操作兩者比較：

• 時(shí)間：Bugly可以堪稱即時(shí)性，友盟。。等的我花兒都謝了；
• 定位準(zhǔn)確度：從剛開的分析也可以看出，Bugly明顯是優(yōu)于友盟的；
• 操作難易度：Bugly可以進(jìn)行自動(dòng)配置符號表，但友盟只能進(jìn)行手動(dòng)操作，并且友盟的文檔關(guān)于umcrashtool的介紹使用說明并不是那么明顯；
• 友盟只能統(tǒng)計(jì)1000個(gè)錯(cuò)誤，而Bugly并沒有限制；
  關(guān)于錯(cuò)誤分析只是友盟的一個(gè)小分支，這里也沒有貶低友盟的意思，只是對兩者進(jìn)行錯(cuò)誤分析的比較，當(dāng)然友盟的分享和統(tǒng)計(jì)做的還是相當(dāng)牛逼的，有時(shí)間再講講統(tǒng)計(jì)，這個(gè)挺有意思的。