в компиляторе LLVM 3.0 в Xcode 4.2 вы можете подавить предупреждение следующим образом:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
    [self.ticketTarget performSelector: self.ticketAction withObject: self];
#pragma clang diagnostic pop

если вы получаете ошибку в нескольких местах и хотите использовать макросистему C для скрытия прагм, вы можете определить макрос, чтобы облегчить подавление предупреждения:

#define SuppressPerformSelectorLeakWarning(Stuff) \
    do { \
        _Pragma("clang diagnostic push") \
        _Pragma("clang diagnostic ignored \"-Warc-performSelector-leaks\"") \
        Stuff; \
        _Pragma("clang diagnostic pop") \
    } while (0)

вы можете использовать макрос такой:

SuppressPerformSelectorLeakWarning(
    [_target performSelector:_action withObject:self]
);

Если вам нужен результат выполненного сообщения, Вы можете сделать это:

id result;
SuppressPerformSelectorLeakWarning(
    result = [_target performSelector:_action withObject:self]
);

мое предположение об этом таково: поскольку селектор неизвестен компилятору, ARC не может обеспечить надлежащее управление памятью.

на самом деле, бывают случаи, когда управление памятью привязано к имени метода определенным соглашением. В частности, я думаю о удобство конструкторов и сделать методы; возвращения к Конвенции объект autoreleased; последний сохраненный объект. Конвенция основана на названиях selector, поэтому, если компилятор не знает селектор, то он не может применить правильное правило управления памятью.

Если это правильно, я думаю, что вы можете безопасно использовать свой код, если вы убедитесь, что все в порядке с управлением памятью (например, что ваши методы не возвращают объекты, которые они выделяют).

в проекте Параметры Построения, под Другие Предупреждающие Флаги (WARNING_CFLAGS), добавить
-Wno-arc-performSelector-leaks

теперь просто убедитесь, что вызываемый селектор не вызывает сохранение или копирование объекта.

в качестве обходного пути, пока компилятор не позволит переопределить предупреждение, вы можете использовать runtime

objc_msgSend(_controller, NSSelectorFromString(@"someMethod"));

вместо

[_controller performSelector:NSSelectorFromString(@"someMethod")];

вы должны

#import <objc/message.h>

чтобы игнорировать ошибку только в файле с селектором perform, добавьте # pragma следующим образом:

#pragma clang diagnostic ignored "-Warc-performSelector-leaks"

это проигнорирует предупреждение в этой строке, но все равно позволит ему на протяжении всей остальной части вашего проекта.

странно, но верно: если приемлемо (т. е. результат пуст, и вы не против позволить циклу runloop один раз), добавьте задержку, даже если это ноль:

[_controller performSelector:NSSelectorFromString(@"someMethod")
    withObject:nil
    afterDelay:0];

Это удаляет предупреждение, предположительно потому, что это гарантирует компилятору, что объект не может быть возвращен, и как-то неумело.

вот обновленный макрос, основанный на ответе, приведенном выше. Это должно позволить вам обернуть свой код даже с помощью оператора return.

#define SUPPRESS_PERFORM_SELECTOR_LEAK_WARNING(code)                        \
    _Pragma("clang diagnostic push")                                        \
    _Pragma("clang diagnostic ignored \"-Warc-performSelector-leaks\"")     \
    code;                                                                   \
    _Pragma("clang diagnostic pop")                                         \


SUPPRESS_PERFORM_SELECTOR_LEAK_WARNING(
    return [_target performSelector:_action withObject:self]
);

этот код не включает флаги компилятора или прямые вызовы среды выполнения:

SEL selector = @selector(zeroArgumentMethod);
NSMethodSignature *methodSig = [[self class] instanceMethodSignatureForSelector:selector];
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
[invocation setSelector:selector];
[invocation setTarget:self];
[invocation invoke];

NSInvocation позволяет устанавливать несколько аргументов в отличие от performSelector это будет работать на любой метод.

Ну, здесь много ответов, но так как это немного отличается, объединяя несколько ответов, я думал, что вставлю его. Я использую категорию NSObject, которая проверяет, что селектор возвращает void, а также подавляет предупреждение компилятора.

#import <Foundation/Foundation.h>
#import <objc/runtime.h>
#import "Debug.h" // not given; just an assert

@interface NSObject (Extras)

// Enforce the rule that the selector used must return void.
- (void) performVoidReturnSelector:(SEL)aSelector withObject:(id)object;
- (void) performVoidReturnSelector:(SEL)aSelector;

@end

@implementation NSObject (Extras)

