iOS拓展---常见crash以及解决方案

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

我们常见的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）……

问题和解决

一：Unrecognized Selector类型crash防护

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

二：KVO类型crash防护（NSNotification）

kVO crash 产生的原因：大致有2种

第一种：KVO的被观察者dealloc时仍然注册着KVO导致的crash

第二种：添加KVO重复添加观察者或重复移除观察者（KVO注册观察者与移除观察者不匹配）导致的crash

一个被观察的对象上有若干个观察者，每个观察者又有若干条keypath.

如果观察者和keypath的数量一多，很容易不清楚被观察的对象整个KVO关系，导致被观察者在dealloc的时候，

仍然残存着一些关系没有被注销，同时还会导致KVO注册者和移除观察者不匹配的情况发生

尤其是多线程的情况下，导致KVO重复添加观察者或者移除观察者的情况，这种类似的情况通常发生的比较隐蔽,很难从代码的层面上排查

KVO crash 防护方案

如何管理混乱的KVO关系呢：

可以让观察对象持有一个KVO的delegate,所有和KVO相关的操作均通过delegate来进行管理，delegate通过

建立一张MAP表来维护KVO的整个关系，如下图：

这样做的好处有2个：

1：如果出现KVO重复添加观察或者移除观察者（KVO注册者不匹配的）情况，delegate，可以直接阻止这些非正常的操作。

2：被观察对象dealloc之前，可以通过delegate自动将与自己有关的KVO关系都注销掉，避免了KVO的被观察者dealloc时仍然注册着KVO导致的crash

具体实现：见demo

三：NSNotification类型crash防护（NSNotification）

3.1 NSNotification crash 产生原因：

当一个对象添加了notification之后，如果dealloc的时候，仍然持有notification，就会出现NSNotification类型的crash

NSNotification类型的crash多产生于程序员写代码时候犯疏忽，在NSNotificationCenter添加一个对象为observer之后，忘记了在对象dealloc的时候移除它。

所幸的是，苹果在iOS9之后专门针对于这种情况做了处理，所以在iOS9之后，即使开发者没有移除observer，Notification crash也不会再产生了。

不过针对于iOS9之前的用户，我们还是有必要做一下NSNotification Crash的防护的。

NSNotification Crash的防护原理很简单，利用method swizzling hook NSObject的dealloc函数，再对象真正dealloc之前先调用一下

[[NSNotificationCenter defaultCenter] removeObserver:self]，即可。

注意到并不是所有的对象都需要做以上的操作，如果一个对象从来没有被NSNotificationCenter 添加为observer的话，在其dealloc之前调用removeObserver完全是多此一举

具体实现：见demo

四：NSTimer类型crash防护（NSTimer）

4.1 NSTimer crash 产生原因

在程序开发过程中，大家会经常使用定时任务，但使用NSTimer的 scheduledTimerWithTimeInterval:target:selector:

userInfo:repeats: 接口做重复性的定时任务时存在一个问题：NSTimer会强引用 target实例，所以需要在合适的时机invalidate 定时器，否则就会由于定时器timer强引用target的关系导致 target不能被释放，造成内存泄露，甚至在定时任务触发时导致crash。 crash的展现形式和具体的target执行的selector有关。

与此同时，如果NSTimer是无限重复的执行一个任务的话，也有可能导致target的selector一直被重复调用且处于无效状态，对app的CPU，内存等性能方面均是没有必要的浪费。所以，很有必要设计出一种方案，可以有效的防护NSTimer的滥用问题。

4.2 NSTimer crash 防护方案

上面的分析可见，NSTimer所产生的问题的主要原因是因为其没有再一个合适的时机invalidate，同时还有NSTimer对target的强引用导致的内存泄漏问题。

那么解决NSTimer的问题的关键点在于以下两点：

　　>1.NSTimer对其target是否可以不强引用

　　>2.是否找到一个合适的时机，在确定NSTimer已经失效的情况下，让NSTimer自动invalidate

关于第一个问题，target的强引用问题。可以用如下图的方案来解决：

在NSTimer和target之间加入一层stubTarget，stubTarget主要做为一个桥接层，负责NSTimer和target之间的通信。

同时NSTimer强引用stubTarget，而stubTarget弱引用target，这样target和NSTimer之间的关系也就是弱引用了，意味着target可以自由的释放，从而解决了循环引用的问题。

上文提到了stubTarget负责NSTimer和target的通信，其具体的实现过程又细分为两大步：

step 1. swizzle NSTimer中scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: 相关的方法，在新方法中动态创建stubTarget对象，stubTarget对象弱引用持有原有的target，selector，timer，targetClass等properties。然后将原target分发stubTarget上，selector回调函数为stubTarget的fireProxyTimer

step 2. 通过stubTarget的fireProxyTimer：来具体处理回调函数selector的处理和分发

当NSTimer的回调函数fireProxyTimer：被执行的时候，会自动判断原target是否已经被释放，如果释放了，意味着NSTimer已经无效，此时如果还继续调用原有target的selector很有可能会导致crash，而且是没有必要的。所以此时需要将NSTimer invalidate，然后统计上报错误数据。如此一来就做到了NSTimer在合适的时机自动invalidate

