Estou recebendo o seguinte aviso do compilador ARC:

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

Aqui está o que estou fazendo:

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

Por que recebo esse aviso? Entendo que o compilador não pode verificar se o seletor existe ou não, mas por que isso causaria um vazamento? E como posso alterar meu código para não receber mais esse aviso?

Solução

O compilador está avisando sobre isso por um motivo. É muito raro que esse aviso seja simplesmente ignorado e é fácil contornar isso. Aqui está como:

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

Ou de maneira mais concisa (embora difícil de ler e sem a guarda):

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

Explicação

O que está acontecendo aqui é que você está solicitando ao controlador o ponteiro da função C para o método correspondente ao controlador. Todos NSObjectrespondem methodForSelector:, mas você também pode usar class_getMethodImplementationno tempo de execução Objective-C (útil se você tiver apenas uma referência de protocolo, como id<SomeProto>). Esses ponteiros de função são chamados IMPs e são simples typedefponteiros de função ed ( id (*IMP)(id, SEL, ...)) ¹ . Isso pode estar próximo da assinatura real do método, mas nem sempre corresponde exatamente.

Depois de ter o IMP, você precisará convertê-lo em um ponteiro de função que inclua todos os detalhes que o ARC precisa (incluindo os dois argumentos ocultos implícitos selfe _cmdtodas as chamadas de método Objective-C). Isso é tratado na terceira linha (o (void *)lado direito simplesmente informa ao compilador que você sabe o que está fazendo e não gera um aviso, pois os tipos de ponteiro não correspondem).

Finalmente, você chama o ponteiro de função ² .

Exemplo complexo

Quando o seletor recebe argumentos ou retorna um valor, você precisa mudar um pouco as coisas:

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;

Raciocínio para aviso

O motivo desse aviso é que, com o ARC, o tempo de execução precisa saber o que fazer com o resultado do método que você está chamando. O resultado poderia ser qualquer coisa: void, int, char, NSString *, id, etc. ARC normalmente obtém essas informações do cabeçalho do tipo de objeto que você está trabalhando. ³

Na verdade, existem apenas quatro coisas que a ARC consideraria para o valor de retorno: ⁴

1. Ignorar tipos não-objetos ( void, int, etc.)
2. Reter o valor do objeto e solte quando não for mais usado (suposição padrão)
3. Libere novos valores de objeto quando não forem mais usados ​​(métodos na família init/ copyou atribuídos a ns_returns_retained)
4. Não faça nada e assuma que o valor do objeto retornado será válido no escopo local (até que o conjunto de liberação mais interno seja drenado, atribuído com ns_returns_autoreleased)

A chamada para methodForSelector:assume que o valor de retorno do método que está chamando é um objeto, mas não o retém / libera. Portanto, você pode criar um vazamento se seu objeto for lançado como no item 3 acima (ou seja, o método que você está chamando retorna um novo objeto).

Para os seletores que você está tentando chamar de retorno voidou outros não-objetos, você pode habilitar os recursos do compilador a ignorar o aviso, mas pode ser perigoso. Eu vi o Clang passar por algumas iterações de como ele lida com valores de retorno que não são atribuídos a variáveis ​​locais. Não há razão para que, com o ARC ativado, ele não possa reter e liberar o valor do objeto retornado, methodForSelector:mesmo que você não queira usá-lo. Do ponto de vista do compilador, é um objeto, afinal. Isso significa que, se o método que você está chamando someMethodretornar um objeto não (incluindo void), você poderá acabar com um valor de ponteiro de lixo sendo retido / liberado e travado.

Argumentos adicionais

Uma consideração é que esse é o mesmo aviso que ocorrerá performSelector:withObject:e você poderá ter problemas semelhantes ao não declarar como esse método consome parâmetros. O ARC permite declarar parâmetros consumidos e, se o método consumir o parâmetro, você provavelmente enviará uma mensagem para um zumbi e trava. Existem maneiras de contornar isso com a conversão em ponte, mas realmente seria melhor simplesmente usar a IMPmetodologia de ponteiro e de função acima. Como os parâmetros consumidos raramente são um problema, é provável que isso não ocorra.

Seletores estáticos

Curiosamente, o compilador não irá reclamar dos seletores declarados estaticamente:

[_controller performSelector:@selector(someMethod)];

