Otrzymuję następujące ostrzeżenie przez kompilator ARC:

"performSelector may cause a leak because its selector is unknown".

Oto co robię:

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

Dlaczego dostaję to ostrzeżenie? Rozumiem, że kompilator nie może sprawdzić, czy selektor istnieje, czy nie, ale dlaczego miałoby to spowodować wyciek? Jak mogę zmienić kod, aby nie wyświetlało się już to ostrzeżenie?

Rozwiązanie

Kompilator ostrzega o tym z jakiegoś powodu. Bardzo rzadko to ostrzeżenie należy po prostu zignorować i łatwo się obejść. Oto jak:

if (!_controller) { return; }
SEL selector = NSSelectorFromString(@"someMethod");
IMP imp = [_controller methodForSelector:selector];
void (*func)(id, SEL) = (void *)imp;
func(_controller, selector);

Lub bardziej zwięźle (choć trudny do odczytania i bez osłony):

SEL selector = NSSelectorFromString(@"someMethod");
((void (*)(id, SEL))[_controller methodForSelector:selector])(_controller, selector);

Wyjaśnienie

Chodzi o to, że pytasz kontroler o wskaźnik funkcji C dla metody odpowiadającej kontrolerowi. Wszystkie NSObjectreagują methodForSelector:, ale możesz także użyć class_getMethodImplementationw środowisku wykonawczym Objective-C (przydatne, jeśli masz tylko odwołanie do protokołu, takie jak id<SomeProto>). Te wskaźniki funkcji są nazywane IMPs i są prostymi typedefwskaźnikami funkcji ed ( id (*IMP)(id, SEL, ...)) ¹ . Może to być zbliżone do rzeczywistej sygnatury metody, ale nie zawsze będzie dokładnie pasować.

Gdy już go IMPmasz, musisz rzucić go na wskaźnik funkcji, który zawiera wszystkie szczegóły potrzebne ARC (w tym dwa ukryte argumenty ukryte selfi _cmdkażde wywołanie metody Objective-C). Jest to obsługiwane w trzecim wierszu ( (void *)po prawej stronie informuje kompilator, że wiesz, co robisz, i nie generuje ostrzeżenia, ponieważ typy wskaźników nie pasują).

Na koniec wywołujesz wskaźnik funkcji ² .

Złożony przykład

Kiedy selektor przyjmuje argumenty lub zwraca wartość, musisz nieco zmienić rzeczy:

SEL selector = NSSelectorFromString(@"processRegion:ofView:");
IMP imp = [_controller methodForSelector:selector];
CGRect (*func)(id, SEL, CGRect, UIView *) = (void *)imp;
CGRect result = _controller ?
  func(_controller, selector, someRect, someView) : CGRectZero;

Uzasadnienie ostrzeżenia

Powodem tego ostrzeżenia jest to, że w przypadku ARC środowisko wykonawcze musi wiedzieć, co zrobić z wynikiem wywoływanej metody. Rezultatem może być cokolwiek: void, int, char, NSString *, id, itd. ARC normalnie pobiera te informacje z nagłówka typu obiektu ty pracujesz. ³⁾

Są naprawdę tylko 4 rzeczy, które ARC rozważa dla wartości zwracanej: ⁴

1. Rodzaje ignorować niż przedmiot ( void, intitp)
2. Zachowaj wartość obiektu, a następnie zwolnij ją, gdy nie będzie już używana (założenie standardowe)
3. Zwolnij nowe wartości obiektów, gdy nie będą już używane (metody w init/ copyrodzinie lub przypisane do ns_returns_retained)
4. Nie rób nic i zakładaj, że zwrócona wartość obiektu będzie poprawna w zasięgu lokalnym (do momentu wyczerpania wewnętrznej puli zwolnień, przypisanej przez ns_returns_autoreleased)

Wywołanie to methodForSelector:zakłada, że ​​wartość zwracana przez wywoływaną metodę jest obiektem, ale go nie zachowuje / nie zwalnia. Możesz więc spowodować wyciek, jeśli twój obiekt ma zostać zwolniony jak w punkcie 3 powyżej (to znaczy, że wywoływana metoda zwraca nowy obiekt).

W przypadku selektorów, które próbujesz nazwać tym zwrotem voidlub innymi obiektami niebędącymi obiektami, możesz włączyć funkcje kompilatora, aby zignorować ostrzeżenie, ale może to być niebezpieczne. Widziałem, jak Clang przechodzi kilka iteracji tego, w jaki sposób obsługuje zwracane wartości, które nie są przypisane do zmiennych lokalnych. Nie ma powodu, aby po włączeniu ARC nie można było zachować i zwolnić wartości obiektu, która została zwrócona, methodForSelector:nawet jeśli nie chcesz jej używać. Z perspektywy kompilatora jest to jednak obiekt. Oznacza to, że jeśli metoda, którą wywołujesz, someMethodzwraca obiekt niebędący obiektem (w tym void), możesz skończyć z zachowaniem / zwolnieniem wartości wskaźnika śmieci i awarią.

