iOS 崩溃日志收集及分析

最近几天，项目中在增加推送功能，选用的极光推送SDK，相信大家也都用过，官方文档的集成步骤很详细，集成也很容易。但是这跟今天的主题有什么关系呢？？？ 黑人问号？？？别急，下面就来说说我今天的遭遇。坑~~~

话说，由于iOS10之后，苹果对推送进行了重大更新，主要是新增了 User Notifications Framework框架， 具体信息可以查看苹果官方文档，这里就不多解释了。于是我就突发奇想，利用新增的三种本地推送，TimeInteval，Calendar，Location，在项目中增加自定义推送设置，让用户自己想要的推送的内容，图片或者视频，可以基于位置，时间和日历。 很不错，于是开始写代码，由于极光对iOS10和10以下的Api进行了封装，所以直接可以调用。当我写完第一个TimeInteval类型的推送时，一运行直接崩溃！！！崩溃倒是无所谓，可我一看Log：

。。。 只是提示捕获了异常，然而并没有具体的信息，Xcode也没有定位到底是哪一行出错的。。。这就尴尬了。于是，我想到了崩溃日志。 怎么查看？很简单，将自己的iPhone连接到mac上，然后点击下图的位置：

接着在按照下图的步骤查看具体的信息

在点击View Device Logs后可以看到你的设备中所有的崩溃信息，可以根据时间进行排序，我们找到刚才的崩溃信息，出现了以下界面：

崩溃信息大致大致可以分为以上几个部分，下面来详细介绍：

第一部分是闪退进程的相关信息：

Incident Identifier ： 是崩溃报告的唯一标识符。

CrashReporter Key： 是与设备标识相对应的唯一键值。虽然它不是真正的设备标识符，但也是一个非常有用的情报:如果你看到100个崩溃日志的CrashReporter Key值都是相同的，或者只有少数几个不同的CrashReport值，说明这不是一个普遍的问题，只发生在一个或少数几个设备上。

Hardware Model ：标识设备类型。 如果很多崩溃日志都是来自相同的设备类型，说明应用只在某特定类型的设备上有问题。上面的日志里，崩溃日志产生的设备是iPhone 4s。

Process：对项目的操作权限，上面的是可读可写

Path:崩溃文件的路径

Identifier:项目标识符，就是Bundle Id

Version:版本号

.....等等.......

第二部分

给出了一些基本信息，包括闪退发生的日期Date/Time和时间Launch Time，设备的iOS版本OS Version等。

第三部分
Exception Type:异常的类型。
Exception Codes ：异常错误码
Termination Reason：闪退的原因，比如常见的数组越界啊，什么的。
Triggered by Thread：出现问题在哪个线程，这个比较重要，首先确定在哪个线程中出了问题，然后再去定位。

第四部分
这部分提供应用中所有线程的回溯日志。 线程调用的一些，堆栈信息，压根看不懂，所有需要进行符号化处理。

首先，这里介绍下官方的，也就是利用Xcode自带的崩溃日志分析工具symbolicatecrash,自己尝试了下效果一般，只是把它转换成常规的崩溃信息，用法这里就不细说了，附上一篇文章，里面有具体的用法，传送门。。。

其实，现在网上有很多搜集崩溃日志的第三方，下面介绍几个相对比较专业的：

一丶Bugly

Bugly 是腾讯内部使用的移动应用崩溃检测服务，同时支持 iOS 和 Android 平台。目前 Bugly 已经对移动开发者开放。移动开发者在自己的  App 中接入 Bugly 的 SDK 后，就能在应用崩溃后获得信息上报。开发者可以通过 Bugly 的网站看到崩溃的概要和详情。崩溃概要包括，崩溃的列表、近日按小时统计趋势、昨天前天的崩溃次数和崩溃率。

具体用法：

• 登录Bugly，注册应用：

• 选择异常上报
  

  
  
  

• 可以选着SDK集成，也可以使用Pod，我当然选着Pod了，这么方便：
  通过CocoaPods集成，在工程的Podfile
  里面添加以下代码：

   pod 'Bugly'

  初始化Bugly,在工程AppDelegate.m
  的application:didFinishLaunchingWithOptions:
  方法中初始化Bugly：
  Objective-C

  - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
      [Bugly startWithAppId:@"此处替换为你的AppId"];
       return YES;
    }

      Swift     

 func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObje ct: AnyObject]?) -> Bool {
      Bugly.startWithAppId("此处替换为你的AppId")
      return true
 }

友情提醒：使用Bugly采集崩溃信息，要使用真机，不能使用模拟器，不可以Xcode启动真机App，因为，崩溃后，程序会停止在mian函数，那么上传崩溃信息就走运行不了了。

看看，Bugly的崩溃信息：

可以看到，Bugly可以帮助我们做一些崩溃数据的统计与分析。

当我们进入崩溃的详情页面，可以清楚的看到在哪一个控制器，哪一个方法，什么原因引起的崩溃。

这里还要推荐下Bugly的内测分发功能，也是相当的不错，通过二维码扫描下载，省去了很多麻烦，还可以设置密码权限等一系列操作，大家不妨去试试~

二丶Fabric

Fabric是Twitter在2014年举办的首届开发者大会上提供给第三方移动应用开发者的新工具，具体信息可以去它的官网进行浏览，下面介绍具体集成的步骤：

访问官网地址(进行注册账号)：

https://fabric.io

下载客户端地址：

https://fabric.io/downloads

1：注册成功后，并把客户端软件下载后，就可以登录客户端进行操作，选择要增加的工程文件

 

2：运用客户端，生成脚本

因为这边是直接采用把fabric框架直接拉进到项目中，所以生成的脚本为这种样式，若是采用Pod引入，其脚本会不一样；脚本的引入都会在项目的Info.Plist产生一个配置采单；

3：把脚本复制到XCode项目的相关地方

 注意：当有一个项目多个targets时，要对每个targets进行run Script设置，确保每个targets里面的info.plist文件有生成相应的配置，否则运行会报错；

4：引入相应的框架文件，直接从客户端拉到项目中

注意：除了直接把fabric拉进项目引用，还可以用POD进行管理插件，只是其脚本的内容格式不一样；

5：在项目中引入文件，并初始化框架，注册并特意编写错误的代码

 6：根据客户端提示运行最后一步,点Done回去，等待程序发布

7：回到XCODE的项目中，对项目进行发布

注意：选择Release,然后进行Archive;

8：当Archive成功发布以后，客户端会有提示，是否要进行dsym的上传

注意：选择Distribute，进入下一个页面，此处可以输入接受通知的邮件地址，可以是多人接收，然后下一步提示语输入，然后开始进行上传dysm文件；

9:成功运行以后就可以查看错误的信息

注意：其实fabric的原理还是把发布后的dsym上传后对它进行定位，显示出错误的位置；如果不用客户端这种上传，也可以中完成到脚本的加入后，把发布生成的dysm压缩成包进行上传；后官网对应的项目进行操作，如下图：

不过我感觉上面这些都挺麻烦的，别的不说，又要集成SDK，还要看官方文档。。。我们既然集成了极光推送了，那就直接用极光自带的算了。打开极光的崩溃信息收集功能很简单：

一句代码搞定，然后登陆极光官网，打开极光开发者服务，找到如下位置：

OK，现在已经可以看到刚才崩溃的信息了，当然你也点开查看具体的崩溃信息。

当我看到那个错误摘要的时候，恍然大悟！！！

time interval must be at least 60 if repeating

WTF。。。原来在设置NotificationTrigger为TimeInteval时，如果repeat设为true，那么timeInteval最少要设置成60.0s，好吧。。。

于是，在我改完代码之后，果然成功运行，没有报错。极光的这个崩溃收集还是挺好用的。

总结：平时我们在测试项目的时候尽量使用真机而不是模拟器，一方面真机的功能全面，另一方面可以更好的收集崩溃信息，便于分析Bug所在及时解决，上线的项目也是如此，可以通过打包发送给指定的邮箱或服务器来收集分析解决Bug。你问我没有真机怎么办？？？兄弟，听说前端现在很火，要不要考虑转行~