前言
有时候无法避免地，服务器会传回一些脏数据，但这个锅我们自己得接好。
场景
比如我们接收的是一个NSMutableDictionary ，传回来的却是一个NSNull，在调用方法的时候必然会奔溃，因为NSMutableDictionary 的这个方法我NSNull 类里没有实现。可以模拟情况如下：
NSMutableDictionary * nullDic = [NSNull null];
[nullDic objectForKey:@"123"];
可以简单看一下nil 和 NSNull 的区别
当我们给一个NSNull对象发送消息的话，可能会崩溃（NSNull是有内存的），而发送给nil的话，是不会崩溃的。
我们也可以看一下objc_msgSend的源代码，如果传递给 objc_msgSend 的 self 参数是 nil ，该函数不会执行有意义的操作，直接返回。不会走到消息转发。
所以解决问题的一个思路就是把 NSNull 替换成 nil
怎么替换？如果是我来写的话。
我可能也会写一个NULL(safeCategory) 直接在消息转发的第三步只会返回一个自定义的方法签名，然后再把 target = nil
- (void)forwardInvocation:(NSInvocation *)anInvocation {
anInvocation.target = nil;
[anInvocation invoke];
}
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {
NSMethodSignature *Signature = [super methodSignatureForSelector:aSelector];
if (!signature) {
signature = [NSMethodSignature signatureWithObjCTypes:"^v^c"];
}
return signature;
}
NullSafe的实现
但作者在他的issue里写了这么一段话，原本应该返回的方法签名返回值和实际的方法签名需要保持一致
What about the return type? If the expected return type is a struct (> 8 bytes), and you return an integer, couldn't that corrupt the stack?
issue
这里我有些存疑，我既然生成了新的方法签名我怎么还要和之前的返回类型保持一致。我觉得可能是作者想错了。
但我想可能还有些其他原因，如果像我这么写，performselector一个未知的方法都不会走到崩溃
所以作者的写法会更复杂一些
作者把发送给NSNull的而NSNull又无法处理的消息经过如下几步处理：
1 创建缓存，缓存项目中类的所有类名
2 遍历缓存，寻找是否已经有可以执行此方法的类
3 如果有的话，返回这个NSMethodSignature
4 如果没有的话，返回nil奔溃
5 如果有的话，[invocation invokeWithTarget:nil];将消息转发给nil。
我解释一下。1的代码就如下cacheSignatures函数，没什么好说的，实现中规中矩（一般几w个类还会有性能瓶颈）。将所有的类加到了一个缓存字典中，除了performselector的方法都应该能找到对应归属的类
static void cacheSignatures()
{
}
// check implementation cache first
NSString *selectorString = NSStringFromSelector(selector);
signature = signatureCache[selectorString];
if (!signature)
{
for (Class someClass in classList)
{
// 判断 这个基于NSObject类的子类是否能够响应传入的方法
if ([someClass instancesRespondToSelector:selector])
{
// someClass类能够响应selector方法
// 返回NSMethodSignature对象，这个对象包含被标示的实例方法的描述。
signature = [someClass instanceMethodSignatureForSelector:selector];
break;
}
}
// cache for next time
signatureCache[selectorString] = signature ?: [NSNull null];
}
else if ([signature isKindOfClass:[NSNull class]])
{
// 永远不会走到这里
signature = nil;
}
第二步第三步如上，之所以我要找到对应的类就是为了 signature = [someClass instanceMethodSignatureForSelector:selector]通过类去获得正确的方法签名。
会出现第四步的是情况很少见，一般在所有类能找到对应的方法签名，否则编译都无法通过，除了performselector的方法。
这里的Crash作者没有去做避免，也不应该在这里去做避免。
这个时候就走向Crash了， 所以即使缓存了signature为NSNull
下次也不会走到这个判断 ([signature isKindOfClass:[NSNull class]])，（存的是内存，我需要重新启动APP ）
signature返回nil为什么奔溃？
这里就需要讲一下消息转发了，消息进入消息转发后有三步
1 + (BOOL)resolveInstanceMethod:(SEL)sel 或者 Class
2 - (id)forwardingTargetForSelector:(SEL)aSelector
3 - (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector
- (void)forwardInvocation:(NSInvocation *)anInvocation
刚接触消息转发的时候我困惑为什么消息转发要设计成3步，明明任何一步都能处理这个本来无法处理的消息
不知道读者会不会和我有一样的困惑
其实这里每一步做的事情都是不一样的
1 给原本的实例或者类一次增加方法的机会
2 将原本的方法子交给其他的类实现
3 第三步能做的事情就更多了，NSMethodSignature和taget 我都可以自定义，很多黑魔法的实现都依赖于第三步，比如JSPatch
在第三步中的2个方法，如果第一步的NSMethodSignature返回了nil，那么forwardInvocation就不会再走了，直接返回无法处理该方法。