iOS的Block

存取变量

Block将使用到的、作用域附近的变量的值建立一份快照拷贝到栈上。

1、读取和Block pointer同一个Scope的变量值：

{  
    int outA = 8;  
    int (^myPtr)(int) = ^(int a){ return outA + a;};  
    //block里面可以读取同一类型的outA的值  
    int result = myPtr(3);  // result is 11  
    NSLog(@"result=%d", result);  
}

下面这一段代码就不一样了

{
    int outA = 8;  
    int (^myPtr)(int) = ^(int a){ return outA + a;}; //block里面可以读取同一类型的outA的值  
    outA = 5;  //在调用myPtr之前改变outA的值  
    int result = myPtr(3);  // result的值仍然是11，并不是8  
    NSLog(@"result=%d", result);  
}

为什么result 的值仍然是11？而不是8呢？事实上，myPtr在其主体中用到的outA这个变量值的时候做了一个copy的动作，把outA的值copy下来，在Block中作为常量使用。所以，之后outA即使换成了新的值，对于myPtr里面copy的值是没有影响的。（类似于深拷贝）

需要注意的是，这里copy的值是变量的值，如果它是一个记忆体的位置（地址），换句话说，就是这个变量是个指针的话，它的值是可以在block里被改变的。(相当于浅拷贝，拷贝的只是一个指针地址，对象地址还是没变的)

{  
    NSMutableArray \*mutableArray = [NSMutableArray arrayWithObjects:@"one", @"two", @"three", nil];  
    int result = ^(int a){[mutableArray removeLastObject]; return a*a;}(5);  
    NSLog(@"test array :%@", mutableArray);  
}  
    
//原本mutableArray的值是{@"one",@"two",@"three"}，在block里面被更改mutableArray后，就变成{@"one", @"two"}了。

2、直接存取static类型的变量

因为全局变量或静态变量在内存中的地址是固定的，Block在读取该变量值的时候是直接从其所在内存读出，获取到的是最新值，而不是在定义时copy的常量。

{  
    static int outA = 8;  
    int (^myPtr)(int) = ^(int a){return outA + a;};  
    outA = 5;  
    int result = myPtr(3);  
    //result的值是8，因为outA是static类型的变量 (该变量在全局数据区分配内存,但作用域还是局部作用域) 
    NSLog(@"result=%d", result);     
}

3、Block Variable类型的变量

在某个变量前面如果加上修饰字“__block”的话（注意，block前面有两个下划线），这个变量就称作block variable。基本类型的Block变量等效于全局变量、或静态变量。

那么在block里面就可以任意修改此变量的值，如下代码：

{  
    __block int num = 5;  
      
    int (^myPtr)(int) = ^(int a){return num++;};  
    int (^myPtr2)(int) = ^(int a){return num++;};  
    int result = myPtr(0);   //result的值为5，num的值为6  
    result = myPtr2(0);      //result的值为6，num的值为7  
    NSLog(@"result=%d", result);      
}

4、weak–strong dance（避免循环引用）

  • 使用方将self或成员变量加入block之前要先将self变为__weak
  • 在多线程环境下（block中的weakSelf有可能被析构的情况下），需要先将self转为strong指针，避免在运行到某个关键步骤时self对象被析构。
    以上两条合起来有个名词叫weak–strong dance

以下是使用weak–strong dance的经典代码

__weak __typeof(self)weakSelf = self和
__strong __typeof(weakSelf)strongSelf = weakSelf

//AFNetworking经典代码
__weak __typeof(self)weakSelf = self;
AFNetworkReachabilityStatusBlock callback = ^(AFNetworkReachabilityStatus status) {
    __strong __typeof(weakSelf)strongSelf = weakSelf;
    strongSelf.networkReachabilityStatus = status;
    if (strongSelf.networkReachabilityStatusBlock) {
        strongSelf.networkReachabilityStatusBlock(status);
    }
};

其中用到了__typeof(self)，这里涉及几个知识点：

  • __typeof、___typeof___ 、typeof的区别
    恩~~他们没有区别，但是这牵扯一段往事，在早期C语言中没有typeof这个关键字，__typeof、__typeof__是在C语言的扩展关键字的时候出现的。typeof是现代GNU C++的关键字，从Objective-C的根源说，他其实来自于C语言，所以AFNetworking使用了继承自C的关键字。

  • 对于老的LLVM编译器上面这句话会编译报错，所以在很早的ARC使用者中流行__typeof(&*self)这种写法，原因如下

