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

[转载]iOS常见crash以及解决方案

 

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

 

我们常见的crash有哪些呢?

  1. unrecognized selector crash  (没找到对应的函数)
  2. KVO crash :(KVO的被观察者dealloc时仍然注册着KVO导致的crash,添加KVO重复添加观察者或重复移除观察者 )
  3. NSNotification crash:(当一个对象添加了notification之后,如果dealloc的时候,仍然持有notification)
  4. NSTimer类型crash:(需要在合适的时机invalidate 定时器,否则就会由于定时器timer强引用target的关系导致 target不能被释放,造成内存泄露,甚至在定时任务触发时导致crash)
  5. Container类型crash:(数组,字典,常见的越界,插入,nil)
  6. 野指针类型的crash
  7. 非主线程刷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的整个关系,如下图:

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

这样做的好处有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的强引用问题。 可以用如下图的方案来解决:

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

在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是一个虚类,你可以通过继承它,并重写这两个方法以实现消息转发到另一个实例

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

栗子:

/**
 桥接层
 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率,不是彻底的完全消灭,而且我们目前也没有办法完全消灭,只有我们掌握了底层的原理,才能灵活应变处理问题!

 

 

 

 

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

上一篇:IIS部署网站出现Server Error in '/' Application.CS0016的解决办法


下一篇:poj1003