前言
先说下友盟的SDK，现在真是对友盟没脾气了，分享不正常！三方登录不正常！崩溃分析也不好用！最近所在项目的App，加了直播功能，总是会出现些不可预见的闪退出现，但通过友盟的崩溃统计分析，真心看的云里雾里的，很不方便，分析工具也不够友好，用起来很麻烦。一些朋友、同行都在用Bugly，鉴于Bugly是腾讯旗下的产品，在用过他们的JSPatch后，对腾讯的产品也是好感满满，这里就总结下Bugly的简单使用。
然后说下符号表对于崩溃分析的重要性，因为虽然很多人在用Bugly，但可能没有用到符号表，导致很多问题没法定位到具体代码。所以，写这篇文章，一是帮自己记录下使用流程及终端命令；二是如果你没用过Bugly，可以帮助你快速上手；三是如果你在用Bugly，但没有使用符号表，可以让你把符号表用起来。但如果这些你都用过，这篇入门文章，就可以不用看了😀。
集成
集成很简单，按照官方文档来就好，我们这里建个简单的小项目，模拟一些崩溃，测试下Bugly的bug上报及时性。
项目就取名叫BuglyDemo了，创建好项目后，去Bugly的控制台，添加我们的应用。
随便填一填就好了。然后我们点击异常上报，查看他的SDK集成方法，这里就不细说了。
然后在AppDelegate中初始化，OK。
// 头文件
#import <Bugly/Bugly.h>
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[Bugly startWithAppId:@"此处替换为你的AppId"];
return YES;
}
AppID可以点击你在控制台创建的App，然后点产品设置就能看到了。
Bug上传测试
通过以上的集成及初始化，我们就可以使用了。现在我们创造一个闪退bug，测试下Bugly的bug上传及时性。
来到ViewController中，在touchBegin中制造一个闪退。以数组越界为例：
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
NSArray *arr = @[@"", @""];
arr[5];
}
运行项目（iOS10需要允许App进行数据访问），点击屏幕，这时就崩溃了，然后刷新Bugly的控制台，你会发现，bug已经统计到了。所以，Bugly的崩溃上传是在崩溃后立刻上传的，而友盟的bug上传，你需要反复启动几次应用，然后过几分钟才会在控制台看到。
我们点进异常问题中去看一下，崩溃信息大致是这样的，相较于友盟的分析，我们可以很直观的看到崩在哪个方法里了，但想更具体的分析代码位置，就要用到符号表了。
符号表分析
没有符号表，我们就无法定位崩溃中的符号对应的代码所在的类以及类中的行数位置。我们在每次构建版本、debug的时候，都会生成dSYM后缀名的符号表文件，而我们App在手机上运行的时候，崩溃后产生的崩溃信息，不可能定位到代码的多少多少行，因为这些信息对于App运行是没有意义的，存储在App中势必会增大安装包的体积，所以App的崩溃信息都是存储为各种符号，具体符号代表什么，需要去符号表中查找对应的含义。
我们每次debug、构建版本，都会生成dSYM文件，都对应了一个UUID（像我们的手机一样，都有一个唯一标志），按下图指示，我们就能找到我们所使用的App版本对应的dSYM文件的UUID，通过这个UUID，我们就能找到存储在我们电脑中的dSYM文件，将这个文件上传到bugly，bugly会自动帮我们找到崩溃符号的含义。
需要注意的是，构建版本会自动生成dSYM文件，但debug的时候，是没有的，需要我们手动开启。在build setting中搜索debug，将下面两项内容修改为正确的设置：
有了符号表的UUID，我们打开终端，按UUID找到符号表的路径。
mdfind "com_apple_xcode_dsym_uuids == A8E87810-70A7-3335-B638-C8B01BE15D79"
后面的一串字母数字组合，就是我们的UUID，这里需要将UUID按一定格式处理下，也就是在特定位置插入“-”，具体格式如下：
来到终端，运行上面的命令，就定位到了dSYM文件的位置：
打开文件路径，就找到了dSYM文件：
拷贝出来，压缩为zip文件，上传到bugly上。
刷新页面，再回去看刚才的问题，定位到了为ViewController.m的第24行：
SO，我们的24行做了越界的处理：
其他体验
与友盟比较，Bugly更人性化一些，而且页面更好看写。对于闪退的出现，还提供了如何避免和修复该Bug的一些帮助：
Bugly也提供热修复功能，当然官方说自己的SDK也是基于JSPatch的，想了解热修复的，可以参考我的这篇文章：JSPatch热修复简单使用
官网文档也提供了自动上传dSYM文件的操作流程，有兴趣的可以试试，避免以后每次新版本都要手动上传dSYM文件。dSYM文件也可以手动查找：
找到你构建的版本，右键show in finder：
然后在定位到的文件上右键显示包内容就OK了：
总结
与友盟相比，Bugly在崩溃信息统计方面，优势很明显，除了上面的功能、细节强大，邮件提示、公众号提示，都体现了Bugly的用心。不说别的，就友盟那没事就抽风的服务器，我还是建议广大开发者快来拥抱鹅厂吧。
