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率
- 我们常见的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类型中占着比较大的成分,通常是因为一个对象调用了一个不属于它方法的方法导致的。
例如调用以下一段代码就会产生crash:
具体crash时的表现见下图:
1.2 方法调用流程
函数调用的流程如下:
1:首先,在相应操作的对象中的缓存方法列表中找调用的方法,如果找到,转向相应的函数
2:如果没找到在对象的类方法列表中找调用的方法,如果找到,转向相应的实现执行
3:如果没有找到,去父类指针指向的对象中执行1,2
4:以此类推,如果一直到根类还没有找到,转向拦截调用,走消息转发
5:如果没有重写拦截调用的方法,程序报错。
1.3 拦截调用:
拦截调用就是,在找不到调用的方法程序崩溃之前,你有机会通