block详解

开始之前,我想先提几个问题,看看大家是否对此有疑惑。唐巧已经写过一篇对block很有研究的文章,大家可以去看看(本文会部分引用巧哥文中出现的图和代码)。在巧哥的基础上,我补充一些block相关的知识点和代码,并且概括并修正一些观点。

1.block是什么?block是对象吗?

2.block分为哪几种?__blcok关键字的作用?

3.block在ARC和MRC下的区别?

4.block的生命周期?

5.block对于以参数形式传进来的对象,会不会强引用??

block是什么?block是对象吗?
先介绍一下什么是闭包。在 wikipedia 上,闭包的定义是:

In programming languages, a closure is a function or reference to a function together with a referencing environment—a table storing a reference to each of the non-local variables (also called free variables or upvalues) of that function.

翻译过来,闭包是一个函数(或指向函数的指针),再加上该函数执行的外部的上下文变量(有时候也称作自由变量)。

block 实际上就是 Objective-C 语言对于闭包的实现。

block是不是对象?答案显而易见:是的。

下图是block的数据结构定义,显而易见,在Block_layout里,我们看到了isa指针,这里我们不具体对isa指针展开,也不对block具体数据结构展开,想了解详细可以看唐巧的文章。

回到上文,为什么说block是对象呢,原因就在于isa指针。那么这个isa指针是何物呢?

所有对象的都有isa 指针,用于实现对象相关的功能。

看到这,你应该明白,block其实就是objc对于闭包的对象实现。


block的数据结构

block分为哪几种?__blcok关键字的作用?

分为三种,即NSConcreteGlobalBlock、NSConcreteStackBlock、NSConcreteMallocBlock。

详细剖析这三种block,首先是NSConcreteGlobalBlock:

简单地讲,如果一个block中没有引用外部变量,就是NSConcreteGlobalBlock。

如下图所示:


NSConcreteGlobalBlock

需要注意的是,NSConcreteGlobalBlock是全局的block,在编译期间就已经决定了,如同宏一样。

什么是NSConcreteStackBlock呢:

可以这么理解,NSConcreteStackBlock就是引用了外部变量的block,上代码:


NSConcreteStackBlock

NSConcreteStackBlock不会持有外部对象
从打印的日志可以看出,引用计数始终没变。

NSConcreteMallocBlock:

看似最为神秘的NSConcreteMallocBlock其实就是一个block被copy时,将生成NSConcreteMallocBlock(block没有retain)。怎么样,是不是很简单


NSConcreteMallocBlock

NSConcreteMallocBlock
需要注意的是,NSConcreteMallocBlock会持有外部对象!


NSConcreteMallocBlock会持有外部对象

通过调用Block_copy()方法或者直接向他发送OC的copy消息完成。这就是所谓的Block_copy()。

看到了吧,只要这个NSConcreteMallocBlock存在,内部对象的引用计数就会+1。

Block_copy()

首先我们来看Block.h。其中有下面的定义:

#define Block_copy(...) ((__typeof(__VA_ARGS__))_Block_copy((const void *)(__VA_ARGS__)))

void *_Block_copy(const void *arg);

所以Block_copy是一个宏,它将传入的参数转换为一个const void *然后传递给_Block_copy()方法。_Block_copy()的实现在runtime.c

void *_Block_copy(const void *arg) {
    return _Block_copy_internal(arg, WANTS_ONE);
}

所以也就是调用_Block_copy_internal方法,传入block自己和WANTS_ONE。为了明白这什么意思,我们需要看一下实现代码。也在runtime.c。下面是方法的实现,已经删掉不想干的部分(主要是垃圾收集的部分):

static void *_Block_copy_internal(const void *arg, const int flags) {
    struct Block_layout *aBlock;
    const bool wantsOne = (WANTS_ONE & flags) == WANTS_ONE;

    // 1
    if (!arg) return NULL;

    // 2
    aBlock = (struct Block_layout *)arg;

    // 3
    if (aBlock->flags & BLOCK_NEEDS_FREE) {
        // latches on high
        latching_incr_int(&aBlock->flags);
        return aBlock;
    }

    // 4
    else if (aBlock->flags & BLOCK_IS_GLOBAL) {
        return aBlock;
    }

    // 5
    struct Block_layout *result = malloc(aBlock->descriptor->size);
    if (!result) return (void *)0;

    // 6
    memmove(result, aBlock, aBlock->descriptor->size); // bitcopy first

    // 7
    result->flags &= ~(BLOCK_REFCOUNT_MASK);    // XXX not needed
    result->flags |= BLOCK_NEEDS_FREE | 1;

    // 8
    result->isa = _NSConcreteMallocBlock;

    // 9
    if (result->flags & BLOCK_HAS_COPY_DISPOSE) {
        (*aBlock->descriptor->copy)(result, aBlock); // do fixup
    }

    return result;
}