第四、五、六行，如果不转成strongSelf而使用weakSelf，后面几句话中，有可能在第四句执行之后self的对象可能被析构掉，然后后面的StausBlock没有执行，导致逻辑错误。

大致说法是老LLVM编译器会将__typeof转义为 XXX类名 const __strong的__strong和前面的__weak关键字对指针的修饰又冲突了，所以加上&对指针的修饰。

为了使用方便我们可以用一份宏定义

#ifndef weakify
    #if DEBUG
        #if __has_feature(objc_arc)
        #define weakify(object) autoreleasepool{} __weak __typeof__(object) weak##_##object = object;
        #else
        #define weakify(object) autoreleasepool{} __block __typeof__(object) block##_##object = object;
        #endif
    #else
        #if __has_feature(objc_arc)
        #define weakify(object) try{} @finally{} {} __weak __typeof__(object) weak##_##object = object;
        #else
        #define weakify(object) try{} @finally{} {} __block __typeof__(object) block##_##object = object;
        #endif
    #endif
#endif

#ifndef strongify
    #if DEBUG
        #if __has_feature(objc_arc)
        #define strongify(object) autoreleasepool{} __typeof__(object) object = weak##_##object;
        #else
        #define strongify(object) autoreleasepool{} __typeof__(object) object = block##_##object;
        #endif
    #else
        #if __has_feature(objc_arc)
        #define strongify(object) try{} @finally{} __typeof__(object) object = weak##_##object;
        #else
        #define strongify(object) try{} @finally{} __typeof__(object) object = block##_##object;
        #endif
    #endif
#endif

//使用方法
@weakify(self);
AFNetworkReachabilityStatusBlock callback = ^(AFNetworkReachabilityStatus status) {
    @strongify(self)
    if(!self)return; 
    self.networkReachabilityStatus = status; 
    if (self.networkReachabilityStatusBlock) {
        self.networkReachabilityStatusBlock(status);
    }
};

因为对象obj在Block被copy到堆上的时候自动retain了一次。因为Block不知道obj什么时候被释放，为了不在Block使用obj前被释放，Block retain了obj一次，在Block被释放的时候，obj被release一次。

retain cycle问题的根源在于Block和obj可能会互相强引用，互相retain对方，这样就导致了retain cycle，最后这个Block和obj就变成了孤岛，谁也释放不了谁。

黑幕背后的__block修饰符

我们知道在Block使用中，Block内部能够读取外部局部变量的值。但我们需要改变这个变量的值时，我们需要给它附加上__block修饰符。

__block另外一个比较多的使用场景是，为了避免某些情况下Block循环引用的问题，我们也可以给相应对象加上__block 修饰符。

为什么不使用__block就不能在Block内部修改外部的局部变量？

我们把以下代码通过 clang -rewrite-objc 源代码文件名重写：

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        int val = 10;
        void (^block)(void) = ^{
            NSLog(@"%d", val);
        };
        block();
    }
    return 0;
}

得到如下代码:

struct __main_block_impl_0 {
  struct __block_impl impl;
  struct __main_block_desc_0* Desc;
  int val;
  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int _val, int flags=0) : val(_val) {
    impl.isa = &_NSConcreteStackBlock;
    impl.Flags = flags;
    impl.FuncPtr = fp;
    Desc = desc;
  }
};
static void __main_block_func_0(struct __main_block_impl_0 *__cself) {
  int val = __cself->val; // bound by copy
  NSLog((NSString *)&__NSConstantStringImpl__val_folders_gm_0jk35cwn1d3326x0061qym280000gn_T_main_41daf1_mi_0, val);
}
static struct __main_block_desc_0 {
  size_t reserved;
  size_t Block_size;
} __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0)};