// Apparently the reason the regular performSelect gives a compile time warning is that the system doesn't know the return type. I'm going to (a) make sure that the return type is void, and (b) disable this warning
// See http://stackoverflow.com/questions/7017281/performselector-may-cause-a-leak-because-its-selector-is-unknown

- (void) checkSelector:(SEL)aSelector {
    // See http://stackoverflow.com/questions/14602854/objective-c-is-there-a-way-to-check-a-selector-return-value
    Method m = class_getInstanceMethod([self class], aSelector);
    char type[128];
    method_getReturnType(m, type, sizeof(type));

    NSString *message = [[NSString alloc] initWithFormat:@"NSObject+Extras.performVoidReturnSelector: %@.%@ selector (type: %s)", [self class], NSStringFromSelector(aSelector), type];
    NSLog(@"%@", message);

    if (type[0] != 'v') {
        message = [[NSString alloc] initWithFormat:@"%@ was not void", message];
        [Debug assertTrue:FALSE withMessage:message];
    }
}

- (void) performVoidReturnSelector:(SEL)aSelector withObject:(id)object {
    [self checkSelector:aSelector];

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
    // Since the selector (aSelector) is returning void, it doesn't make sense to try to obtain the return result of performSelector. In fact, if we do, it crashes the app.
    [self performSelector: aSelector withObject: object];
#pragma clang diagnostic pop    
}

- (void) performVoidReturnSelector:(SEL)aSelector {
    [self checkSelector:aSelector];

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
    [self performSelector: aSelector];
#pragma clang diagnostic pop
}

@end

для потомков, я решил бросить свою шляпу на ринг :)

в последнее время я вижу все больше и больше реструктуризации от target/selector парадигма, в пользу таких вещей, как протоколы, блоки и т. д. Тем не менее, есть одна замена для performSelector что я использовал несколько раз:

[NSApp sendAction: NSSelectorFromString(@"someMethod") to: _controller from: nil];

это, кажется, быть чистой, дуги безопасности, и почти идентичной замены performSelector не много о с objc_msgSend().

хотя я понятия не имею, есть ли аналог на iOS.

ответ Мэтта Гэллоуэя на этой теме объясняю почему:

рассмотрим следующее:

id anotherObject1 = [someObject performSelector:@selector(copy)];
id anotherObject2 = [someObject performSelector:@selector(giveMeAnotherNonRetainedObject)];

теперь, как ARC может знать, что первый возвращает объект с числом сохранения 1, но второй возвращает объект, который является autoreleased?

Кажется, что обычно безопасно подавлять предупреждение, если вы игнорируете возвращаемое значение. Я не уверен, что лучшая практика, если вам действительно нужно получить сохраненный объект из performSelector -- кроме "не делайте этого".

@c-road обеспечивает правильную связь с описанием проблемы здесь. Ниже вы можете увидеть мой пример, когда performSelector вызывает утечку памяти.

@interface Dummy : NSObject <NSCopying>
@end

@implementation Dummy

- (id)copyWithZone:(NSZone *)zone {
  return [[Dummy alloc] init];
}

- (id)clone {
  return [[Dummy alloc] init];
}

@end

void CopyDummy(Dummy *dummy) {
  __unused Dummy *dummyClone = [dummy copy];
}

void CloneDummy(Dummy *dummy) {
  __unused Dummy *dummyClone = [dummy clone];
}

void CopyDummyWithLeak(Dummy *dummy, SEL copySelector) {
  __unused Dummy *dummyClone = [dummy performSelector:copySelector];
}

void CloneDummyWithoutLeak(Dummy *dummy, SEL cloneSelector) {
  __unused Dummy *dummyClone = [dummy performSelector:cloneSelector];
}

int main(int argc, const char * argv[]) {
  @autoreleasepool {
    Dummy *dummy = [[Dummy alloc] init];
    for (;;) { @autoreleasepool {
      //CopyDummy(dummy);
      //CloneDummy(dummy);
      //CloneDummyWithoutLeak(dummy, @selector(clone));
      CopyDummyWithLeak(dummy, @selector(copy));
      [NSThread sleepForTimeInterval:1];
    }} 
  }
  return 0;
}

единственный метод, который вызывает утечку памяти в моем примере, - CopyDummyWithLeak. Причина в том, что ARC не знает, что copySelector возвращает сохраненный объект.

Если вы запустите инструмент утечки памяти, вы увидите следующее изображение: ...и нет никаких утечек памяти в любой другой случай:

чтобы сделать макрос Скотта Томпсона более общим:

// String expander
#define MY_STRX(X) #X
#define MY_STR(X) MY_STRX(X)

