我们知道，在ObjC中向nil发送任何消息都不会导致崩溃，然而，在某些情况下这可能只是南柯一梦~
此次的问题，就发生我们的项目使用链式API之后
链式API的使用
如下为一个使用了链式API的People类代码：
@interface People : NSObject
- (People *(^)(NSString *sth))eat;
@end
@implementation People
- (People *(^)(NSString *sth))eat
{
return ^(NSString *sth) {
NSLog(@"I eat %@", sth);
return self;
};
}
@end
要说的是，以上代码并没有什么问题的，链式API十分的简洁好用。但是在以下情景中使用链式API，可能整个App都不好了
int main(int argc, char * argv[])
{
People *a = [[People alloc] init];
a.eat(@"苹果").eat(@"香蕉").eat(@"橘子");
a = nil;
a.eat(@"香蕉");
}
将a置为nil后，它就无福消受大香蕉了。此时的结果也只有一个，奔溃~~~~~~~
报错信息如下：
error: Execution was interrupted, reason: Attempted to dereference an invalid pointer..
The process has been returned to the state before expression evaluation.
ObjC中的nil
ObjC中向nil对象发送任何消息都不会崩溃，不用怀疑，这并没有什么问题，网络上也有大量文章介绍其原理。但是此处为什么崩溃了呢？
原因是、其实 a.eat(@"苹果") 并不是单纯的一次消息发送，而是做了以下两步操作：
- 第一步：调用a.eat，可以理解为取得这个block
- 第二步：传参并执行这个block
显然，问题就出在了第二步上，在a为nil时，a.eat为nil，第二步就等价执行了nil(@"苹果")。所以，崩的也不冤。
所以在此类场景下，建议优先判断指针是否为nil，再决定是否执行之后的操作。还有另外一个原因是：一次if判断相较于消息发送来讲是非常快的操作了。实测代码和结果如下：
int main(int argc, char * argv[])
{
/// 测试次数
int testCount = 100000000;
/// 每次测试中，消息发送的执行次数
int executeCount = 1;
People *x = [[People alloc] init];
People *y = nil;
NSDate *date1 = [NSDate date];
// 测试A：消息发送，sayHello为一空方法
for (int i = 0; i < testCount; i++) {
for (int j = 0; j < executeCount; j++) {
[x sayHello];
}
}
NSDate *date2 = [NSDate date];
// 测试B：消息发送，对象为nil
for (int i = 0; i < testCount; i++) {
for (int j = 0; j < executeCount; j++) {
[y sayHello];
}
}
NSDate *date3 = [NSDate date];
// 测试C：if判空，不执行消息发送
for (int i = 0; i < testCount; i++) {
if (y) { // 执行if判断后，可避免n多条无意义语句的执行
for (int j = 0; j < executeCount; j++) {
[y sayHello];
}
}
}
NSDate *date4 = [NSDate date];
// 打印结果
NSLog(@"A (!= nil): %lf", [date2 timeIntervalSinceDate:date1]);
NSLog(@"B ( = nil): %lf", [date3 timeIntervalSinceDate:date2]);
NSLog(@"C (nil+if): %lf", [date4 timeIntervalSinceDate:date3]);
}
测试结果如下（各执行1,0000,0000次测试，executeCount为每轮测试中方法的执行次数）：
| executeCount | A (执行空方法) | B (Object为nil) | C (nil+if判空) |
|---|---|---|---|
| 1 | 0.607867 | 0.491741 | 0.203444 |
| 10 | 3.852057 | 3.015501 | 0.210288 |
| 50 | 20.307179 | 15.178183 | 0.205914 |
- 由A、B可知，向nil发送消息还是比较慢的操作；
- 但B、C可知，if判断不涉及消息发送，执行速度非常快，且由此可避免多条无意义语句的执行（向nil发送消息），带来是时间红利更是明显。
针对此种情景的解决方案
上文已经提到通过判断对象是否为nil，再决定执行后续操作这一解决方案，这也最为简单高效。但是这一方案较容易出现漏判的情况，所以以下两种配合的方案也值得考虑：
- 1、根据业务场景将链式API抽出到OC方法中统一执行，这样如果对象为nil时，就到不了执行链式API这一步了。同时这样也有助于功能模块的进一步细分；
- 2、确保对象释放后，有关该对象的所有逻辑操作已取消（比如页面销毁时结束所有未完成的网络请求、DB操作），这个要结合具体业务场景进行处理。