如果你的项目是从 Objective-C 时代一路走过来的，大概率在 Xcode 的 Issue Navigator 里没少跟这条警告打过照面：“PerformSelector may cause a leak because its selector is unknown”。我最早遇到它是在封装一个全局 Target-Action 路由时，当时第一反应就是找个编译选项把它关掉，后来被线上一个内存增长追了整整两周，才真正把这条警告背后的内存管理规则搞明白。这篇文章就把这条警告的来龙去脉、实际触发场景，以及几种绕开又不出事的方案一次说清楚。
这条警告不是 Xcode 在闹情绪，它是 clang 在 ARC 下的保守策略。PerformSelector 把消息发送从编译期“确定”变成了运行期“猜”，编译器没法知道你要调的方法签名，自然不知道返回值归谁管、要不要在调用后补一个 release。搞清楚这个逻辑，你才能在动态派发和内存安全之间找到平衡。
内容适合三类人：正在维护 Objective-C 老项目的开发者、做 iOS 底层库封装的人，以及刚接触运行时机制想弄明白消息发送原理的学习者。下面直接开讲。
1. 警告是怎么来的：ARC 的保守策略
1.1 编译器如何判断返回值归属
ARC 能自动管理内存，全靠编译期静态分析。它有一套“方法族”规则：只要方法名以alloc、new、copy、mutableCopy开头，编译器就认为返回值是 +1 所有权，调用方需要在用完后释放。比如[obj newToken]，编译器知道这个调用会产出一个需要平衡引用的对象，自动在合适的时机插入 release。
但到了 PerformSelector 这里就麻烦了。[target performSelector:@selector(newToken)]里的 selector 只是一个运行时字符串，编译器根本不知道它指向什么方法。它没法判断newToken到底是不是方法族，只能按“返回普通对象”来处理，后续的 release 也就无处安放。如果这个 selector 真实对应的方法恰好是newXxx或copyXxx，那每一次调用都会让内存上涨一个引用计数，这就是警告里说的 leak。
你可能会想：编译器为什么不在运行时检查一下？因为 clang 是静态分析器，它不能保证 selector 的解析结果。与其在不确定时帮你乱插入内存管理代码，不如在编译期提示你“这里可能有坑”。这就是为什么这条警告是-Warc-performSelector-leaks，属于 ARC 专属。
1.2 什么情况下“泄漏”是真的
不是所有 PerformSelector 都会泄漏。判断方法很简单：看目标方法返回值的所有权。如果方法返回值是void，或者返回的是并未标记为 +1 的普通对象，那么 ARC 的默认处理就是正确的，不会出问题。真正会泄漏的主要是三类：
- 方法名以
alloc、new、copy、mutableCopy开头，返回对象； - 方法被
__attribute__((objc_method_family("new")))等属性强制标记为 +1 所有权； - 方法返回值被赋给强引用变量并持续持有，但编译器又没有插入配对释放。
举个例子。假设一个钱包类里定义：
@interface Wallet : NSObject - (id)newToken; @end然后你用performSelector:去调用：
id token = [wallet performSelector:@selector(newToken)];编译器看到的是“一个普通对象返回，赋值给局部强引用”，它认为 ARC 会自动处理token的生命周期，不会额外调用 release。而真实语义是newToken返回 +1 对象，调用方必须负责平衡引用。两个规则错位，结果就是每次调用泄漏一次。这种问题在循环里尤其致命。
2. 别只会用 performSelector：全家桶逐一说清
2.1 常用的五个变体和参数限制
performSelector:家族并不只有你经常看到的那一个，常见的变体至少有七个：
performSelector:，无参调用；performSelector:withObject:，传一个对象参数；performSelector:withObject:withObject:，传两个对象参数；performSelector:withObject:afterDelay:，延迟调用；performSelector:withObject:afterDelay:inModes:，指定 runloop mode 延迟调用；performSelectorOnMainThread:withObject:waitUntilDone:，在主线程执行；performSelectorInBackground:withObject:，在后台线程执行；performSelector:onThread:withObject:waitUntilDone:，指定线程执行。
最大的限制是参数只能传对象，而且是“最多两个”。你要是想传NSInteger、CGRect、BOOL这些非对象类型，直接往withObject:里塞会编译报错，运行时更走不通。就算强行把NSInteger包装进NSNumber，也只是绕了一层，本质还是对象。真正要传结构体或原生类型，得用 NSInvocation，后面会专门讲。
2.2 延迟执行与 runloop 的关系
performSelector:withObject:afterDelay:和普通的performSelector:不是一个东西，它的底层是往当前线程的 runloop 里注册一个 timer。如果你当前线程根本没有启动 runloop，或者 runloop 处于一个不包含默认 mode 的追踪状态（比如正在滑动列表时用了UITrackingRunLoopMode），延迟调用就不会执行。
另一个很容易忽略的点：performSelector:onThread:withObject:waitUntilDone:这一族方法同样依赖目标线程的 runloop。如果目标线程没有活跃的 runloop，waitUntilDone:YES会让当前线程一直等下去，直接卡死。我见过不止一次因为后台线程没开 runloop 导致performSelector:onThread:静默失败的事故。
2.3 返回值“丢了”和“多出来”的问题
performSelector:系列不是没有返回值，只是返回值被当作id处理，类型信息丢失了。编译器于是无从判断是否需要对返回值做特殊管理。前面说的newToken案例就是典型的返回值“多出来”的归属问题。
还有一种是“丢了”的情况：如果一个方法返回了一个被标记为ns_returns_retained的强引用对象，你用了performSelector:且立刻丢弃返回值，编译器不会回收它，对象就悬在外面没人管。这种情况在自定义类里极少见，但在桥接 Core Foundation 对象时会出现。处理原则只有一个：凡是方法族返回 +1 对象的，都不要走 PerformSelector，除非你明确知道自己在做手动管理。
3. 怎么绕开警告：四种方案的完整对比
3.1 NSInvocation：把动态调用重构成显式签名
NSInvocation 是官方推荐的正规军。它让你把“要调用的方法签名”显式提供给编译器，有了NSMethodSignature，ARC 就能正确推断参数和返回值的内存管理方式。这是从根上解决未知 selector 问题的方案。
看一下标准写法：
SEL selector = NSSelectorFromString(@"doSomething:withAnother:"); if (![target respondsToSelector:selector]) { return; } NSMethodSignature *signature = [target methodSignatureForSelector:selector]; if (!signature) { return; } NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:signature]; invocation.target = target; invocation.selector = selector; id arg1 = @(1); id arg2 = @"hello"; [invocation setArgument:&arg1 atIndex:2]; [invocation setArgument:&arg2 atIndex:3]; [invocation invoke]; id returnValue = nil; [invocation getReturnValue:&returnValue];两个细节需要强调。第一，参数 index 从 2 开始，因为 0 号是self，1 号是_cmd。第二，setArgument:接收的是指针，所以这里传的是&arg1而不是arg1。返回值如果非对象类型，getReturnValue:同样也只做内存拷贝，需要你自己声明一个匹配类型去接，比如NSInteger result; [invocation getReturnValue:&result];。
NSInvocation 缺点是慢，比直接发消息慢一个量级，不适合做高性能热路径上的高频调用。但它是消息转发机制的标准载体，也是forwardInvocation:里必经的一环，通用性和安全性最高。
3.2 IMP 函数指针：高性能方案与 arm64 的坑
如果你确认目标方法的签名是固定的，可以用methodForSelector:取出 IMP，然后用函数指针调用。这样绕开了 clang 的警告，又保留了动态派发能力，性能几乎和直接objc_msgSend一样好。
typedef id (*ObjectIMP)(id, SEL, id); SEL selector = @selector(doSomething:); if ([target respondsToSelector:selector]) { ObjectIMP imp = (ObjectIMP)[target methodForSelector:selector]; id result = imp(target, selector, @(1)); }这段代码能直接通过编译，但有一个非常重要的前提：函数指针的签名必须和真实方法签名严格一致。返回值类型、参数类型、参数个数都不能错，否则在 arm64 架构上会因寄存器分配错乱而崩溃。这也是为什么我会把 IMP 方案的危险级别标得比 NSInvocation 高。
如果你要调的方法返回值是void，函数指针类型要对应写void (*)(id, SEL, id)，不能统一用id (*)(id, SEL, ...)。别抱有侥幸，变长参数在 arm64 上的调用约定和固定参数完全不同，写错就是崩溃。
3.3 直接调用 objc_msgSend：性能极限但要谨慎
Objective-C 的消息发送本来就会编译成objc_msgSend的调用，所以你也可以在代码里直接使用它：
((void(*)(id, SEL, id))objc_msgSend)(target, selector, arg);这种写法能把动态派发压到极致，很多开源库在底层就是这么干的。但你自己写的时候必须把函数指针的每个参数类型都写对，尤其是浮点数、结构体这类在寄存器传递规则上和整数不同的类型。objc_msgSend在不同 CPU 架构上对浮点参数的处理不一样，写错了会得到完全错误的结果而不是崩溃。
我的建议是：除非你在写消息转发的底层封装，否则不要直接碰objc_msgSend。它的性能优势和 IMP 方案没有本质差别，但出错概率高得多。生产环境里能用 IMP 就用 IMP，IM P 解决不了再升级到 NSInvocation。
3.4 消除警告的“正规姿势”：pragma 和 switch
在某些场景下你就是能确认对应方法是安全的，比如方法返回void、参数类型确定、路由表只接受内部白名单 selector。这时候你可以用 pragma 限定范围关闭警告：
#pragma clang diagnostic push #pragma clang diagnostic ignored "-Warc-performSelector-leaks" [target performSelector:selector withObject:arg]; #pragma clang diagnostic pop注意这里用的是 push / pop，不是简单的 ignored，这样警告只在 push 和 pop 之间被关闭，不会影响其他代码。这种做法的前提是你清楚风险，并且明确当前 selector 不涉及 +1 返回值。它治标不治本，但作为临时方案是安全的。
另一种更优雅的方式是用 switch 或字典把动态 selector 映射到一套编译器认识的静态消息上：
switch (actionType) { case ActionOpen: [target open]; break; case ActionClose: [target close]; break; }这是把“动态”回归“静态”的思路，牺牲一点扩展性，换来编译期类型安全。如果动态方法数量有限，这是我推荐的首选。
3.5 四种方案的横向对比
| 方案 | 类型安全 | 性能 | 复杂度 | 适用场景 |
|---|---|---|---|---|
| NSInvocation | 高 | 低 | 中 | 路由、消息转发、参数不定 |
| IMP 函数指针 | 中 | 高 | 中 | 签名固定、热路径 |
| objc_msgSend | 低 | 极高 | 高 | 底层封装 |
| pragma 忽略 | 无 | 高 | 低 | 明确安全的临时方案 |
个人建议的决策顺序是：能用静态映射就用静态映射，动态方法多就上 NSInvocation，真的要做性能优化再考虑 IMP。直接跳过警告会爽一时，等泄漏积攒到线上爆发时，你会比写 NSInvocation 多花十倍的时间排查。
4. 实战：动态路由、消息转发与延迟执行
4.1 路由表中动态调用的落地
很多 App 做模块间通信都会维护一个路由表，用字符串映射到 selector。这类场景下目标类是动态的、方法是动态的，用 NSInvocation 最稳。
比如我手里的简化版本接收一个路由 key，从注册表查 selector 并执行：
- (void)dispatchAction:(NSString *)action payload:(id)payload { NSString *selectorName = self.routeMap[action]; if (!selectorName.length) { return; } SEL selector = NSSelectorFromString(selectorName); id target = self.destination; if (![target respondsToSelector:selector]) { return; } NSMethodSignature *signature = [target methodSignatureForSelector:selector]; NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:signature]; invocation.target = target; invocation.selector = selector; NSMethodSignature *sig = invocation.methodSignature; NSUInteger argCount = sig.numberOfArguments; if (argCount > 2) { [invocation setArgument:&payload atIndex:2]; } [invocation invoke]; }这套逻辑把“字符串 action”和“对象方法”解耦开，路由表只管映射，业务方只需要遵循“方法最多一个参数”的约定，就能安全完成动态调用。
4.2 消息转发配合 NSInvocation 处理未知 selector
如果不希望“调用了不存在的方法”直接崩溃，可以在消息转发阶段拦截。forwardInvocation:里拿到的不再是裸的 selector，而是完整的 NSInvocation，可以直接改 target 或者改消息内容：
- (void)forwardInvocation:(NSInvocation *)invocation { if ([self.fallbackTarget respondsToSelector:invocation.selector]) { [invocation invokeWithTarget:self.fallbackTarget]; } else { [super forwardInvocation:invocation]; } } - (NSMethodSignature *)methodSignatureForSelector:(SEL)selector { NSMethodSignature *signature = [super methodSignatureForSelector:selector]; if (!signature) { signature = [self.fallbackTarget methodSignatureForSelector:selector]; } return signature; }这里有一段顺带帮你理解了 performSelector 的警告：你在代码里写performSelector:时，编译器连运行时的消息转发机制都考虑到了，风险更不可控，所以直接警告。
4.3 延迟执行和跨线程执行容易踩的坑
前面提到延迟执行依赖 runloop。现实中最大的坑是：你在子线程里写了performSelector:withObject:afterDelay:，但子线程没起 runloop，代码安静地不执行。排查时一眼看上去像 selector 没绑对，实际上只是 runloop 没跑。
如果必须在线程里延迟执行，要么手动启动一个带循环的 runloop，要么直接用 GCD 的dispatch_after替代：
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delay * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{ [target doSomething]; });跨线程执行时，waitUntilDone:YES如果配合一个未启动 runloop 的目标线程，会让当前线程永久等待。等你的崩溃日志里出现主线程阻塞监控报警，再回头看这里就晚了。我的建议是业务代码里的跨线程调用能换 GCD 就换 GCD，performSelector 的线程变体只留在框架内部。
5. 高频问题实录与排查技巧
5.1 方法返回 void 为什么还泄漏
有个朋友排查了好久没找到原因：他的 selector 对应方法确实是- (void)refreshUI，返回值是void，但 Instruments 里仍然能看到内存增长。后来发现，这个类里有一个方法被__attribute__((objc_method_family("new")))标记了，而他的路由表在某次重构后把方法名打错了，selector 解析到了一个带 +1 所有权的新方法上。这就是动态派发的经典风险：编译期无法静态校验，只能在运行时出错。
排查方法是打个断言检查当前方法的签名：
NSMethodSignature *sig = [target methodSignatureForSelector:selector]; const char *returnType = sig.methodReturnType; // 打印 returnType 检查是否 '@' 或 'v'，判断是否对象类型如果返回类型是@（对象），就要警惕方法族；如果是v（void），基本安全。
5.2 传非对象参数时崩溃
performSelector:withObject:只能接对象，传NSInteger或结构体会直接出问题。记得有一次我把CGRect当作NSValue包装传进去，虽然在调试时看着正常，到了真机上由于 NSValue 的解包时机差异，得到的是错位数据。场景上应该直接上 NSInvocation，用setArgument:atIndex:传原生态结构体，别做无谓的包装。
5.3 arm64 上 IMP 函数指针崩溃
arm64 架构下，函数调用参数寄存器规则与 armv7 差别很大。直接把 IMP 转成id (*)(id, SEL, id)没问题，但如果你在转成void (*)(id, SEL, ...)后用变长参数方式调用，寄存器分配就会出错。很多老代码一在 arm64 真机上跑就闪退，大概率就是这个原因。解决办法是让函数指针签名和消息签名完全对齐，参数类型逐个写下，不要用...。
5.4 用 Instruments 做 leak check 验证
如果你改完代码想知道到底还泄不泄漏，直接在 Xcode 里跑 Leaks 工具不一定能快速暴露每一条路径，毕竟测试场景未必覆盖到动态调用。我的做法是在可疑调用外面套一个大循环，比如执行一万次，然后观察内存增量：
for (NSInteger i = 0; i < 10000; i++) { [wallet performSelector:@selector(newToken)]; }如果内存从几 MB 涨到几十 MB，说明泄漏还在；如果一万一循环跑完内存持平，说明 ARC 处理正常。这个小技巧比任何静态分析都直观，也方便写进回归测试。配合leaks命令行工具在 CI 上跑，还能自动化检测动态调用路径的引用失衡。
最后
现在再看到这条警告，我的选择习惯是先判断方法的返回值类型和参数类型，能落到静态消息就落静态消息；必须用动态 selector 时，参数多于两个一概走 NSInvocation；参数固定且对性能有要求时，用严格匹配签名的 IMP 指针。pragma 关闭警告是最后的选择，而且每次都要加注释说明为什么安全。
当初追那个线上内存问题的两周，我学会的最重要的一件事：编译器报的每一条 warning，背后都有一个它在替你担忧的运行时场景。把警告当成线索去看，比把它当成障碍去掉要省力得多。