补充：众所周知，NSObject类是Objective-C中大部分类的基类。但不是很多人知道除了NSObject之外的另一个基类——NSProxy
NSProxy是一个虚类，你可以通过继承它，并重写这两个方法以实现消息转发到另一个实例

栗子：

/**
 桥接层
 NSTimer强引用WOCPWeakProxy， WOCPWeakProxy弱引用target
 这样target和NSTimer之间的关系也就是弱引用了，意味着target可以自由的释放，从而解决了循环引用的问题
 */
@interface WOCPWeakProxy: NSProxy
@property (nonatomic, weak, readonly) id target;
- (instancetype)initWithTarget:(id)target;
+ (instancetype)proxyWithTarget:(id)target;
@end

@implementation WOCPWeakProxy

- (instancetype)initWithTarget:(id)target {
    _target = target;
    return self;
}

+ (instancetype)proxyWithTarget:(id)target {
    return [[WOCPWeakProxy alloc] initWithTarget:target];
}

//当不能识别方法时候,就会调用这个方法,在这个方法中,我们可以将不能识别的传递给其它对象处理
//由于这里对所有的不能处理的都传递给_target了,所以methodSignatureForSelector和forwardInvocation不可能被执行的,所以不用再重载了吧
//其实还是需要重载methodSignatureForSelector和forwardInvocation的,为什么呢?因为_target是弱引用的,所以当_target可能释放了,当它被释放了的情况下,那么
forwardingTargetForSelector就是返回nil了.然后methodSignatureForSelector和forwardInvocation没实现的话,就直接crash了!!!
//这也是为什么这两个方法中随便写的!!!

// 转发目标选择器
- (id)forwardingTargetForSelector:(SEL)selector {
    return _target;
}

// 函数执行器
- (void)forwardInvocation:(NSInvocation *)invocation {
    void *null = NULL;
    [invocation setReturnValue:&null];
}

// 方法签名的选择器
- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    return [NSObject instanceMethodSignatureForSelector:@selector(init)];
}

具体实现：见DEMO

五：Container类型crash防护（Container）

5.1 Container crash 产生原因

Container 类型的crash 指的是容器类的crash，常见的有NSArray／NSMutableArray／NSDictionary／NSMutableDictionary／NSCache的crash。一些常见的越界，插入nil，等错误操作均会导致此类crash发生。由于产生的原因比较简单，就不展开来描述了。

该类crash虽然比较容易排查，但是其在app crash概率总比还是挺高，所以有必要对其进行防护

5.2 Container crash 防护方案

Container crash 类型的防护方案也比较简单，针对于NSArray／NSMutableArray／NSDictionary／NSMutableDictionary／

NSCache的一些常用的会导致崩溃的API进行method swizzling，然后在swizzle的新方法中加入一些条件限制和判断，

从而让这些API变的安全，这里就不展开来具体描述了。

具体实现见DEMO

六：野指针类型的crash

6.1：野指针产生的原因

在App的所有Crash中，访问野指针导致的Crash占了很大一部分，野指针类型crash的表现为：Exception Type:SIGSEGV，Exception Codes: SEGV_ACCERR

解决野指针导致的crash往往是一件棘手的事情，一来产生crash 的场景不好复现，二来crash之后console的信息提供的帮助有限。

XCode本身为了便于开放调试时发现野指针问题，提供了Zombie机制，能够在发生野指针时提示出现野指针的类，

从而解决了开发阶段出现野指针的问题。然而针对于线上产生的野指针问题，依旧没有一个比较好的办法来定位问题。

所以，因为野指针出现概率高而且难定位问题，非常有必要针对于野指针专门做一层防护措施

6.2 野指针crash 防护方案

其实网上提出的方法都不完美，而且相当复杂。网上大多是在类init初始化的时候做一个标记，然后再dealloc再做一次标记，通过2次的标记来判断是否有内存，对于UIView UIImageview常用的类来讲多次分配释放内存消耗还是比较大的，并不是完美的解决方案

这里教大家一个小技巧：

大家知道怎么判断一个实例的内存是否已经释放了吗？这个方法是我发现的，亲测，非常有效，用于判断当前指针的内存是否还在

if(!malloc_zone_from_ptr((__bridge const void *)(strongself)))return;

但是它也不能解决全部的问题

因为我们不知道什么时候去调用类函数什么时候调用属性

这里大家有什么更好的想法，欢迎发表

七：非主线程刷UI类型crash防护（UI not on Main Thread）

目前初步的处理方案是swizzle UIView类的以下三个方法：

-(void)setNeedsLayout;

-(void)setNeedsDisplay;

-(void)setNeedsDisplayInRect:(CGRect)rect;

在这三个方法调用的时候判断一下当前的线程，如果不是主线程的话，直接利用 dispatch_async(dispatch_get_main_queue(), ^{ //调用原本方法 });

来将对应的刷UI的操作转移到主线程上，同时统计错误信息。

但是真正实施了之后，发现这三个方法并不能完全覆盖UIView相关的所有刷UI到操作，但是如果要将全部到UIView的刷UI的方法统计起来并且swizzle，感觉略笨拙而且不高效。但是这种crash占比并不高，我们重要的宗旨是降低再降低crash率，不是彻底的完全消灭，而且我们目前也没有办法完全消灭，只有我们掌握了底层的原理，才能灵活应变处理问题！