如题，项目地址请点击这里
用 method swizzle 来实现，没有使用 try-catch。 对常见的容器类，数组字典字符串这些有做保护，顺带新增了 NSSet，NSCache，NSUserDefaults，NSData 等几个类的保护，支持拦截 unrecognized selector sent to instance 异常，设置好要拦截的类即可。
已经在自己的项目用上了，目前工作稳定，iOS8.x 到 iOS11.x 都测试通过。
一些使用代码规范就能解决的崩溃，比如 NSTimer，通知和 KVO 这些造成的崩溃，本项目并未做额外处理，这种低级的失误，还是用代码规范来限制比较好。
 |
1
YIem Sep 29, 2018
为什么不在 V2EX 里用英文介绍呢？
|
 |
2
tanpengsccd Sep 29, 2018 via iPhone
用 swift 不强制解包 应该可以减少 crash
|
 |
3
kobe1941 OP @tanpengsccd 那就跟我这个原理不太一样了哈
|
 |
4
nathanw Sep 30, 2018 via iPhone  2
这么做并不合适，出现这个问题一般由于逻辑缺陷，若简单拦下来只是当时不 crash，程序继续执行还会处于一个不稳定状态，延迟错误的发生将更难定位问题
|
 |
5
classyk Sep 30, 2018
防止 crash 并不能保证程序按预期进行。反而问题更难查找了
|
 |
6
ruiwendell Sep 30, 2018
这个有写得比较完善的轮子了，也是通过 method swizzle 实现的，https://github.com/chenfanfang/AvoidCrash
|
|
7
kobe1941 OP @nathanw 我是针对常见的容器类做拦截，并且给出了错误日志回调的接口，只要你上传错误日志，是可以定位到问题的，而且只用了 methos swizzle，而没有使用 try-catch，因为一旦 try-catch 失败后，操作系统抛出的异常，往往很诡异，跟原本的错误是两码事。avoidCrash 的 issue 页面有一些这样的问题，作者根本就无法复现，更不要谈怎么去解决 @ruiwendell 。
APP 崩溃对于用户来说始终是最差的体验，没有之一。 |
|
8
kobe1941 OP @classyk 因为 OC 有语法糖，经常会使用诸如 @[str1，str2]，或者 array[5]或者 dic[@"key"] = obj 这样子的写法，所以降低崩溃率是切实可行的，而且上报的错误日志有完整的调用堆栈，为什么会更难查找问题呢？
当然如果代码或者数据有问题，虽然走到此处并不会崩溃，但程序不见得会正常运行下去，至少让用户可以返回到上一个页面，比直接 crash 还是要好很多吧。。。 |
 |
9
cikelengfeng Nov 27, 2018
火灾发生了，就把报警声关掉。。。。
这种行为不可取啊 |
|
10
cikelengfeng Nov 27, 2018
程序之所以要 crash，一个很重要的原因是程序在非预期的状态下能够保护用户的数据，这种情况下如果继续跑多半会有更严重的错误发生
|
|
11
kobe1941 OP @cikelengfeng 你先看下介绍嘛，拦截的是一些基础容器的异常，常见的是各种越界，插入空值这些导致的崩溃。拦截他们不会有更严重的错误发生，会让一部分操作不是得到它原来的结果，但是其他功能依然可以正常运行。
你有了解到用户就会知道，常规来说，APP 崩溃是对用户最大的伤害。 |
 |
12
massacreformash Dec 1, 2018
不建议团队使用. 个人项目使用算是比较适合
|
 |
13
misaka20 Feb 13, 2019
拦截到了，把日志记录下来不就好了。
怎么就问题就更难找了 |
Select Language