工欲善其事，必先利其器。崩溃治理是个苦力活，尤其是在基础设施不完善的情况下。
那么我们需要哪些基础设施呢？
1，崩溃收集SDK
要治理崩溃，一个功能强大的崩溃收集SDK以及对应的服务是必不可少的。如果公司有自研的SDK, 那当然是选用公司自研的，这样可以根据自己的需要去给对应的团队提需求。
如果你所在的团队或者公司并没有自研的崩溃收集SDK, 那么就要选用一个比较好用的三方服务了。那要怎么挑选呢？
我觉得至少要做到以下两点：
1，准确性。做不到这一点，那就没什么意义了。如果是自研的SDK，可以评估一下其捕获的崩溃是否准确，三方服务的话建议使用一些比较知名的。
3，报警功能，最好能分级报警。线上问题不可能靠人工盯着，想要保持线上环境的稳定报警功能是必不可少的。
2，详细日志功能
对于线上问题的排查意义重大，并不仅仅只对于崩溃而言。有些崩溃产生的原因很容易理解，但却很难定位，因为崩溃日志的有效信息范围过大，无法定位。比如下面这个崩溃：我们大概可以判定这是一个多线程问题，但由于堆栈中都是系统相关的调用，如果要根据这些信息去定位无异于大海捞针。
Thread 28 Crashed: 0 libobjc.A.dylib _objc_msgSend 1 libdispatch.dylib __dispatch_call_block_and_release 2 libdispatch.dylib __dispatch_client_callout 3 libdispatch.dylib __dispatch_lane_serial_drain$VARIANT$mp 4 libdispatch.dylib __dispatch_lane_invoke$VARIANT$mp 5 libdispatch.dylib __dispatch_workloop_worker_thread 6 libsystem_pthread.dylib __pthread_wqthread
这时候要是能在崩溃发生的时候携带一些额外信息，比如当然所处的页面，操作路径等，对于问题定位有很大的帮助。但如果日志的功能和崩溃日志不能整合到一起，对于崩溃的定位帮助就要打一个大折扣。需要自己去找对应的日志，以及对应的时间点，很麻烦，但总比没有好。如果没有日志相关的功能，也可以选择一些能够添加自定义日志，以及上传自定义参数的崩溃收集SDk。fireBase就有相关的功能，但需要自己添加打点，成本比较高。bugly，网易云捕没有用过，可以找找有没有直接将操作日志功能和崩溃日志整合在一起的三方服务。
3，热修复功能
虽然苹果明令禁止使用热修复，但实际上使用相关功能的App还是很多，热修复的意义在于及时止损，不仅仅是针对崩溃问题，对于线上问题意义重大。毕竟以苹果爸爸的审核效率，增发一个新包的话黄花菜都凉了。热修复的原理并不复杂，但实现起来坑很多，如果公司没自研的话，那实现成本估计会比较高，因为不止需要端上的SDK实现，还需要配套的服务端。使用三方库审核不过的风险比较大，建议慎重选择。
4，灰度功能
灰度功能并不是一个必须的功能，只能说是锦上添花。但如果没有热修复功能的话，还是强烈建议使用灰度的。苹果现在可以添加外部测试，上限是一万人。具体可以看iOS中利用TestFlight进行灰度测试，实现成本是有的，但成本应该在可接受范围内，比热修复要简单得多。在没有热修复的情况下，最好至少拥有功能级别上的灰度能力，否则对于一些新增问题以及线上问题就会非常无力。