#define MYSilenceWarning(FLAG, MACRO) \
_Pragma("clang diagnostic push") \
_Pragma(MY_STR(clang diagnostic ignored MY_STR(FLAG))) \
MACRO \
_Pragma("clang diagnostic pop")

тогда используйте его так:

MYSilenceWarning(-Warc-performSelector-leaks,
[_target performSelector:_action withObject:self];
                )

поскольку вы используете ARC, вы должны использовать iOS 4.0 или более позднюю версию. Это означает, что вы можете использовать блоки. Если вместо запоминания селектора для выполнения вы вместо этого взяли блок, ARC сможет лучше отслеживать, что на самом деле происходит, и вам не придется рисковать случайным введением утечки памяти.

не подавлять предупреждения!

не менее 12 альтернативные решения для возни с компилятором.
В то время как вы умны во время первой реализации, немногие инженеры на Земле могут следовать по вашим стопам, и этот код в конечном итоге сломается.

Безопасные Маршруты:

все эти решения будут работать, с некоторой степенью отклонения от вашего первоначального намерения. Предположим, что param может быть nil если вы так желаете:

Безопасный маршрут, такое же концептуальное поведение:

// GREAT
[_controller performSelectorOnMainThread:selector withObject:anArgument waitUntilDone:YES];
[_controller performSelectorOnMainThread:selector withObject:anArgument waitUntilDone:YES modes:@[(__bridge NSString *)kCFRunLoopDefaultMode]];

[_controller performSelector:selector onThread:[NSThread mainThread] withObject:anArgument waitUntilDone:YES];
[_controller performSelector:selector onThread:[NSThread mainThread] withObject:anArgument waitUntilDone:YES modes:@[(__bridge NSString *)kCFRunLoopDefaultMode]];

Безопасный маршрут, немного другое поведение:

(см. этой ответ)
Используйте любой поток вместо [NSThread mainThread].

// GOOD
[_controller performSelector:selector withObject:anArgument afterDelay:0];
[_controller performSelector:selector withObject:anArgument afterDelay:0 inModes:@[(__bridge NSString *)kCFRunLoopDefaultMode]];

[_controller performSelectorOnMainThread:selector withObject:anArgument waitUntilDone:NO];
[_controller performSelectorOnMainThread:selector withObject:anArgument waitUntilDone:NO];
[_controller performSelectorOnMainThread:selector withObject:anArgument waitUntilDone:NO modes:@[(__bridge NSString *)kCFRunLoopDefaultMode]];

[_controller performSelectorInBackground:selector withObject:anArgument];

[_controller performSelector:selector onThread:[NSThread mainThread] withObject:anArgument waitUntilDone:NO];
[_controller performSelector:selector onThread:[NSThread mainThread] withObject:anArgument waitUntilDone:NO modes:@[(__bridge NSString *)kCFRunLoopDefaultMode]];

Опасные Маршруты

требует какого-то молчания компилятора, которое обязательно сломается. Отметим, что в настоящее время, это сделал перерыв Свифт.

// AT YOUR OWN RISK
[_controller performSelector:selector];
[_controller performSelector:selector withObject:anArgument];
[_controller performSelector:selector withObject:anArgument withObject:nil];

вместо использования блочного подхода, который дал мне некоторые проблемы:

    IMP imp = [_controller methodForSelector:selector];
    void (*func)(id, SEL) = (void *)imp;

Я буду использовать NSInvocation, например:

    -(void) sendSelectorToDelegate:(SEL) selector withSender:(UIButton *)button 

    if ([delegate respondsToSelector:selector])
    {
    NSMethodSignature * methodSignature = [[delegate class]
                                    instanceMethodSignatureForSelector:selector];
    NSInvocation * delegateInvocation = [NSInvocation
                                   invocationWithMethodSignature:methodSignature];


    [delegateInvocation setSelector:selector];
    [delegateInvocation setTarget:delegate];

    // remember the first two parameter are cmd and self
    [delegateInvocation setArgument:&button atIndex:2];
    [delegateInvocation invoke];
    }

Если вам не нужно передавать какие-либо аргументы, простым обходным путем является использование valueForKeyPath. Это даже возможно на

вы также можете использовать протокол здесь. Итак, создайте такой протокол:

@protocol MyProtocol
-(void)doSomethingWithObject:(id)object;
@end

в вашем классе, который должен вызвать ваш селектор, у вас есть свойство@.

@interface MyObject
    @property (strong) id<MyProtocol> source;
@end

когда вам нужно позвонить @selector(doSomethingWithObject:) в экземпляре MyObject сделайте следующее:

[self.source doSomethingWithObject:object];