声明Block用Strong还是Copy

较短的回答(Short Answer)

这是一个历史原因,在ARC中不使用Copy,而使用Strong是完全正确的。就像是使用实例变量的时候,是使用local还是global。

较长的回答(Long Answer)

和其他的object不一样,一个block是被存储在stack上的,这是一个优化的实现,这种实现是很必要的。像其他的编译优化一样,这对code没有一个直接的影响。这个优化在block被创建,作为一个方法的参数被传入再被释放的时候受益于一个一般的案例。block在stack上被创建,释放的时候也不需要heap(动态内存池)的调用。

把它和局部变量做对比,(a)一个是在stack上创建,(b)在方法return的时候自动被摧毁,(c)在被调用的时候,可以以地址的方式传入到方法中。在方法return的时候,局部变量的地址不能够被存储和使用——已经被释放了。

但是,如果需要,对象的预期持续时间可以比创建的方法长久。所以不像局部变量,它们被创建在heap上并且在方法创建的时候不会自动释放,而是取决于局部变量是否被需要,是否“需要”是由ARC决定的。

在stack上创建block能得到一些的好处,但是也会引起一个问题。如果block想要持续存在,就像object做的,所以在创建它的stack释放之前它必须要移动到heap上。

当实现的block被第一个释放,在stack上strong block的优化是可见的对于开发者,编译器在这个时候不能够自动处理移动block到heap上。当需要的时候,开发者必须自己调用block_copy方法。

但是这个方法只能在底层C的API中使用(block是一个C的结构体),在Object-C的层开发的开发者手动管理编译优化不是一个很好的实践。Apple发布的最新的编译器版本改善了这种使用,较早的开发者被告诉用[block copy]替代block_copy(block),这符合一般的Object-C的调用方式。当需要的时候,编译器开始自动的从stack拷贝出block。但是这没有被官方文档正式说明。

没有必要暂时的手动从stack拷贝block,因为Apple不能摆脱历史的包袱,只能认为这样做是best practice,但这也是相当有争议的。在2014年9月最新的版本中,苹果的Workding with Blocks陈述了block属性应该使用copy,这就立马变的清晰了。

Note:你应该用copy来修饰block属性。为了追踪原始作用域捕获的状态,block需要被拷贝。当使用Automatic Reference Counting你就不需要担心这些,因为这会自动发生,但是属性attribute命名的最佳实践应该是能够说明它的必然行为。

没有必要显示“它必然的行为” - 在stack上的第一个地方存储block是一个优化,并且对于code来说应该是透明可见的。就像其他编译器优化之后,不应该需要开发者做什么就能得到性能的提升。

个人理解的意思是:编译器优化了之后,不应该要求使用者将属性改为copy,使用者只要知道被strong过的block也会想普通对象一样被ARC管理就行了。

所以只要你使用ARC,现在的Clang编译器,你可以像对待其他对象一样对待block。因为block是可变的。这意味着你不需要拷贝他们。相信Apple,他们已经在编译器优化的时候帮我们做了这件事。他们鼓励你抛弃历史的包袱,copy 不再需要了。


有很多地方没有翻译通,但是为什么用strong代替copy已经很清楚了:

之前我们需要手动的用copy属性来修饰block,让block从stack拷贝到heap,保证block在出了作用域之后也能够让block继续存在,并且以ARC的方式来决定什么时候释放在heap上的block。在2014年9月后的一次编译器优化之后,如果用strong修饰block,编译器会自动将blcok从stack拷贝到heap上。
对于开发者来说,这就像处理普通对象一样用strong来block就行了。

原文:Cocoa blocks as strong pointers vs copy
欢迎指正👏👏👏👏

Object C中的对象存放在Heap上还是Stack上

Object-C只使用heap对象,不使用stack对象。

Stack

stack包含了局部变量的存储的原始内存,每个执行的thread都有一个stack。当一个方法被called,方法内的局部变量的数据存储在stack地址。当方法return的时候,stack的地址被释放。所有的这些都会自动发生。

Heap

内存中的一部分是heap。在heap的上的内存任何时候都能被分配和摧毁。
所以,最后stack上的object的的内存地址是在heap被分配的。

原文:where does Objective C store objects, heap or stack [duplicate]
欢迎指正👏👏👏👏

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

推荐阅读更多精彩内容