写了个防止 iOS APP 崩溃的库，可以拦截一些常见的崩溃

用 method swizzle 来实现，没有使用 try-catch。对常见的容器类，数组字典字符串这些有做保护，顺带新增了 NSSet，NSCache，NSUserDefaults，NSData 等几个类的保护，支持拦截 unrecognized selector sent to instance 异常，设置好要拦截的类即可。

已经在自己的项目用上了，目前工作稳定，iOS8.x 到 iOS11.x 都测试通过。

一些使用代码规范就能解决的崩溃，比如 NSTimer，通知和 KVO 这些造成的崩溃，本项目并未做额外处理，这种低级的失误，还是用代码规范来限制比较好。

崩溃

拦截

代码

swizzle

13 条回复 • 2019-02-13 17:51:29 +08:00

YIem

2018-09-29 19:52:52 +08:00

为什么不在 V2EX 里用英文介绍呢？

tanpengsccd

2018-09-29 20:06:19 +08:00 via iPhone

用 swift 不强制解包应该可以减少 crash

kobe1941

2018-09-29 22:34:45 +08:00

@tanpengsccd 那就跟我这个原理不太一样了哈

nathanw

2018-09-30 00:21:43 +08:00 via iPhone

这么做并不合适，出现这个问题一般由于逻辑缺陷，若简单拦下来只是当时不 crash，程序继续执行还会处于一个不稳定状态，延迟错误的发生将更难定位问题

classyk

2018-09-30 08:39:04 +08:00

防止 crash 并不能保证程序按预期进行。反而问题更难查找了

ruiwendell

2018-09-30 10:32:10 +08:00

这个有写得比较完善的轮子了，也是通过 method swizzle 实现的，https://github.com/chenfanfang/AvoidCrash

kobe1941

2018-09-30 11:25:59 +08:00

@nathanw 我是针对常见的容器类做拦截，并且给出了错误日志回调的接口，只要你上传错误日志，是可以定位到问题的，而且只用了 methos swizzle，而没有使用 try-catch，因为一旦 try-catch 失败后，操作系统抛出的异常，往往很诡异，跟原本的错误是两码事。avoidCrash 的 issue 页面有一些这样的问题，作者根本就无法复现，更不要谈怎么去解决 @ruiwendell 。
APP 崩溃对于用户来说始终是最差的体验，没有之一。

kobe1941

2018-09-30 11:29:34 +08:00

@classyk 因为 OC 有语法糖，经常会使用诸如 @[str1，str2]，或者 array[5]或者 dic[@"key"] = obj 这样子的写法，所以降低崩溃率是切实可行的，而且上报的错误日志有完整的调用堆栈，为什么会更难查找问题呢？
当然如果代码或者数据有问题，虽然走到此处并不会崩溃，但程序不见得会正常运行下去，至少让用户可以返回到上一个页面，比直接 crash 还是要好很多吧。。。