A razão para isso é porque o compilador realmente é capaz de registrar todas as informações sobre o seletor e o objeto durante a compilação. Não precisa fazer suposições sobre nada. (Eu verifiquei isso um ano atrás, olhando a fonte, mas não tenho uma referência no momento.)

Supressão

Ao tentar pensar em uma situação em que a supressão desse aviso seria necessária e um bom design de código, estou ficando em branco. Alguém compartilhe se eles tiveram uma experiência em que o silenciamento desse aviso era necessário (e o acima não lida com as coisas corretamente).

Mais

É possível criar um NSMethodInvocationpara lidar com isso também, mas isso exige muito mais digitação e também é mais lento, por isso há poucas razões para fazê-lo.

História

Quando a performSelector:família de métodos foi adicionada pela primeira vez ao Objective-C, o ARC não existia. Ao criar o ARC, a Apple decidiu que um aviso deveria ser gerado para esses métodos como uma maneira de orientar os desenvolvedores a usar outros meios para definir explicitamente como a memória deve ser manipulada ao enviar mensagens arbitrárias por meio de um seletor nomeado. No Objective-C, os desenvolvedores conseguem fazer isso usando projeções de estilo C em ponteiros de função bruta.

Com a introdução do Swift, a Apple documentou a performSelector:família de métodos como "inerentemente inseguros" e eles não estão disponíveis para o Swift.

Com o tempo, vimos essa progressão:

1. As versões anteriores do Objective-C permitem performSelector:(gerenciamento manual de memória)
2. Objective-C com ARC alerta para o uso de performSelector:
3. Swift não tem acesso performSelector:e documenta esses métodos como "inerentemente inseguros"

A idéia de enviar mensagens com base em um seletor nomeado não é, no entanto, um recurso "inerentemente inseguro". Essa idéia foi usada com sucesso por um longo tempo no Objective-C, bem como em muitas outras linguagens de programação.

¹ Todos os métodos de Objective-C tem dois argumentos ocultos, selfe _cmdque são adicionados implicitamente quando você chamar um método.

^{2 A} chamada de uma NULLfunção não é segura em C. O guarda usado para verificar a presença do controlador garante que temos um objeto. Nós, portanto, sei que nós vamos ter uma IMPde methodForSelector:(embora possa ser _objc_msgForward, a entrada no sistema de encaminhamento de mensagens). Basicamente, com a guarda no lugar, sabemos que temos uma função a chamar.

³ Na verdade, é possível obter informações incorretas se você declarar objetos ide não estiver importando todos os cabeçalhos. Você pode acabar com falhas no código que o compilador acha que está bem. Isso é muito raro, mas pode acontecer. Geralmente, você recebe um aviso de que não sabe qual das duas assinaturas de método deve escolher.

⁴ Consulte a referência ARC sobre valores de retorno acumulados e valores de retorno não acumulados para mais detalhes.

No compilador LLVM 3.0 no Xcode 4.2, você pode suprimir o aviso da seguinte maneira:

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

Se você estiver recebendo o erro em vários locais e quiser usar o sistema de macro C para ocultar os pragmas, poderá definir uma macro para facilitar a supressão do aviso:

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

Você pode usar a macro assim:

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

Se você precisar do resultado da mensagem executada, poderá fazer o seguinte:

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

Meu palpite sobre isso é o seguinte: como o seletor é desconhecido para o compilador, o ARC não pode aplicar o gerenciamento de memória adequado.

De fato, há momentos em que o gerenciamento de memória está vinculado ao nome do método por uma convenção específica. Especificamente, estou pensando em construtores de conveniência versus métodos make ; o primeiro retorno por convenção de um objeto liberado automaticamente; o último um objeto retido. A convenção é baseada nos nomes do seletor; portanto, se o compilador não conhecer o seletor, não poderá impor a regra de gerenciamento de memória adequada.

Se isso estiver correto, acho que você pode usar seu código com segurança, desde que tudo esteja correto quanto ao gerenciamento de memória (por exemplo, que seus métodos não retornem objetos que eles alocam).

No seu Build Build Settings , em Other Warning Flags ( WARNING_CFLAGS), adicione
-Wno-arc-performSelector-leaks

Agora, verifique se o seletor que você está chamando não faz com que seu objeto seja retido ou copiado.

Como uma solução alternativa até que o compilador permita substituir o aviso, você pode usar o tempo de execução

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

ao invés de

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

Você terá que

#import <objc/message.h>