int main(int argc, const char * argv[]) {
    /* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool; 
        int val = 10;
        void (*block)(void) = (void (*)())&__main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA, val);
        ((void (*)(__block_impl *))((__block_impl *)block)->FuncPtr)((__block_impl *)block);
    }
    return 0;
}

我们注意到Block实质被转换成了一个__main_block_impl_0的结构体实例，其中__main_block_impl_0结构体的成员包括局部变量val。在__main_block_impl_0结构体的构造方法中，val作为第三个参数传递进入。

但执行我们的Block时，通过block找到Block对应的方法执行部分__main_block_func_0，并把当前block作为参数传递到__main_block_func_0方法中。

__main_block_func_0的第一个参数声明如下：
struct __main_block_impl_0 *__cself
它和Objective－C的self相同，不过它是指向 __main_block_impl_0 结构体的指针。这个时候我们就可以通过__cself->val对该变量进行访问。

因为int val变量定义在栈上，在block调用时其实已经被销毁，但是我们还可以正常访问这个变量。但是试想一下，如果我希望在block中修改变量的值，那么受到影响的是int val而非__cself->val，事实上即使是__cself->val，也只是截获的自动变量的副本，要想修改在block定义之外的自动变量，是不可能的事情。

所以，对于auto类型的局部变量，不允许block进行修改是合理的。

__block 到底是怎么工作的?

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        __block NSInteger val = 0;
        void (^block)(void) = ^{
            val = 1;
        };
        block();
        NSLog(@"val = %ld", val);
    }
    return 0;
}

可得到如下代码：

struct __Block_byref_val_0 {
     void *__isa;
     __Block_byref_val_0 *__forwarding;
     int __flags;
     int __size;
     NSInteger val;
};
struct __main_block_impl_0 {
      struct __block_impl impl;
      struct __main_block_desc_0* Desc;
      __Block_byref_val_0 *val; // by ref
      __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, __Block_byref_val_0 *_val, int flags=0) : val(_val->__forwarding) {
        impl.isa = &_NSConcreteStackBlock;
        impl.Flags = flags;
        impl.FuncPtr = fp;
        Desc = desc;
      }
};
static void __main_block_func_0 (struct __main_block_impl_0 *__cself) {
  __Block_byref_val_0 *val = __cself->val; // bound by ref
  (val->__forwarding->val) = 1;
}
static void __main_block_copy_0 (struct __main_block_impl_0*dst, struct __main_block_impl_0*src) {
    _Block_object_assign((void*)&dst->val, (void*)src->val, 8/*BLOCK_FIELD_IS_BYREF*/);
}
static void __main_block_dispose_0 (struct __main_block_impl_0*src)     {
    _Block_object_dispose((void*)src->val, 8/*BLOCK_FIELD_IS_BYREF*/);
}
static struct __main_block_desc_0 {
  size_t reserved;
  size_t Block_size;
  void (*copy)(struct __main_block_impl_0*, struct __main_block_impl_0*);
  void (*dispose)(struct __main_block_impl_0*);
} __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0), __main_block_copy_0, __main_block_dispose_0};

int main(int argc, const char * argv[]) {
    {   __AtAutoreleasePool __autoreleasepool; 
        __attribute__((__blocks__(byref))) __Block_byref_val_0 val = {(void*)0,(__Block_byref_val_0 *)&val, 0, sizeof(__Block_byref_val_0), 0};
        void (*block)(void) = (void (*)())&__main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA, (__Block_byref_val_0 *)&val, 570425344);
        ((void (*)(__block_impl *))((__block_impl *)block)->FuncPtr)((__block_impl *)block);
        NSLog((NSString *)&__NSConstantStringImpl__val_folders_gm_0jk35cwn1d3326x0061qym280000gn_T_main_d7fc4b_mi_0, (val.__forwarding->val));
    }
    return 0;
}

我们发现由__block修饰的变量变成了一个__Block_byref_val_0结构体类型的实例。该结构体的声明如下：

struct __Block_byref_val_0 {
     void *__isa;
     __Block_byref_val_0 *__forwarding;
     int __flags;
     int __size;
     NSInteger val;
};

我们从上述被转化的代码中可以看出 Block 本身也一样被转换成了 __main_block_impl_0 结构体实例，该实例持有__Block_byref_val_0结构体实例的指针。
我们再看一下赋值和执行部分代码被转化后的结果：

static void __main_block_func_0 (struct __main_block_impl_0 *__cself) {
  __Block_byref_val_0 *val = __cself->val; // bound by ref
  (val->__forwarding->val) = 1;
}
((void (*)(__block_impl *))((__block_impl *)block)->FuncPtr)((__block_impl *)block);

