考虑以下代码:
@interface ClassA : NSObject
@property (nonatomic, copy) void(^blockCopy)();
@end
@implementation ClassA
@synthesize blockCopy;
- (void)giveBlock:(void(^)())inBlock {
blockCopy = inBlock;
}
@end
然后在一个类中使用它,该类具有 ClassA
类型的 strong
属性,称为 someA
:
self.someA = [[ClassA alloc] init];
[self.someA giveBlock:^{
NSLog(@"self = %@", self);
}];
dispatch_async(dispatch_get_main_queue(), ^{
self.someA.blockCopy();
self.someA = nil;
});
如果我在启用 ARC 的情况下运行构建的 O3
,在 iOS 上,它会在 self.someA.blockCopy();
调用期间崩溃 objc_retain
。为什么?
现在我意识到人们可能会说我应该用 self.blockCopy = inBlock
来设置它,但我确实认为 ARC 应该在这里做正确的事情。如果我查看从 giveBlock:
方法生成的程序集 (ARMv7),它看起来像这样:
.align 2
.code 16
.thumb_func "-[ClassA giveBlock:]"
"-[ClassA giveBlock:]":
push {r7, lr}
movw r1, :lower16:(_OBJC_IVAR_$_ClassA.blockCopy-(LPC0_0+4))
mov r7, sp
movt r1, :upper16:(_OBJC_IVAR_$_ClassA.blockCopy-(LPC0_0+4))
LPC0_0:
add r1, pc
ldr r1, [r1]
add r0, r1
mov r1, r2
blx _objc_storeStrong
pop {r7, pc}
这就是调用 objc_storeStrong
,它依次在 block 上执行 retain
并在旧 block 上执行 release
。我的猜测是 ARC 没有正确地注意到它是一个 block 属性,因为我认为它应该调用 objc_retainBlock
而不是正常的 objc_retain
。
或者,我是不是完全错了,实际上 ARC 正在做它记录的事情,而我只是以错误的方式阅读它?
非常欢迎对此进行讨论 - 我发现这很有趣。
注意事项:
- 它不会在 OS X 上崩溃。
- 它不会使构建的
O0
崩溃。
最佳答案
- (void)giveBlock:(void(^)())inBlock {
blockCopy = inBlock;
}
您需要在分配时或传递给此函数时复制 block 。虽然 ARC 解决了返回时自动移动到堆的问题,但它不会为参数这样做(不能对 C 的特性这样做)。
它在某些环境中不会崩溃纯属巧合;只要 block 的堆栈版本没有被覆盖,它就不会崩溃。一个明确的迹象是当您遇到崩溃并在关闭优化时消失。关闭优化后,编译器将不会在任何给定范围内重用堆栈内存,从而导致内存在本应有效的情况下长时间“有效”。
I still don't quite understand why it can't do a objc_blockRetain rather than a normal objc_retain, though. The compiler knows the type after all.
我很确定问题出在任务的潜在成本上。如果 block 捕获大量状态,包括可能的其他 block ,那么 Block_copy() 可能真的真的 真的昂贵。
即如果你有类似的东西:
BlockType b = ^(...) { ... capture lots of gunk ... };
SomeRandomFunc(b);
... 这意味着 Block_copy() 仅仅是因为赋值,这将使得不可能在不存在病态性能问题风险的情况下始终如一地使用 block 。因为编译器没有办法知道 SomeRandomFunc()
是同步的还是异步的,所以没有办法自动管理它(此时——我肯定会摆脱这个潜在的绊线是可取的)。
关于objective-c - iOS:Block 属性直接设置访问时崩溃,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8824996/