转载

iOS KVO crash 自修复技术实现与原理解析

摘要： KVO API设计非常不合理，于是有很多的KVO三方库，比如 KVOController 用更优的API来规避这些crash，但是侵入性比较大，必须编码规范来约束所有人都要使用该方式。有没有什么更优雅，无感知的接入方式？

前言

【前言】KVO API设计非常不合理，于是有很多的KVO三方库，比如 KVOController 用更优的API来规避这些crash，但是侵入性比较大，必须编码规范来约束所有人都要使用该方式。有没有什么更优雅，无感知的接入方式？

简介

KVO crash 也是非常常见的 Crash 类型，在探讨 KVO crash 原因前，我们先来看一下传统的KVO写发：

iOS KVO crash 自修复技术实现与原理解析

看到如上的写发，大概我们就明白了 API 设计不合理的地方：

B 需要做的工作太多，B可能引起Crash的点也太多：

B 需要主动移除监听者的时机，否则就crash：

B 在释放变为nil后，hook dealloc时机
A 在释放变为nil后否则报错 Objective-C Thread 1: EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

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

B 不能移除监听者A的时机，否则就crash：

B没有被A监听
B已经移除A的监听。

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

采取的措施：

B添加A监听的时候，避免重复添加，移除的时候避免重复移除。
B dealloc时及时移除 A
A dealloc时，让 B 移除A。
避免重复添加，避免重复移除。

报错信息一览：

iOS KVO crash 自修复技术实现与原理解析

防crash措施

于是有很多的KVO三方库，比如 KVOController 用更优的API来规避这些crash，但是侵入性比较大，必须编码规范来约束所有人都要使用该方式。有没有什么更优雅，无感知的接入方式？

那便是我们下面要讲的 KVO crash 防护机制。

我们可以对比下其他的一些KVO防护方案：

网络上有一些类似的方案，“大白健康系统”方案大致如下：

KVO的被观察者dealloc时仍然注册着KVO导致的crash 的情况，可以将NSObject的dealloc swizzle，在object dealloc的时候自动将其对应的kvodelegate所有和kvo相关的数据清空，然后将kvodelegate也置空。避免出现KVO的被观察者dealloc时仍然注册着KVO而产生的crash

这样未免太过麻烦，我们可以借助第三方库 CYLDeallocBlockExecutor hook 任意一个对象的 dealloc 时机，然后在 dealloc 前进行我们需要进行的操作，因此也就不需要为 NSObject 加 flag 来进行全局的筛选。flag 效率非常底，影响 app 性能。

“大白健康系统”思路是建立一个delegate，观察者和被观察者通过delegate间接建立联系，由于没有demo源码，这种方案比较繁琐。可以考虑建立一个哈希表，用来保存观察者、keyPath的信息，如果哈希表里已经有了相关的观察者，keyPath信息，那么继续添加观察者的话，就不载进行添加，同样移除观察的时候，也现在哈希表中进行查找，如果存在观察者，keypath信息，那么移除，如果没有的话就不执行相关的移除操作。要实现这样的思路就需要用到methodSwizzle来进行方法交换。我这通过写了一个NSObject的cagegory来进行方法交换。示例代码如下：

下面是核心的swizzle方法：

iOS KVO crash 自修复技术实现与原理解析