Question

请考虑以下代码：

@interface ClassA : NSObject
@property (nonatomic, copy) void(^blockCopy)();
@end

@implementation ClassA

@synthesize blockCopy;

- (void)giveBlock:(void(^)())inBlock {
    blockCopy = inBlock;
}

@end

然后在名为strong的{{1}}类型ClassA属性的类中使用它：

someA

如果我在启用ARC的情况下运行已构建的self.someA = [[ClassA alloc] init]; [self.someA giveBlock:^{ NSLog(@"self = %@", self); }]; dispatch_async(dispatch_get_main_queue(), ^{ self.someA.blockCopy(); self.someA = nil; });，则在iOS O3内的self.someA.blockCopy();调用期间，它会崩溃。为什么呢？

现在我意识到人们可能会说我应该用objc_retain设置它但我确实认为ARC应该在这里做正确的事情。如果我查看从self.blockCopy = inBlock方法生成的程序集（ARMv7），它看起来像这样：

giveBlock:

这就是调用.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会在块上执行retain，在旧块上执行release。我的猜测是ARC没有正确地注意到它是一个块属性，因为我认为它应该调用objc_retainBlock而不是普通的objc_retain。

或者，我完全错了，实际上ARC正在做它所记录的内容而我只是以错误的方式阅读它？

讨论非常欢迎 - 我觉得这很有趣。

注意事项：

它不会在OS X上崩溃。
它不会导致O0崩溃。

Answer 1

- (void)giveBlock:(void(^)())inBlock {
    blockCopy = inBlock;
}

您需要在分配时或传递给此函数时复制块。虽然ARC解决了自动移动到堆返回问题，但它不会对参数这样做（对C的特性无法做到）。

它在某些环境中不崩溃只是巧合;只要块的堆栈版本没有被覆盖，它就不会崩溃。这是一个明确的迹象，当你发生崩溃时，关闭优化就会消失。在优化关闭的情况下，编译器不会在任何给定范围内重用堆栈内存，导致内存在应该存在后很长时间内“有效”。

我仍然不太明白为什么它不能做一个objc_blockRetain 但是，而不是正常的objc_retain。编译器知道类型毕竟。

我很确定问题是作业的潜在成本。如果块捕获了很多状态，包括可能的其他块，那么Block_copy（）可能真的真的真的昂贵。

即。如果你有类似的东西：

BlockType b = ^(...) { ... capture lots of gunk ... };
SomeRandomFunc(b);

...并且仅仅因为赋值而暗示了Block_copy（），它将使得无法一致地使用块而不存在病理性能问题的风险。因为编译器无法知道SomeRandomFunc()是同步还是异步，所以没有办法自动管理（此时 - 我确定可以摆脱这种潜在的tripwire）。 / p>

iOS：Block属性在访问时直接设置崩溃

1 个答案: