不起眼的nil的潜在风险

我们知道，在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操作），这个要结合具体业务场景进行处理。