针对 dispatch_once 的优化
dispatch_once 说明
先看这个
static id x;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
x = [[self alloc] init];
});
return x;
很多人写过类似的代码吧？dispatch_once就是让里面的代码只执行一次——跨线程调用是安全的。
前因
有人拿 dispatch_once 和 @synchronized 比较。
用 dispatch_once 写单例，通常情况下 dispatch_once所在方法调用次数会很高，第一次调用的情况比较特殊，谁又会去在乎那特殊一次的发现不了的影响，比较的重点就在于已经调用过一次的前提下，之后再经过这处代码的效率。
而比较的结果是 dispatch_once 效率更高。注：DEBUG模式下。
那么问题来了，用 dispatch_once 或 @synchronized 或者其它什么东西的原因是为了跨线程安全，那么只要用 dispatch_once 保底就行了，没必要每次都跑到，比如这样：
+ (instancetype)xxx {
static dispatch_once_t onceToken;
static BOOL didRun = NO;
if (!didRun) {
dispatch_once(&onceToken, ^{
//一次代码
didRun = YES;
});
}
return x;
}
对于已经跑过一次之后的情况，用一个变量记录一下，然后只要用这个变量就可以判断确实跑过了一次。
至于第一次如果是跨线程多次同时调用（安全上这是一种需要考虑和测试的情况，但在性能上请直接无视吧），虽然这个变量没有来得及同步，但内部还有个dispatch_once进行安全判断，没有任何的危险，也不需要用volatile来修饰。
单例还可以这样
+ (instancetype)xxx {
static id x;
static dispatch_once_t onceToken;
if (!x) {//新人注意，也不知道dispatch_once里是什么时候给onceToken赋的值。只要不能排除在执行block之前就赋值的可能性，这里就不能用if (!onceToken)来判断。
dispatch_once(&onceToken, ^{
x = [[self alloc] init]; //新人注意，要是对x还有设置，可以先用个临时变量，都处理好后再赋值给x，可别刚alloc init就给x赋值，结果其它设置还没进行呢，别的线程就跳过if(!x){}直接就把x拿去用了。
});
}
return x;
}
那么，接下来开始测试性能吧，iPhone6 sp
首先，debug模式下：
NSTimeInterval t1 = [NSDate timeIntervalSinceReferenceDate];
for (NSInteger j = 0; j < 10000000; j ++) {
}
NSTimeInterval t2 = [NSDate timeIntervalSinceReferenceDate];
NSLog(@"%lf", t2 - t1);
0.14秒
NSTimeInterval t1 = [NSDate timeIntervalSinceReferenceDate];
for (NSInteger j = 0; j < 10000000; j ++) {
static NSInteger i = 0;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
i ++;
});
}
NSTimeInterval t2 = [NSDate timeIntervalSinceReferenceDate];
NSLog(@"%lf", t2 - t1);
0.21秒，只比空的for循环多用了0.07秒，一点都不值得去优化
NSTimeInterval t1 = [NSDate timeIntervalSinceReferenceDate];
for (NSInteger j = 0; j < 10000000; j ++) {
static NSInteger i = 0;
static dispatch_once_t onceToken;
if (i == 0) {
dispatch_once(&onceToken, ^{
i ++;
});
}
}
NSTimeInterval t2 = [NSDate timeIntervalSinceReferenceDate];
NSLog(@"%lf", t2 - t1);
约0.145左右，和空的for循环时间几乎一样，看不出多少差别，看起来是有进步的。
……但是……
这还没完，这只是debug模式下的测试，真正外发都是release版的，就用默认的-Os来试试吧。
空的for循环，没的说，在-Os级别下没它什么事，时间0。
接下来两个的时间分别是0.027，0.052，没错，多了一个if(i==0)的判断后，时间反而长了，鬼知道这里的for循环被编译器优化成什么样子了，根本没有可比性。
为了增加对比性，新建了个工程，代码如下：
long long check1(void) {
static NSInteger i = 0;
static dispatch_once_t onceToken;
if (i == 0) {
dispatch_once(&onceToken, ^{
i ++;
});
}
return i;
}
long long check2(void) {
static NSInteger i = 0;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
i ++;
});
return i;
}
然后用-Os级别编译成静态库后引入这个项目，然后继续用debug模式测试，
NSTimeInterval t1 = [NSDate timeIntervalSinceReferenceDate];
for (NSInteger j = 0; j < 10000000; j ++) {
check1();check1();check1();check1();check1();
check1();check1();check1();check1();check1();
}
NSTimeInterval t2 = [NSDate timeIntervalSinceReferenceDate];
NSLog(@"%lf", t2 - t1);
约0.31秒，
循环内部换成20次check2()，约0.25秒，走dispatch_once检查的还是比走if (i == 0)快。莫非是if (i == 0)没生效？里面再加变量统计了一下，if里面确实只走了1次。那么究竟发生了什么，这就是传说中的编译器的优化吗？我们花了这一天时间所做的比较，在-Os级别的优化后变得毫无意义。
结论
事后小节
这种写在for循环里都不能让循环时间改变多少的代码，先不说能不能优化好，就算优化的再好又能如何？不要再在没有任何优化价值的地方纠结了。