主要做了以下工作:

  1. 如果传入参数是NULL就直接返回NULL。防止传入一个NULL的Block。

  2. 将参数转换为一个struct Block_layout类型的指针。你也许还记得第一篇文章中提到它。它就是block内部一个包含了实现函数和一些元数据的数据结构。

  3. 如果block的flags字段包含BLOCK_NEEDS_FREE,那么这是一个堆block(稍后你就明白)。这里只需要增加引用计数然后返回原blcok。

  4. 如果这是一个全局block(回看第一篇文章),那么不需要做任何事,直接返回原block。因为全局block是一个单例。

  5. 如果走到这里,那么这一定是一个栈上分配的block。那样的话,block需要拷贝到堆上。这才是有趣的部分。第一步,调用malloc()创建一块特定的内存。如果创建失败,返回NULL;否则,继续。

  6. 调用memmove()方法将当前栈上分配的block按位拷贝到我们刚刚创建的堆内存上。这样可以保证所有的元数据都拷贝过来,比如descriptor。

  7. 接下来,更新标志位。第一行确保引用计数为0。注释表明这行其实不需要——大概这个时候引用计数已经是0了。我猜保留这行是因为以前有个bug导致这里的引用计数不是0(所以说runtime的代码也会偷懒)。下一行设置了BLOCK_NEEDS_FREE标志位,表明这是一个堆block,一旦引用计数减为0,它所占用的内存将被释放。|1操作设置block的引用计数为1。

  8. block的isa指针被设置为_NSConcreteMallocBlock,说明这是个堆block。

  9. 最后,如果block有一个拷贝辅助函数,那么它将被调用。必要的时候编译器会生成拷贝辅助函数。比如一个捕获了对象的block就需要。那么拷贝辅助函数将持有被捕获的对象。

哈哈,已经十分清晰了。现在你知道拷贝一个block到底发生了什么事!但那只是图片展示的一半内容,释放一个block又会怎么样呢?

Block_release()

Block_copy()图的另一半是Block_release()。实际上这又是一个宏:

#define Block_release(...) _Block_release((const void *)(__VA_ARGS__))

Block_copy()一样,Block_release()也是转换传入的参数然后调用一个方法。这一定程度上解放了程序员的双手,他们不用自己做转换。

我们来看看_Block_release()的源码(简明起见,重新整理了代码顺序,并删除了垃圾回收相关的代码):

    // 1
    struct Block_layout *aBlock = (struct Block_layout *)arg;
    if (!aBlock) return;

    // 2
    int32_t newCount;
    newCount = latching_decr_int(&aBlock->flags) & BLOCK_REFCOUNT_MASK;

    // 3
    if (newCount > 0) return;

    // 4
    if (aBlock->flags & BLOCK_NEEDS_FREE) {
        if (aBlock->flags & BLOCK_HAS_COPY_DISPOSE)(*aBlock->descriptor->dispose)(aBlock);
        _Block_deallocator(aBlock);
    }

    // 5
    else if (aBlock->flags & BLOCK_IS_GLOBAL) {
        ;
    }

    // 6
    else {
        printf("Block_release called upon a stack Block: %p, ignored\n", (void *)aBlock);
    }
}

这段代码做了这些事:

  1. 首先,参数被转换为一个指向struct Block_layout的指针。如果传入NULL,直接返回。

  2. 标志位部分表示引用计数减1(之前Block_copy()中标志位操作代表的是引用计数置为1)。

  3. 如果新的引用计数值大于0,说明有其他东西在引用block,所以block不应该被释放。

  4. 否则,如果标志位包含BLOCK_NEEDS_FREE,那么这是一个堆block而且引用计数为0,应该被释放。首先block的处理辅助函数(dispose helper)被调用,它是拷贝辅助函数(copy helper)的反义词,执行相反的操作,比如释放被捕获的对象。最后调用_Block_deallocator方法释放block。如果你查找runtime.c你就会发现这个方法最后就是一个free的函数指针,释放malloc分配的内存。

  5. 如果到这一步且lock是全局的,什么也不做。

  6. 如果到这一步,一定是发生了未知状况,因为一个栈block试图在这里释放,输出一行警告。实际上,你应该永远不会走到这一步。

下面来说说__block这个关键字:

先上一个例子,你们很快就会明白了

__block example1