Para ignorar o erro apenas no arquivo com o seletor de execução, adicione um #pragma da seguinte maneira:

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

Isso ignoraria o aviso nessa linha, mas ainda o permitiria durante o restante do seu projeto.

Estranho, mas verdadeiro: se aceitável (ou seja, o resultado é nulo e você não se importa de deixar o ciclo de execução rodar uma vez), adicione um atraso, mesmo que seja zero:

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

Isso remove o aviso, presumivelmente porque assegura ao compilador que nenhum objeto pode ser retornado e, de alguma forma, mal gerenciado.

Aqui está uma macro atualizada com base na resposta dada acima. Este deve permitir que você agrupe seu código mesmo com uma declaração de retorno.

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

Este código não envolve sinalizadores de compilador ou chamadas diretas de tempo de execução:

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

NSInvocationpermite que vários argumentos sejam definidos, ao contrário, performSelectorisso funcionará em qualquer método.

Bem, muitas respostas aqui, mas como isso é um pouco diferente, combinando algumas respostas que pensei em colocar. Estou usando uma categoria NSObject que verifica se o seletor retorna nulo e também suprime o compilador Atenção.

#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

Por uma questão de posteridade, eu decidi jogar meu chapéu no ringue :)

Recentemente, tenho visto cada vez mais reestruturações fora do target/ selectorparadigma, a favor de coisas como protocolos, blocos, etc. No entanto, há um substituto substituto performSelectorque já usei algumas vezes agora:

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

Estes parecem ser um substituto limpo, seguro para ARC e quase idêntico, performSelectorsem ter que se preocupar muito com isso objc_msgSend().

No entanto, não faço ideia se existe um analógico disponível no iOS.

A resposta de Matt Galloway neste tópico explica o porquê:

Considere o seguinte:

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

Agora, como o ARC pode saber que o primeiro retorna um objeto com uma contagem de retenção de 1, mas o segundo retorna um objeto que é liberado automaticamente?

Parece que geralmente é seguro suprimir o aviso se você estiver ignorando o valor de retorno. Não sei qual é a melhor prática se você realmente precisa obter um objeto retido do performSelector - além de "não faça isso".

O @ c-road fornece o link correto com a descrição do problema aqui . Abaixo você pode ver meu exemplo, quando performSelector causa um vazamento de memória.

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

O único método, que causa vazamento de memória no meu exemplo, é CopyDummyWithLeak. O motivo é que o ARC não sabe, que copySelector retorna o objeto retido.

Se você executar a Ferramenta de vazamento de memória, poderá ver a seguinte imagem: ... e não haverá vazamento de memória em nenhum outro caso:

Para tornar a macro de Scott Thompson mais genérica:

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

Em seguida, use-o assim:

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

Não suprima avisos!

Existem pelo menos 12 soluções alternativas para mexer no compilador.
Enquanto você está sendo esperto no momento da primeira implementação, poucos engenheiros na Terra podem seguir seus passos, e esse código acabará quebrando.

Rotas seguras:

Todas essas soluções funcionarão, com algum grau de variação em relação à sua intenção original. Suponha que parampode ser, nilse você desejar:

Rota segura, mesmo comportamento conceitual:

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

Rota segura, comportamento ligeiramente diferente:

(Veja esta resposta)
Use qualquer thread em vez de [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]];

Rotas perigosas

Requer algum tipo de silenciamento do compilador, que está fadado a quebrar. Note-se que no momento presente, ele fez pausa em Swift .

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

Como você está usando o ARC, você deve usar o iOS 4.0 ou posterior. Isso significa que você pode usar blocos. Se, em vez de lembrar do seletor para executar, você executasse um bloco, o ARC seria capaz de rastrear melhor o que realmente está acontecendo e você não precisaria correr o risco de introduzir acidentalmente um vazamento de memória.

Em vez de usar a abordagem de bloco, o que me deu alguns problemas:

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

Vou usar o NSInvocation, assim:

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

Se você não precisar passar nenhum argumento, uma solução fácil é usar valueForKeyPath. Isso é possível em um Classobjeto.

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

Você também pode usar um protocolo aqui. Então, crie um protocolo como este:

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

Na sua turma que precisa chamar seu seletor, você tem uma propriedade @.

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

Quando você precisar chamar @selector(doSomethingWithObject:)uma instância do MyObject, faça o seguinte:

[self.source doSomethingWithObject:object];