为什么block要用copy修饰?

简单的答案:首先在官方文档《Programming with Objective-C》里面写到,初学阅读的时候没有注意到这个细节:You should specify copy as the property attribute, because a block needs to be copied to keep track of its captured state outside of the original scope. This isn’t something you need to worry about when using Automatic Reference Counting, as it will happen automatically, but it’s best practice for the property attribute to show the resultant behavior .
在这里官方叫我们使用copy修饰符,虽然在ARC时代已经不需要再显式声明了,也就是使用strong是没有问题的,但是仍然建议我们使用copy以显示相关拷贝行为。问题到这里就基本结束了。目前使用strong和copy都是没有问题的。
深入探索: 但是在这里仍然无法解答我的疑惑,需要使用copy修饰符的根本原因是什么。所以继续探索。
最终得到的答案是这与block对象在创建时是stack对象有关。
所以,其实Objective-C是有它的Stack object的。是的,那就是block.
首先我们先对block进行进一步的认识。

在Objective-C语言中,一共有3种类型的block:

_NSConcreteGlobalBlock 全局的静态block,不会访问任何外部变量。

_NSConcreteStackBlock 保存在栈中的block,当函数返回时会被销毁。

_NSConcreteMallocBlock 保存在堆中的block,当引用计数为0时会被销毁。

这里我们主要基于内存管理的角度对它们进行分类。

NSConcreteGlobalBlock,这种不捕捉外界变量的block是不需要内存管理的,这种block不存在于Heap或是Stack而是作为代码片段存在,类似于C函数。

NSConcreteStackBlock。这就是这次探索的重点了,需要涉及到外界变量的block在创建的时候是在stack上面分配空间的,也就是一旦所在函数返回,则会被摧毁。这就导致内存管理的问题,如果我们希望保存这个block或者是返回它,如果没有做进一步的copy处理,则必然会出现问题。

NSConcreteMallocBlock,因此为了解决block作为Stack object的这个问题,我们最终需要把它拷贝到堆上面来。而此时NSConcreteMallocBlock扮演的就是这个角色。
真正的答案: 因此答案便是因为block在创建时是stack对象,如果我们需要在离开当前函数仍能够使用我们创建的block。我们就需要把它拷贝到堆上以便进行以引用计数为基础的内存管理。

ARC的疑团:
解答完最初的问题后,新的问题又出现在我的脑海。那就是ARC是如何进行block的内存管理的呢,对于普通的OC对象之前已经总结过

那么block在ARC下是如何从栈管理正确过渡到堆的管理的呢:

我在网上查阅了许多资料与博文,有部分总结是:

在ARC下NSConcreteStackBlock类型的block会替换成NSConcreteMallocBlock类型

其实这是不够准确的,来自苹果LLVM ARC的文档中谈到:
With the exception of retains done as part of initializing a __strong parameter variable or reading a __weak variable, whenever these semantics call for retaining a value of block-pointer type, it has the effect of a Block_copy. The optimizer may remove such copies when it sees that the result is used only as an argument to a call.
也就是说ARC帮助我们完成了copy的工作,在ARC下,即使你声明的修饰符是strong,实际上效果是与声明为copy一样的。

因此在ARC情况下,创建的block仍然是NSConcreteStackBlock类型,只不过当block被引用或返回时,ARC帮助我们完成了copy和内存管理的工作。

总结和心得:
其实用一句话总结便是:
在ARC下,我们可以将block看做一个正常的OC对象,与其他对象的内存管理没什么不同。

有时我们可能简单地从博客和文档上面得到一句简单的结论就够了。但是如果我们不断探索,不断思考,那么我们的收获会更大,更深。可能不仅仅是一句知识点,更多的是探索的方法和过程。对一件事情剥茧抽丝,还原本质的过程对我来说也是一种享受,一种修行。

经过了一系列探索,最终理解了block的概念,了解了block的实现,弄懂了block的内存管理。
加油,继续修行~

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

推荐阅读更多精彩内容