我开始大量使用块，并很快注意到 nil 块会导致总线错误：
typedef void (^SimpleBlock)(void);
SimpleBlock aBlock = nil;
aBlock(); // bus error
这似乎违背了 Objective-C 忽略 nil 对象的消息的通常行为：
NSArray *foo = nil;
NSLog(@"%i", [foo count]); // runs fine
因此，在使用块之前，我必须使用通常的 nil 检查：
if (aBlock != nil)
aBlock();
或者使用虚拟块：
aBlock = ^{};
aBlock(); // runs fine
还有其他选择吗？为什么 nil 块不能简单地是一个 nop 有什么原因吗？
【问题讨论】：
标签： objective-c objective-c-blocks
警告：我不是 Blocks 方面的专家。
块是 objective-c objects 但调用 block is not a message，尽管您仍然可以尝试 [block retain] 发送 nil 块或其他消息。
希望这（和链接）有所帮助。
【讨论】：
__block 类型...但我不确定。 #define nilBlock ^{} 也可以让您的生活更轻松。
nilBlock 方法，不幸的是，打字会妨碍 - 为每个块类型创建单独的 nil 值并不是很有趣。
[block call] 进行内部检查可能会有所帮助。不确定块与 ObjC 对象的距离有多近。
这是我最简单最好的解决方案……也许可以用这些 c var-args 编写一个通用的运行函数，但我不知道该怎么写。
void run(void (^block)()) {
if (block)block();
}
void runWith(void (^block)(id), id value) {
if (block)block(value);
}
【讨论】：
马特·加洛韦的回答是完美的！很好读！
我只想补充一点，有一些方法可以让生活更轻松。你可以像这样定义一个宏：
#define BLOCK_SAFE_RUN(block, ...) block ? block(__VA_ARGS__) : nil
它可以接受 0 - n 个参数。使用示例
typedef void (^SimpleBlock)(void);
SimpleBlock simpleNilBlock = nil;
SimpleBlock simpleLogBlock = ^{ NSLog(@"working"); };
BLOCK_SAFE_RUN(simpleNilBlock);
BLOCK_SAFE_RUN(simpleLogBlock);
typedef void (^BlockWithArguments)(BOOL arg1, NSString *arg2);
BlockWithArguments argumentsNilBlock = nil;
BlockWithArguments argumentsLogBlock = ^(BOOL arg1, NSString *arg2) { NSLog(@"%@", arg2); };
BLOCK_SAFE_RUN(argumentsNilBlock, YES, @"ok");
BLOCK_SAFE_RUN(argumentsLogBlock, YES, @"ok");
如果您想获得 块的返回值，并且您不确定该块是否存在，那么您最好只输入： p>
block ? block() : nil;
通过这种方式，您可以轻松定义后备值。在我的示例中为“零”。
【讨论】：
我想多解释一下，给出更完整的答案。首先让我们考虑这段代码：
#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 并尝试加载该内存地址中保存的值。然后它会尝试跳转到该地址。但如果该块为零，那么它将尝试读取地址0xc。很明显，这是一个 duff 地址，因此我们得到了分段错误。
现在它必须是这样的崩溃而不是像 Objective-C 消息调用那样静默失败的原因实际上是一种设计选择。由于编译器正在做决定如何调用块的工作，它必须在调用块的任何地方注入 nil 检查代码。这会增加代码大小并导致性能下降。另一种选择是使用进行零检查的蹦床。但是，这也会导致性能损失。 Objective-C 消息已经通过了蹦床，因为它们需要查找实际调用的方法。运行时允许延迟注入方法和更改方法实现，因此无论如何它已经通过了蹦床。在这种情况下，执行 nil 检查的额外惩罚并不重要。
我希望这有助于解释基本原理。
【讨论】：