iOS防止崩溃机制以及底层原理

iOS防止崩溃机制以及底层原理开发的目的是什么？

吴杰   2018-11-19

在你影响中是否有这样子的晚上，当刚刚躺下准备美美的睡一觉的时候，突然接到您的上司的电话，一接起来发现是你上司！“**啊，刚刚上线的X.X.X版本出问题了啊，怎么样操作会crash啊，导致新功能都无法使用了，快定位一下是什么原因，抓紧修复一下啊！”。心里一万头草泥马呼啸而过，瞬间已经满头大汗的你却还要故作镇静地回答：“嗯，我马上去看看，一定努力解决问题！” 急忙打开电脑的你，知道今夜注定无眠了。

是否又存在这样的情形，你老板把大家都聚起来开了一个年初KPI目标制定会议，说到：“作为一个资深的技术团队，app性能是我们技术团队首抓的目标，其中很最要的一项就是app的崩溃率，去年我们app统计出来的崩溃率是千分之五，而我们的竞争对手的崩溃率只有万分之五，相差了10倍！今年我们要赶超他们，最起码也要和他们持平。” 你甚是赞同，但是你心里却又有点怀疑，对方的开发资源是我们的好几倍而且个个都是资深老司机，我们团队里却大多都是应届生小鲜肉，这KPI能完成么？

如果你遇到过以上的情况并且对此深表头痛，那么 IOS自动修复系统 将会是你的不二选择！

APP运行时Crash自动修复+捕获系统 的设计初衷，就是为了降低app的crash率。利用Objective-C语言的动态特性，采用AOP(Aspect Oriented Programming) 面向切面编程的设计思想，做到无痕植入。能够自动在app运行时实时捕获导致app崩溃的破环因子，然后通过特定的技术手段去化解这些破坏因子，使app免于崩溃，照样可以继续正常运行，为app的持续运转保驾护航。当然我们不可能强大到把所有类型的crash都处理掉，但是我们会对一些高频的crash进行一一的处理，我们的目的就是降低crash率

1. 我们常见的crash有哪些呢？

• unrecognized selector crash  (没找到对应的函数)
• KVO crash :(KVO的被观察者dealloc时仍然注册着KVO导致的crash，添加KVO重复添加观察者或重复移除观察者 )
• NSNotification crash:(当一个对象添加了notification之后，如果dealloc的时候，仍然持有notification)
• NSTimer类型crash:(需要在合适的时机invalidate 定时器，否则就会由于定时器timer强引用target的关系导致 target不能被释放，造成内存泄露，甚至在定时任务触发时导致crash)
• Container类型crash:(数组，字典，常见的越界，插入，nil)
• 野指针类型的crash
• 非主线程刷UI类型：(在非主线程刷UI将会导致app运行crash）……

1. 一：Unrecognized Selector类型crash防护

unrecognized selector类型的crash在app众多的crash类型中占着比较大的成分，通常是因为一个对象调用了一个不属于它方法的方法导致的。

例如调用以下一段代码就会产生crash：

具体crash时的表现见下图：

1.2   方法调用流程

函数调用的流程如下：

1：首先，在相应操作的对象中的缓存方法列表中找调用的方法，如果找到，转向相应的函数

2：如果没找到在对象的类方法列表中找调用的方法，如果找到，转向相应的实现执行

3：如果没有找到，去父类指针指向的对象中执行1，2

4：以此类推，如果一直到根类还没有找到，转向拦截调用，走消息转发

5：如果没有重写拦截调用的方法，程序报错。

1.3  拦截调用：