没错,前文说过,block引用外部是以捕获的形式来捕捉的,而没有声明__block,则会将外部变量copy进block,若用了__block,则是复制其引用地址来实现访问。这就是为什么声明了__block,在block内部改变就会对外有影响的原因了。

注意!!这里需要知道的是,在MRC环境下,如果没有用__block,会对外部对象采用copy的操作,而用了__block则不会用copy的操作。

上代码:


__block example2

哈哈哈,怎么样,所以从更底层的角度来说,在MRC环境下,__block根本不会对指针所指向的对象执行copy操作,而只是把指针进行的复制。而这一点往往是很多新手&老手所不知道的!

而在ARC环境下,对于声明为__block的外部对象,在block内部会进行retain,以至于在block环境内能安全的引用外部对象,所以要谨防循环引用的问题!

block在ARC和MRC下的区别?
首先要指正下巧哥博客的观点:

在 ARC 开启的情况下,将只会有 NSConcreteGlobalBlock 和 NSConcreteMallocBlock 类型的 block。

在上面介绍NSConcreteStackBlock的时候,是在ARC环境下跑的,而打印出来的日志明确的显示出,当时的block类型为NSConcreteStackBlock。

而实际上,为什么大家普遍会认为ARC下不存在NSConcreteStackBlock呢?

这是因为本身我们常常将block赋值给变量,而ARC下默认的赋值操作是strong的,到了block身上自然就成了copy,所以常常打印出来的block就是NSConcreteMallocBlock了。

so,在ARC下,大部分的应用场景下,几乎可以说是全部都为NSConcreteMallocBlock或者是NSConcreteGlobalBlock。那么问题来了,我们知道NSConcreteMallocBlock是会持有外部变量的,而此时如果它所持有的外部变量正好又持有它,就会产生循环引用的问题。

让我们来聊聊block的生命周期!

block的生命周期?
谈到block生命周期,其实这是一个非常严肃的话题,虽然block简单易用,老少皆宜,但是一旦使用不慎容易造成“强撸灰飞烟灭”的后果(内存泄露)。

ps:接下来的例子都用ARC来展示了

首先展示:


循环引用

不用看了,这个object永远也不会被释放,这是一个很典型的循环引用情形。object持有了block(读者可以想象此处为何为NSConcreteMallocBlock,提示:在ARC环境下),而block又持有了object,于是造成死锁,object再也不会被释放了。此时机智的编译器给了你warning,但是在很多复杂的情况下,编译器并不能识别出循环引用的场景。而此时你就需要注意了!

那么,我是如何来处理block的生命周期相关问题的呢,首先前文提到,block是一个对象,既然是一个对象,它必然有着和对象一样的生命周期即如果没有被引用就会被释放。

所以block的生命周期归结起来很简单,只要看持有block的对象是不是也被block持有,如果没有持有,就不用担心循环引用问题了。

但是像上面的情况,如果产生相互持有的情况该肿么办!

你可以用__weak(ARC)或__block(MRC)来解决:


weak解决循环引用

看,现在就可以愉快的释放了。

block对于以参数形式传进来的对象,会不会强引用?

唉,不知不觉已经快半夜2点了,对于这部分的话,其实也是闲着蛋疼在想这个问题。

其实block与函数和方法一样,对于传进来的参数,并不会持有

证据如下


block不会持有参数对象

总结:
到这里,对于block的介绍结束了。实际运用中其实不用太关心这些原理的,只需要正确掌握好block的生命周期就可以灵活地运用block了。但是对于一个资深开发者来说,block的深层次掌握还是必须的!

一、整体介绍

  • 定义:C语言的匿名函数,􏰀提前准备一段代码,在需要的时候调用。
  • 底层:是一个指针结构体,在终端下可以通过clang -rewrite-objc 文件名(会在当前目录生成.cpp文件)指令看看c++代码,它的实现底层。

注意:容易造成循环引用,经常是在 block 里面使用了 self.,然后形成强引用,我们打断循 环链即可,如果 MRC 下用__block,ARC 下用__weak(下文会有详细介绍)。

二、内存位置(ARC情况)

block块的存储位置(block块入口地址):可能存放在2个地方:代码区(NSConcreteGlobalBlock)、堆区(NSConcreteMallocBlock),程序分5个区,还有常量区、全局区和栈区,对于MRC情况下代码还可能存在栈区(NSConcreteStackBlock)。关于内存分区详细参考:http://www.jianshu.com/p/d85a5e56c505

  • 情况1:代码区

不访问处于栈区的变量(例如局部变量),且不访问处于堆区的变量(例如alloc创建的对象)。也就是说访问全局变量也可以。

