iOS崩溃治理--开篇

去年我开始负责iOS崩溃治理的工作，从原来的万分之五崩溃率，一直到现在的万分之一左右的崩溃率，期间踩了很多坑，因此想和大家分享一下，希望能对大家有所帮助，也欢迎大家私信交流。

如果你打算开始治理崩溃的话，建议你先想一下以下的问题：

如何高效地去定位修复崩溃？

修复线上收集到的崩溃，可以说这是无法避免的体力活，大部分的崩溃事实上并不复杂，都不难解决，但怎么快速定位是个问题。

大部分的崩溃堆栈很清晰，通过日志我们可以很容易定位到有问题的代码，但有些崩溃日志，很可能只有一堆系统相关的堆栈，很难对应到业务代码。对于类似情况，有没有相关的应对方案，决定了你的崩溃修复效率。

除了解决线上收集到的崩溃还要做些什么？

解决线上收集到的崩溃是必须的，但这只是个必要不充分条件。如果你只是case by case地解决线上崩溃，那很快你就会疲于奔命，被困在无休止的体力活当中。

原因主要有以下几点：

1，你所处的项目比较大，可能涉及到好几个团队的协作

2，每次发版都可能引入新的崩溃

3，后端的改动也可能引起线上崩溃

4，新系统的发布也可能引起问题

如何推动跨团队的协作？

对于一个比较大的App来说，通常都会涉及到多个团队的合作。比如说，登录SDK，IM,日志上报等功能，一般都会有专门的团队负责。也就是说，线上的某个崩溃很可能要找另外一个团队的人解决，即使你知道怎么修复，也很可能没权限。这时候仅仅靠你去协调是不现实的，这会耗费你大量的精力。

每次发版总会有新的崩溃要如何解决？

新需求总是会伴随着或多或少的崩溃，每次发版都会有着上涨的风险，毕竟研发和QA也都是普通人，不可能不毫无遗漏。要如何降低这种风险，以及在问题发生之后如何及时止损。

线上突然爆出问题该怎么办？

线上突然出现崩溃的情况其实并不少见，尤其是和服务端交互比较多的App，甚至是一些有网络请求的三方库也可能引起类似问题，这时候要怎么及时发现问题, 如何及时修复止损。

有没有一劳永逸的方法？

这是终极目标，但是很难，因为项目总在迭代，即使你不迭代（不迭代这项目也没有什么价值了），系统也会更新。但即使做不到一劳永逸，我们是不是可以找到一些方式，让我们只需要花很少的时间来维持线上稳定。

对于这些问题，从手段方面，我分为三种，基础设施，流程规范，技术防控。从时间点上，又可以分为事前，事中，事后。后续我会从这些方面来跟大家分享自己的一些经验，有些内容可能在大家的项目中已经实现了甚至是做的更好，有些内容可能是你所欠缺的，希望能和大家多多交流。