W kompilatorze LLVM 3.0 w Xcode 4.2 można wyłączyć ostrzeżenie w następujący sposób:

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

Jeśli otrzymujesz błąd w kilku miejscach i chcesz użyć systemu makr C do ukrycia pragmatów, możesz zdefiniować makro, aby łatwiej tłumić Ostrzeżenie:

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

Możesz użyć makra w następujący sposób:

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

Jeśli potrzebujesz wyniku wykonanej wiadomości, możesz to zrobić:

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

Moje przypuszczenie jest takie: ponieważ Selektor jest nieznany kompilatorowi, ARC nie może wymusić właściwego zarządzania pamięcią.

W rzeczywistości są chwile, kiedy zarządzanie pamięcią jest powiązane z nazwą metody przez określoną konwencję. W szczególności, myślę o convenience constructors versus make methods; pierwszy zwraca przez Konwencję obiekt z autoreleased, drugi obiekt zachowany. Konwencja opiera się na nazwach selektora, więc jeśli kompilator nie zna selektora, wtedy nie może wymusić odpowiedniej reguły zarządzania pamięcią.

Jeśli jest to poprawne, myślę, że możesz bezpiecznie używać kodu, pod warunkiem upewnienia się, że wszystko jest w porządku, jeśli chodzi o zarządzanie pamięcią (np. że Twoje metody nie zwracają obiektów, które przydzielają).

W Twoim projekcie Build Settings , pod inne flagi ostrzegawcze (WARNING_CFLAGS), dodaj
-Wno-arc-performSelector-leaks

Teraz tylko upewnij się, że selektor, który wywołujesz, nie powoduje, że obiekt zostanie zachowany lub skopiowany.

Jako obejście, dopóki kompilator nie zezwoli na nadpisanie ostrzeżenia, możesz użyć runtime

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

Zamiast

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

Będziesz musiał

#import <objc/message.h>

Aby zignorować błąd tylko w pliku z selektorem wykonaj, dodaj #pragma w następujący sposób:

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

To zignorowałoby ostrzeżenie na tej linii, ale nadal zezwalałoby na to przez resztę twojego projektu.

Dziwne, ale prawdziwe: jeśli akceptowalny (tzn. wynik jest nieważny i nie masz nic przeciwko, aby cykl runloopa był raz), dodaj opóźnienie, nawet jeśli jest to zero:

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

Usuwa to Ostrzeżenie, prawdopodobnie dlatego, że zapewnia kompilator, że żaden obiekt nie może zostać zwrócony i w jakiś sposób niewłaściwie zarządzany.

Oto zaktualizowane makro oparte na odpowiedzi podanej powyżej. Ten powinien pozwolić ci zawinąć Kod nawet z instrukcją zwrotu.

#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]
);

Ten kod nie zawiera flag kompilatora ani bezpośrednich wywołań runtime:

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

NSInvocation pozwala na ustawienie wielu argumentów, więc w przeciwieństwie do {[2] } będzie to działać na dowolnej metodzie.

Cóż, wiele odpowiedzi tutaj, ale ponieważ to jest trochę inne, łącząc kilka odpowiedzi, pomyślałem, że umieścić go w. Używam kategorii NSObject, która sprawdza, czy selektor zwraca void, a także wyłącza Ostrzeżenie kompilatora.

#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

Ze względu na potomność, postanowiłem rzucić mój kapelusz na ring:)

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

Wydają się być czystym, bezpiecznym dla łuku i prawie identycznym zamiennikiem performSelector bez konieczności dużo o objc_msgSend().

Choć nie mam pojęcia, czy istnieje analogowe dostępne na iOS.

ODPOWIEDŹ Matta Gallowaya na Ten wątek wyjaśnia dlaczego:

Rozważ następujące:

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

Skąd ARC może wiedzieć, że pierwszy zwraca obiekt z liczbą zatrzymań równą 1, a drugi zwraca obiekt, który jest autorelowany?

Wydaje się, że ogólnie bezpiecznie jest tłumić ostrzeżenie, jeśli ignorujesz zwracaną wartość. Nie jestem pewien, jaka jest najlepsza praktyka, jeśli naprawdę chcesz uzyskać zachowany obiekt z performSelector -- poza "nie rób tego".

@C-road podaje właściwy link z opisem problemu tutaj . Poniżej możesz zobaczyć mój przykład, kiedy performSelector powoduje wyciek pamięci.

@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;
}

Jedyną metodą, która powoduje wyciek pamięci w moim przykładzie jest CopyDummyWithLeak. Powodem jest to, że ARC nie wie, że copySelector zwraca zachowany obiekt.

Jeśli uruchomisz narzędzie Memory Leak, możesz zobaczyć poniższy obrazek: ...i nie ma wycieków pamięci w żadnym innym przypadku:

Aby makro Scotta Thompsona było bardziej ogólne:

// 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")

Następnie użyj go w ten sposób:

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

Ponieważ używasz ARC musisz używać iOS 4.0 lub nowszego. Oznacza to, że można użyć bloków. Gdyby zamiast zapamiętywać selektor do wykonania zamiast wziąć blok, ARC byłby w stanie lepiej śledzić, co się dzieje i nie musiałbyś ryzykować przypadkowego wprowadzenia wycieku pamięci.

Nie tłumić ostrzeżeń!

Istnieje nie mniej niż 12 alternatywne rozwiązania majsterkowania z kompilatorem.
Podczas gdy jesteś sprytny w czasie pierwszej implementacji, niewielu inżynierów na Ziemi może podążać Twoimi śladami, a ten kod w końcu się zepsuje.

Bezpieczne Trasy:

Wszystkie te rozwiązania będą działać, w pewnym stopniu odbiegając od pierwotnego zamiaru. Załóżmy, że param może być nil Jeśli tak pragnienie:

Bezpieczna droga, takie samo zachowanie konceptualne:

// 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]];

Bezpieczna trasa, nieco inne zachowanie:

(Zobacz to odpowiedź)
Użyj dowolnego wątku zamiast [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]];

Niebezpieczne Trasy

wymaga pewnego rodzaju wyciszenia kompilatora, które z pewnością się zepsuje. Zauważ, że w chwili obecnej, to nie włamał się Swift.

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

Zamiast używać podejścia blokowego, które sprawiało mi pewne problemy:

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

Użyję NSInvocation, TAK:

    -(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];
    }

Jeśli nie musisz podawać żadnych argumentów, łatwym obejściem jest użycie valueForKeyPath. Jest to możliwe nawet na Class obiekcie.

NSString *colorName = @"brightPinkColor";
id uicolor = [UIColor class];
if ([uicolor respondsToSelector:NSSelectorFromString(colorName)]){
    UIColor *brightPink = [uicolor valueForKeyPath:colorName];
    ...
}

Możesz również użyć protokołu tutaj. Więc utwórz protokół w ten sposób:

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

W klasie, która musi zadzwonić do selektora, masz wtedy właściwość@.

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

Gdy musisz wywołać @selector(doSomethingWithObject:) w instancji MyObject, zrób to:

[self.source doSomethingWithObject:object];