Dodatkowe argumenty

Jednym z powodów jest to, że pojawi się to samo ostrzeżenie performSelector:withObject:i możesz napotkać podobne problemy, nie deklarując, w jaki sposób ta metoda zużywa parametry. ARC pozwala na deklarowanie zużytych parametrów , a jeśli metoda zużywa parametr, prawdopodobnie ostatecznie wyślesz wiadomość do zombie i nastąpi awaria. Istnieją sposoby obejścia tego problemu przy użyciu mostkowania rzutowania, ale tak naprawdę lepiej byłoby po prostu użyć IMPpowyższej metodologii wskaźnika i funkcji. Ponieważ zużyte parametry rzadko stanowią problem, prawdopodobnie się nie pojawi.

Selektory statyczne

Co ciekawe, kompilator nie będzie narzekał na selektory zadeklarowane statycznie:

[_controller performSelector:@selector(someMethod)];

Powodem tego jest fakt, że kompilator faktycznie może rejestrować wszystkie informacje o selektorze i obiekcie podczas kompilacji. Nie musi niczego zakładać. (Sprawdziłem to rok temu, patrząc na źródło, ale nie mam teraz odniesienia.)

Tłumienie

Próbując wymyślić sytuację, w której konieczne byłoby zniesienie tego ostrzeżenia i dobry projekt kodu, wychodzę na pustkę. Ktoś proszę podzielić się, jeśli miał doświadczenie, w którym wyciszenie tego ostrzeżenia było konieczne (a powyższe nie radzi sobie właściwie).

Więcej

Można to również zbudować, NSMethodInvocationaby sobie z tym poradzić, ale wymaga to znacznie więcej pisania i jest wolniejsze, więc nie ma powodu, aby to robić.

Historia

Kiedy performSelector:rodzina metod została po raz pierwszy dodana do celu C, ARC nie istniało. Tworząc ARC, Apple zdecydował, że należy wygenerować ostrzeżenie dla tych metod jako sposób na poprowadzenie programistów do użycia innych środków do jawnego zdefiniowania sposobu obsługi pamięci podczas wysyłania dowolnych wiadomości za pośrednictwem nazwanego selektora. W Objective-C programiści mogą to zrobić, używając rzutów w stylu C na surowych wskaźnikach funkcji.

Wraz z wprowadzeniem Swift, Apple został udokumentowany na performSelector:rodzinę metod jako „z natury niebezpieczne” i nie są one dostępne do Swift.

Z biegiem czasu zaobserwowaliśmy następujący postęp:

1. Wczesne wersje Objective-C pozwalają performSelector:(ręczne zarządzanie pamięcią)
2. Cel C z ARC ostrzega przed użyciem performSelector:
3. Swift nie ma dostępu do performSelector:tych metod i dokumentuje je jako „z natury niebezpieczne”

Idea wysyłania wiadomości na podstawie nazwanego selektora nie jest jednak funkcją „z natury niebezpieczną”. Pomysł ten był z powodzeniem stosowany od dawna w Objective-C, a także w wielu innych językach programowania.

¹ Wszystkie metody Objective-C mają dwa ukryte argumenty, selfa _cmdktóre są domyślnie dodawane podczas wywołania metody.

² Wywołanie NULLfunkcji nie jest bezpieczne w C. Osłona używana do sprawdzania obecności kontrolera zapewnia, że ​​mamy obiekt. Dlatego wiem, że otrzymujemy IMPz methodForSelector:(choć może to być _objc_msgForward, wejście do systemu przekazywania wiadomości). Zasadniczo, gdy strażnik jest na miejscu, wiemy, że mamy funkcję do wywołania.

³ W rzeczywistości możliwe jest uzyskanie błędnych informacji, jeśli zadeklarujesz obiekty jako idi nie importujesz wszystkich nagłówków. Może dojść do awarii kodu, które kompilator uważa za prawidłowe. Jest to bardzo rzadkie, ale może się zdarzyć. Zwykle pojawia się ostrzeżenie, że nie wie, z której z dwóch sygnatur metody wybrać.

⁴ Aby uzyskać więcej informacji, zobacz odniesienie do ARC dotyczące zachowanych wartości zwrotnych i niezatwierdzonych wartości zwrotnych .

W kompilatorze LLVM 3.0 w Xcode 4.2 możesz 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 błąd pojawia się w kilku miejscach i chcesz użyć systemu makr C do ukrycia pragm, możesz zdefiniować makro, aby ułatwić wyłączenie ostrzeżenia:

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

Domyślam się, że: ponieważ selektor nie jest znany kompilatorowi, ARC nie może wymusić właściwego zarządzania pamięcią.