/**
  没有访问任何变量 
*/
int main(int argc, char * argv[]) { void (^block)(void) = ^{
        NSLog(@"===");
    };
    block();
}
/**
  访问了全局(静态)变量 
*/
int  iVar = 10; int main(int argc, char * argv[]) { void (^block)(void) = ^{
        NSLog(@"===%d",iVar);
    };
    block();
}
  • 情况2:堆区

如果访问了处于栈区的变量(例如局部变量),或处于堆区的变量(例如alloc创建的对象)。都会存放在堆区。(实际是放在栈区,然后ARC情况下自动又拷贝到堆区)

/**
  访问局部变量 
*/
int main(int argc, char * argv[]) { int iVar = 10; void (^block)(void) = ^{
        NSLog(@"===%d",iVar);
    };
    block();
}

总结下:

  • 代码区:不访问处于栈区的变量(例如局部变量),且不访问处于堆区的变量(例如alloc创建的对象)。也就是说访问全局变量(静态变量)也可以,或者是什么变量都不访问
  • 堆区:如果访问了处于栈区的变量(例如局部变量),或处于堆区的变量(例如alloc创建的对象),即便也访问了全局变量

三、注意事项

1 block为空

代码存放在堆区时,就需要特别注意,因为堆区不像代码区不变化,堆区是不断变化的(不断创建销毁)。因此代码有可能会被销毁(当没有强指针指向时),如果这时再访问此段代码则会程序崩溃。因此,对于这种情况,我们在定义一个block属性时应指定为strong,或copy:

  • @property (nonatomic, strong) void (myBlock)(void); // 这样就有强指针指向它
  • @property (nonatomic, copy) void (myBlock)(void); // 并不会在堆区copy一份,原因见 四

而对于block代码存在代码区,使用strong,copy(不会复制一份到堆区)也可以。因此定义block时最好指定为strong(推荐)或copy。我们在使用时最后判断下block是否为空,例如:

- (void)blockTest { // 如果为空则返回
    if (!block) {
        NSLog(@"block is nil"); return;
    }
    block();

}

2 当不在使用指向block的指针时,将其置空

当有类对象的成员变量pBlock指向block时,一方面是调用方,调用pBlock调用完成后,应将pBlock置为nil;另一方面是被调用方即block函数内部使用到self时要__weak声明。其实__weak声明有很多注意事项,下面是一个经典例子(是正确的写法):

// 弱声明,防止block强引用self,造成循环引用
    __weak __typeof(self) weakSelf = self;
    self.observer = [[NSNotificationCenter defaultCenter] addObserverForName:@"blockTest" object:nil queue:nil usingBlock:^(NSNotification * _Nonnull note) { // 多线程情况下(假设发出通知的代码在另一线程下),strong强引用防止后面调用strongSelf时:前面的strongSelf正常,后面的strongSelf已在其它线程被释放,造成很奇怪的结果,虽然这种情况很少发生
        __strong __typeof(self) strongSelf = weakSelf; //if (strongSelf == nil) { // return; //} // 下面再对strongSelf进行访问 // 防止block为空
        if (!strongSelf.block) { return;
        }
        strongSelf.block(); // 如果不用应置空,养成好习惯
        strongSelf.block = nil;
        NSLog(@"%@",strongSelf);
    }];
  • 1)我们都知道在使用通知中心时,应在dealloc函数中释放通知,如果上面没有使用__weak声明,那么:通知中心持有self.observer,observer又强引用 usingBlock,usingBlock又强引用self,self就不会被释放,那么dealloc就不会被调用(即使在dealloc中写了[[NSNotificationCenter defaultCenter] removeObserver:self.observer]也不会调用,因为dealloc没有被调用),就造成内存泄露;

  • 2)另外,我们在第5行看到又使用了__strong声明,是否瞬间凌乱?下面给出解释:在多线程情况下,有可能在usingBlock调用时,执行if (!strongSelf.block)时strongSelf还没有释放,而执行到strongSelf.block()的时候strongSelf就被释放(现在没有强引用了,又开始担心self被释放,真是操碎了心。。。),造成调用失败(最大的问题是不统一,造成不可预知的错误。用__strong操作后保证要么都访问成功,要么都访问失败或者判断为空后直接return退出)。

而使用了__strong声明后:

  • 如果执行usingBlock时self已经被释放则后面的strongSelf均为nil,因为对weakSelf引用计数为0再retain一次也不会有变化;

  • 如果执行usingBlock时self没有释放,则strongSelf会使self引用计数+1,那么self在其它线程被release -1也不会有影响,只有到usingBlock全部执行完毕后,strongSelf释放,然后self引用计数-1,self才会释放(weak–strong dance)。

