相信没有那个程序员愿意看到自己的 App 发生崩溃，因为这意味着你要面对老板疯狂的「咆哮」，同时也意味着你近期的主要任务就是「加班」。但是，崩溃也是每个 App 必须直面的现实。如果崩溃已经发生了，我们也无法阻挡，那么我们应当如何从容的面对呢？

首先，我们先浅谈一下苹果自带的解决方案。程序员同学可以使用 iOS SDK 中提供的函数 NSSetUncaughtExceptionHandler 用来做异常处理，但是，需要说明的是，其功能非常有限，而且引起崩溃的大多数原因都是因为内存访问错误，但是面对重复释放等错误它就变得无能为力了，因为这类错误抛出的是 Signal，所以必须要专门做 Signal 处理。

这里需要说明一点的是，这些处理过程其实也是非常繁琐的，我们可以借助于一些强大的第三方工具比如 OneAPM，就可以帮助开发同学免去很多复杂繁琐的操作过程。下面让我们正式开启从容应对 Crash 的旅程吧！

第一步：确定发生 Crash 的用户是谁？

当然，如果一款 App 发生了 Crash 问题，首先，我们不用太着急去定位解决这个崩溃问题，而是应该先了解一下，同类型的 Crash 影响的用户人数、用户的设备信息以及 Crash 的发生频率。我们借助 OneAPM 移动端的专业性能监控产品 Mobile Insight，就可以抓取到这些信息，然后帮助我们列出需要解决问题的优先级。

第二步：确定哪行代码造成了移动应用 Crash？

当程序员需要解决这些 Crash 时，他们最想知道的就是：哪行代码造成了崩溃？具体的原因是什么？显然，一般市面上提供的工具解决不了这个问题，它们大多数情况下，只能告诉开发者：「妈呀，你的程序崩溃了，快来看看吧！」所以我们需要借助更专业的监控工具。 以图中的Crash详情为例，OneAPM 可以定位到 Crash 发生在 WXPersonalCenterViewController 类第 445 行的 tableView:didSelectRowAtIndexPath: 这个方法中。而且能够帮开发者分析出造成 Crash 的原因，本例就是因为是在 WXPersonalCenterViewController 类中没有提供 leaveMessageAndNewsBtnPressed 这个方法。接下来，我们需要做的就是检查一下，在某个类中某个方法是否实现了，或者检查一下方法参数跟调用该方法时参数是否匹配，分分钟就可以定位到具体的代码行，这就是专业！

第三步：追溯用户进行了哪些操作？

你以为这样就已经结束了吗？当然没有。虽然通过上面的步骤，大概已经可以帮助我们定位并解决一个 Crash 问题，但是修复之后测试时，我们还需要知道，在此之前，用户进行了哪些操作才导致发生了 Crash。这个似乎变得更难了，但是 OneAPM 又帮你搞定了这件事，它提供的崩溃的轨迹分析，可以回放单个用户出现崩溃前的所有操作轨迹，帮助开发人员分析影响 App 崩溃的相关操作。 这样的话，开发者就可以在 Bug 修复完成之后，按照 Mobile Insight 抓取到的崩溃轨迹，进行场景重现，确认是否彻底解决了这个问题，最终可以达到“根治”的效果。

不仅如此，OneAPM 还会帮你记录崩溃时的崩溃 Log 和线程堆栈详情信息，就像下图所示：

现在，有了如此详细的移动应用 Crash ，你还会被崩溃弄得束手无策么？如果你想从容应对崩溃，如果你想拒绝熬夜加班，那么赶快下载 OneAPM 的 SDK 导入到项目中试试吧！