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

[kobe1941]

如题，项目地址请点击这里

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

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

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

[YIem]

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

[tanpengsccd]

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

[kobe1941]

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

[nathanw]

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

[classyk]

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

[ruiwendell]

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

[kobe1941]

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

[kobe1941]

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

[cikelengfeng]

火灾发生了，就把报警声关掉。。。。
这种行为不可取啊

[cikelengfeng]

程序之所以要 crash，一个很重要的原因是程序在非预期的状态下能够保护用户的数据，这种情况下如果继续跑多半会有更严重的错误发生

[kobe1941]

@cikelengfeng 你先看下介绍嘛，拦截的是一些基础容器的异常，常见的是各种越界，插入空值这些导致的崩溃。拦截他们不会有更严重的错误发生，会让一部分操作不是得到它原来的结果，但是其他功能依然可以正常运行。
你有了解到用户就会知道，常规来说，APP 崩溃是对用户最大的伤害。

[massacreformash]

不建议团队使用. 个人项目使用算是比较适合

[misaka20]

拦截到了，把日志记录下来不就好了。
怎么就问题就更难找了