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

Question

考虑以下代码：

@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 上，它会在 objc_retain 内部的 self.someA.blockCopy(); 调用期间崩溃。为什么？

现在我意识到人们可能会说我应该使用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，它反过来在块上执行retain，在旧块上执行release。我的猜测是 ARC 没有正确注意到它是一个块属性，因为我认为它应该调用 objc_retainBlock 而不是正常的 objc_retain。

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

非常欢迎对此进行讨论 - 我觉得这很有趣。

注意事项：

• 它不会在 OS X 上崩溃。
• O0 构建时不会崩溃。

Answer 1

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

您需要在赋值时或在传递到此函数时复制块。虽然 ARC 解决了 auto-move-to-heap-on-return 问题，但它并没有解决参数问题（不能解决 C 的特性）。

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

---

我还是不太明白为什么它不能做 objc_blockRetain 但是，而不是普通的 objc_retain。编译器知道类型 毕竟。

我很确定问题在于分配的潜在成本。如果块捕获了很多状态，可能包括其他块，那么 Block_copy() 可能真的真的 真的昂贵。

即如果你有类似的东西：

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

... 这意味着 Block_copy() 仅仅因为分配，这将使得不可能在没有病理性能问题的风险的情况下一致地使用块。因为编译器无法知道SomeRandomFunc() 是同步的还是异步的，所以无法自动管理它（目前——我确信摆脱这个潜在的绊线是可取的）。