12 | iOS 崩溃千奇百怪，如何全面监控？

下面，我们就先看看几个常见的编写代码时的小马虎，是如何让应用崩溃的。

1.数组越界：在取数据索引时越界，App会发生崩溃。还有一种情况，就是给数组添加了 nil 会崩溃。
2.多线程问题：在子线程中进行 UI 更新可能会发生崩溃。多个线程进行数据的读取操作，因为处理时机不一致，比如有一个线程在置空数据的同时另一个线程在读取这个数据，可能会出现崩溃情况。
3.主线程无响应：如果主线程超过系统规定的时间无响应，就会被 Watchdog 杀掉。这时，崩溃问题对应的异常编码是0x8badf00d。关于这个异常编码，我还会在后文和你说明。
4.野指针：指针指向一个已删除的对象访问内存区域时，会出现野指针崩溃。野指针问题是需要我们重点关注的，因为它是导致App崩溃的最常见，也是最难定位的一种情况。关于野指针等内存相关问题，我会在第14篇文章“临近 OOM，如何获取详细内存分配信息，分析内存问题？”里和你详细说明。

image.png
1.收集崩溃日志最简单的方法，就是打开 Xcode 的菜单选择 Product -> Archive。
2.目前很多公司的崩溃日志监控系统，都是通过PLCrashReporter 这样的第三方开源库捕获崩溃日志，然后上传到自己服务器上进行整体监控的。

这里，我先介绍下 iOS 后台保活的5种方式：Background Mode、Background Fetch、Silent Push、PushKit、Background Task。

使用 Background Mode方式的话，App Store在审核时会提高对App 的要求。通常情况下，只有那些地图、音乐播放、VoIP 类的 App 才能通过审核。
Background Fetch方式的唤醒时间不稳定，而且用户可以在系统里设置关闭这种方式，导致它的使用场景很少。
Silent Push 是推送的一种，会在后台唤起 App 30秒。它的优先级很低，会调用 application:didReceiveRemoteNotifiacation:fetchCompletionHandler: 这个 delegate，和普通的 remote push notification 推送调用的 delegate 是一样的。
PushKit 后台唤醒 App 后能够保活30秒。它主要用于提升 VoIP 应用的体验。
Background Task 方式，是使用最多的。App 退后台后，默认都会使用这种方式。