我们从__cself找到__Block_byref_val_0结构体实例，然后通过该实例的__forwarding访问成员变量val。成员变量val是该实例自身持有的变量，指向的是原来的局部变量。如图所示：

。
1420513789717076.jpg

上面部分我们展示了__block变量在Block查看和修改的过程，那么问题来了：

当block作为回调执行时，局部变量val已经出栈了，这个时候代码为什么还能正常工作呢?

  • 我们为什么是通过成员变量__forwarding而不是直接去访问结构体中我们*
  • 需要修改的变量呢? __forwarding被设计出来的原因又是什么呢?

存储域

通过上面的描述我们知道Block和__block变量实质就是一个相应结构体的实例。我们在上述转换过的代码中可以发现 __main_block_impl_0 结构体构造函数中， isa指向的是 _NSConcreteStackBlock。Block还有另外两个与之相似的类:

  • _NSConcreteStackBlock 保存在栈中的block，出栈时会被销毁
  • _NSConcreteGlobalBlock 全局的静态block，不会访问任何外部变量
  • _NSConcreteMallocBlock 保存在堆中的block，当引用计数为0时会被销毁

上述示例代码中，Block是被设为_NSConcreteStackBlock，在栈上生成。当我们把Block作为全局变量使用时，对应生成的Block将被设为_NSConcreteGlobalBlock，如:

void (^block)(void) = ^{NSLog(@"This is a Global Block");};
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        block();
    }
    return 0;
}

该代码转换后的代码中，Block结构体的成员变量isa的初始化如下:
impl.isa = &_NSConcreteGlobalBlock;

而_block变量中结构体成员__forwarding就在此时保证了从栈上复制到堆上能够正确访问__block变量。在这种情况下，只要栈上的_block变量的成员变量__forwarding指向堆上的实例，我们就能够正确访问。

我们一般可以使用copy方法手动将 Block 或者 __block变量从栈复制到堆上。比如我们把Block做为类的属性访问时，我们一般把该属性设为copy。有些情况下我们可以不用手动复制,比如Cocoa框架中使用含有usingBlock方法名的方法时，或者GCD的API中传递Block时。

当一个Block被复制到堆上时，与之相关的__block变量也会被复制到堆上，此时堆上的Block持有相应堆上的__block变量。当堆上的__block变量没有持有者时，它才会被废弃。(这里的思考方式和objc引用计数内存管理完全相同。)

而在栈上的__block变量被复制到堆上之后，会将成员变量__forwarding的值替换为堆上的__block变量的地址。这个时候我们可以通过以下代码访问:

val.__forwarding->val

如下面:

1420513884222794.jpg

__block变量和循环引用问题

__block修饰符可以指定任何类型的局部变量，上面的转换代码中，有如下代码:

static void __main_block_copy_0 (struct __main_block_impl_0*dst, struct __main_block_impl_0*src) {
    _Block_object_assign((void*)&dst->val, (void*)src->val, 8/*BLOCK_FIELD_IS_BYREF*/);
}
static void __main_block_dispose_0 (struct __main_block_impl_0*src)     {
    _Block_object_dispose((void*)src->val, 8/*BLOCK_FIELD_IS_BYREF*/);
}

当Block从栈复制到堆时，会使用_Block_object_assign函数持有该变量(相当于retain)。当堆上的Block被废弃时，会使用_Block_object_dispose函数释放该变量(相当于release)。

由上文描述可知，我们可以使用下述代码解除Block循环引用的问题:

__block id tmp = self;
void(^block)(void) = ^{
    tmp = nil;
};
block();
  • 通过执行block方法，nil被赋值到_block变量tmp中。这个时候_block变量对 self 的强引用失效，从而避免循环引用的问题。使用__block变量的优点是:
  • 通过__block变量可以控制对象的生命周期。
    在不能使用__weak修饰符的环境中，我们可以避免使用* __unsafe_unretained修饰符。
  • 在执行Block时可动态地决定是否将nil或者其它对象赋值给__block变量。但是这种方法有一个明显的缺点就是，我们必须去执行Block才能够解除循环引用问题，否则就会出现问题。

参考资料

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,324评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,303评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,192评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,555评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,569评论 5赞 365
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,566评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,927评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,583评论 0赞 257
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,827评论 1赞 297
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2赞 320
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,365评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,941评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2赞 342