我想对此进行更多解释,并提供更完整的答案。首先让我们考虑这段代码:
#import <Foundation/Foundation.h>
int main(int argc, char *argv[]) {
void (^block)() = nil;
block();
}
如果你运行它,你会看到一个block()
看起来像这样的崩溃(在 32 位架构上运行时——这很重要):
EXC_BAD_ACCESS(代码=2,地址=0xc)
那么,这是为什么呢?嗯,这0xc
是最重要的一点。崩溃意味着处理器试图读取内存地址处的信息0xc
。这几乎肯定是一件完全不正确的事情。那里不太可能有任何东西。但是它为什么要尝试读取这个内存位置呢?嗯,这是由于在引擎盖下实际构建块的方式。
定义块时,编译器实际上会在堆栈上创建一个结构,其形式如下:
struct Block_layout {
void *isa;
int flags;
int reserved;
void (*invoke)(void *, ...);
struct Block_descriptor *descriptor;
/* Imported variables. */
};
然后该块是指向该结构的指针。该结构的第四个成员invoke
是有趣的成员。它是一个函数指针,指向保存块实现的代码。因此,当调用块时,处理器会尝试跳转到该代码。请注意,如果您计算结构中invoke
成员之前的字节数,您会发现十进制有 12 个,或者十六进制有 C。
因此,当调用一个块时,处理器获取该块的地址,加上 12 并尝试加载该内存地址中保存的值。然后它会尝试跳转到该地址。但是如果块是 nil ,那么它会尝试读取地址0xc
。很明显,这是一个 duff 地址,因此我们得到了分段错误。
现在它必须是这样的崩溃而不是像 Objective-C 消息调用那样静默失败的原因实际上是一种设计选择。由于编译器正在做决定如何调用块的工作,它必须在调用块的任何地方注入 nil 检查代码。这会增加代码大小并导致性能下降。另一种选择是使用进行零检查的蹦床。但是,这也会导致性能损失。Objective-C 消息已经通过了蹦床,因为它们需要查找实际调用的方法。运行时允许延迟注入方法和更改方法实现,因此无论如何它已经通过了蹦床。在这种情况下,进行 nil 检查的额外惩罚并不重要。
我希望这有助于解释基本原理。
有关详细信息,请参阅我的博客 文章。