W rzeczywistości zdarza się, że zarządzanie pamięcią jest powiązane z nazwą metody według określonej konwencji. W szczególności myślę o konstruktorach wygody a metodach make ; poprzedni zwrócił konwencją automatycznie wydany obiekt; ten ostatni jest zachowanym przedmiotem. Konwencja opiera się na nazwach selektora, więc jeśli kompilator nie zna selektora, nie może egzekwować właściwej reguły zarządzania pamięcią.

Jeśli jest to poprawne, myślę, że możesz bezpiecznie używać swojego kodu, pod warunkiem, że upewnisz się, że wszystko jest w porządku pod względem zarządzania pamięcią (np. Że twoje metody nie zwracają przydzielonych obiektów).

W projekcie Ustawienia budowania , w obszarze Inne flagi ostrzegawcze ( WARNING_CFLAGS), dodaj
-Wno-arc-performSelector-leaks

Teraz upewnij się, że selektor, do którego dzwonisz, nie powoduje zatrzymania lub skopiowania obiektu.

Aby obejść ten problem, dopóki kompilator nie będzie mógł zastąpić ostrzeżenia, można użyć środowiska wykonawczego

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 perform, dodaj #pragma w następujący sposób:

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

To zignoruje ostrzeżenie w tym wierszu, ale nadal pozwoli na to w pozostałej części projektu.

Dziwne, ale prawdziwe: jeśli dopuszczalne (tzn. Wynik jest nieważny i nie masz nic przeciwko jednokrotnemu cyklowi wybiegu), 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 kompilatorowi, że żaden obiekt nie może zostać zwrócony i jakoś źle zarządzony.

Oto zaktualizowane makro na podstawie odpowiedzi podanej powyżej. Ten powinien pozwolić ci owinąć kod nawet z instrukcją 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]
);

Ten kod nie obejmuje flag kompilatora ani bezpośrednich wywołań środowiska wykonawczego:

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

NSInvocationumożliwia ustawienie wielu argumentów, więc w przeciwieństwie do performSelectortego będzie działać na dowolnej metodzie.

Cóż, wiele odpowiedzi tutaj, ale ponieważ jest to trochę inne, łącząc kilka odpowiedzi, pomyślałem, że je wstawię. Korzystam z kategorii NSObject, która sprawdza, czy selektor zwraca wartość void, a także pomija kompilator ostrzeżenie.

#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

Dla potomności postanowiłem rzucić kapelusz na ring :)

Ostatnio byłem widząc coraz bardziej restrukturyzacji od target/ selectorparadygmatu, za rzeczy, takich jak protokoły, bloków itp Jednak istnieje jeden zamiennik dla performSelectorże użyłem kilka razy:

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

Wydają się być czystym, bezpiecznym dla ARC i prawie identycznym zamiennikiem, performSelectorbez konieczności zbytniego angażowania się objc_msgSend().

Chociaż nie mam pojęcia, czy w iOS jest dostępny analog.

Odpowiedź Matta Gallowaya w tym wątku wyjaśnia, dlaczego:

Rozważ następujące:

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

Skąd więc ARC może wiedzieć, że pierwszy zwraca obiekt z liczbą zatrzymań równą 1, a drugi zwraca obiekt automatycznie wydany?

Wydaje się, że można bezpiecznie wyłączyć ostrzeżenie, jeśli ignorujesz zwracaną wartość. Nie jestem pewien, jaka jest najlepsza praktyka, jeśli naprawdę potrzebujesz uzyskać zachowany obiekt z performSelector - inny niż „nie rób tego”.

@ c-road zapewnia właściwą więź 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 Tool, możesz zobaczyć następujący obrazek: ... i w żadnym innym przypadku nie ma wycieków pamięci:

Aby uczynić makro Scotta Thompsona bardziej ogólnym:

// 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 następujący sposób:

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

Nie usuwaj ostrzeżeń!

Istnieje nie mniej niż 12 alternatywnych rozwiązań majstrowania przy kompilatorze.
Podczas gdy jesteś sprytny w momencie 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ć z pewną różnicą w stosunku do pierwotnego celu. Załóż, że parammoże tak być, niljeśli chcesz:

Bezpieczna trasa, to samo zachowanie koncepcyjne:

// 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 tę 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óry musi się zepsuć. Zauważ, że w chwili obecnej, to zrobił przerwę w Swift .

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

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

Zamiast stosować podejście blokowe, co dało mi pewne problemy:

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

Użyję NSInvocation, tak jak to:

    -(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 przekazywać żadnych argumentów, skorzystaj z łatwego obejścia valueForKeyPath. Jest to nawet możliwe na Classobiekcie.

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. Utwórz więc taki protokół:

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

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

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

Jeśli chcesz wywołać @selector(doSomethingWithObject:)instancję MyObject, wykonaj następujące czynności:

[self.source doSomethingWithObject:object];