上面的例子是通知中心可能造成的内存泄露,而使用block还经常出现循环引用,如下:

3 最常出现的循环引用

@interface BlockViewController ()
@property (nonatomic, strong) void (^block)(void);
@property (nonatomic, copy) NSString *str; @end

@implementation BlockViewController - (void)viewDidLoad {
    [super viewDidLoad];
    self.block = ^{
        self.str = @"123";
    };
} 
@end

上面的代码,self.block强引用block,而block中又使用了self.str,所以block强引用self,造成强引用,解决方法使用2中所说即可。

关于引用计数(http://www.jianshu.com/p/28b074919df3)

四、关于捕获变量

block里面捕获的变量,都是副本。看下面一段代码

int val = 10; void (^block)(void) = ^{
    NSLog(@"val = %d",val); // val = 1; //不允许
};
val = 5;
block();

它的打印结果是10,而不是5。

上面代码中val = 1是不允许的,如果想实现写操作,可以使用__block来修饰val,之后val会被拷贝(移动,便于理解)到堆上,之后无论是在block里面还是在val之前所处的作用域,访问的都是出于堆区的val。

为什么非要__block呢,因为如果不用__block,如果出了val所在的“}”,那么val就会被释放,而block的调用时机是不定的,可能调用时机已经超出了block和val本身所处的"{}",再访问val就可能坏地址访问(val已经被释放)。所以这样做是合理的。

但是在block里面,类似self.name = xxx,self->_val,却是很常见的,self也没有用__block修饰呀!你是否有过这样的迷惑?

self.name = xxx——>[self setName:xxx];是发送消息,函数调用,很好理解。那self->_val呢?因为_val本身是处于堆区的。

Block如果没有引用外部变量
保存在全局区(MRC/ARC一样)
Block如果引用外部变量
ARC保存在 堆区; MRC保存在 栈区必须用copy修饰block;

1 简单理解:block对应实例化一个结构体,里面成员有block里用到的变量,准备了数据;调用block时,执行对应函数,使用这些数据;
2 简单理解:拷贝进来时,没有__block修饰的直接字节拷贝进来,有__block修饰的,为了引地址进来,又定义一个结构体包了一层;
3 block拷贝时,栈到堆上真拷贝,堆到堆上只是引用计数;
4 block拷贝时,block使用的变量同样拷贝,拷贝的原则和上面说的有无__block修饰时的两种情况分别一致;
5 block里使用外部OC对象时,本身就相当于一个赋值拷贝,ARC下就会给对象加引用次数,所以才有了循环引用的事;
6 ARC下,等号赋值,retain、strong、copy都会触发block拷贝到堆上;非ARC有些不一样;
7 ARC下,assign不会把栈上block拷贝到堆上,retain、strong、copy都会;非ARC有些不一样;
8 __block修饰的变量被拷贝到堆上后,__forwarding指向的包装结构体都是堆上那个,这样无论操作栈上还是堆上的包装结构体,实际改变值都会是堆上那个里的;
9 一些有block参数的系统API都有说明,当把栈上block作为参数给这些API时会不会拷贝block,一般都会,所以才没问题;

链接:
http://www.jianshu.com/p/e03292674e60
https://www.jianshu.com/p/93f96c6aa530
http://www.cnblogs.com/mddblog/p/4754190.html
https://blog.csdn.net/demondev/article/details/53199785

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,242评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,769评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,484评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,133评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,007评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,080评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,496评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,190评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,464评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,549评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,330评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,205评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,567评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,889评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,160评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,475评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,650评论 2 335

推荐阅读更多精彩内容

  • 转自李峰峰博客 一、概述 闭包 = 一个函数「或指向函数的指针」+ 该函数执行的外部的上下文变量「也就是自由变量」...
    Joshua520阅读 951评论 0 0
  • 前言 Blocks是C语言的扩充功能,而Apple 在OS X Snow Leopard 和 iOS 4中引入了这...
    小人不才阅读 3,750评论 0 23
  • 《Objective-C高级编程》这本书就讲了三个东西:自动引用计数、block、GCD,偏向于从原理上对这些内容...
    WeiHing阅读 9,780评论 10 69
  • 1、概述 闭包 = 一个函数「或指向函数的指针」+ 该函数执行的外部的上下文变量「也就是自由变量」;Block 是...
    DeerRun阅读 651评论 0 0
  • block的定义,调用等就不介绍了,自行去查资料。 本文介绍内容: 1.block的底层数据结构2.block的类...
    伦伦子_f7b3阅读 1,087评论 0 0