Je reçois l'avertissement suivant du compilateur ARC:

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

Voici ce que je fais:

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

Pourquoi ai-je cet avertissement? Je comprends que le compilateur ne peut pas vérifier si le sélecteur existe ou non, mais pourquoi cela provoquerait-il une fuite? Et comment puis-je changer mon code pour ne plus recevoir cet avertissement?

Solution

Le compilateur l'avertit pour une raison. Il est très rare que cet avertissement soit simplement ignoré et il est facile de contourner ce problème. Voici comment:

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

Ou plus laconiquement (bien que difficile à lire et sans le garde):

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

Explication

Ce qui se passe ici, c'est que vous demandez au contrôleur le pointeur de la fonction C pour la méthode correspondant au contrôleur. Tous NSObjectrépondent à methodForSelector:, mais vous pouvez également utiliser class_getMethodImplementationdans le runtime Objective-C (utile si vous n'avez qu'une référence de protocole, comme id<SomeProto>). Ces pointeurs de fonction sont appelés IMPs et sont de simples typedefpointeurs de fonction ed ( id (*IMP)(id, SEL, ...)) ¹ . Cela peut être proche de la signature de méthode réelle de la méthode, mais ne correspondra pas toujours exactement.

Une fois que vous avez le IMP, vous devez le convertir en un pointeur de fonction qui inclut tous les détails dont ARC a besoin (y compris les deux arguments cachés implicites selfet _cmdde chaque appel de méthode Objective-C). Ceci est géré dans la troisième ligne (le (void *)côté droit indique simplement au compilateur que vous savez ce que vous faites et ne pas générer d'avertissement car les types de pointeurs ne correspondent pas).

Enfin, vous appelez le pointeur de fonction ² .

Exemple complexe

Lorsque le sélecteur prend des arguments ou renvoie une valeur, vous devrez changer un peu les choses:

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;

Raison de l'avertissement

La raison de cet avertissement est qu'avec ARC, le runtime doit savoir quoi faire avec le résultat de la méthode que vous appelez. Le résultat pourrait être quelque chose: void, int, char, NSString *, id, etc. ARC reçoit normalement ces informations de l' en- tête du type d'objet que vous travaillez avec. ³

ARC ne prend en compte que 4 éléments pour la valeur de retour: ⁴

1. Ignorer types non-objet ( void, int, etc.)
2. Conserver la valeur de l'objet, puis la relâcher lorsqu'elle n'est plus utilisée (hypothèse standard)
3. Libérer de nouvelles valeurs d'objet lorsqu'elles ne sont plus utilisées (méthodes dans la famille init/ copyou attribuées avec ns_returns_retained)
4. Ne rien faire et supposer que la valeur d'objet retournée sera valide dans la portée locale (jusqu'à ce que le pool de versions le plus interne soit vidé, attribué avec ns_returns_autoreleased)

L'appel à methodForSelector:suppose que la valeur de retour de la méthode qu'il appelle est un objet, mais ne le conserve pas / ne le libère pas. Ainsi, vous pourriez finir par créer une fuite si votre objet est censé être libéré comme au n ° 3 ci-dessus (c'est-à-dire que la méthode que vous appelez renvoie un nouvel objet).

Pour les sélecteurs que vous essayez d'appeler ce retour voidou d'autres non-objets, vous pouvez activer les fonctionnalités du compilateur pour ignorer l'avertissement, mais cela peut être dangereux. J'ai vu Clang parcourir quelques itérations sur la façon dont il gère les valeurs de retour qui ne sont pas affectées aux variables locales. Il n'y a aucune raison qu'avec ARC activé, il ne puisse pas conserver et libérer la valeur d'objet retournée methodForSelector:même si vous ne voulez pas l'utiliser. Du point de vue du compilateur, c'est un objet après tout. Cela signifie que si la méthode que vous appelez, someMethodretourne un objet non (y compris void), vous pourriez vous retrouver avec une valeur de pointeur de mémoire conservée / libérée et planter.

Arguments supplémentaires

Une considération est que c'est le même avertissement qui se produira performSelector:withObject:et vous pourriez rencontrer des problèmes similaires en ne déclarant pas comment cette méthode consomme les paramètres. ARC permet de déclarer les paramètres consommés , et si la méthode consomme le paramètre, vous finirez probablement par envoyer un message à un zombie et à planter. Il existe des moyens de contourner ce problème avec le casting ponté, mais il serait vraiment préférable d'utiliser simplement la IMPméthodologie de pointeur de fonction ci-dessus. Étant donné que les paramètres consommés sont rarement un problème, cela ne devrait pas se produire.

Sélecteurs statiques

Fait intéressant, le compilateur ne se plaindra pas des sélecteurs déclarés statiquement:

[_controller performSelector:@selector(someMethod)];

La raison en est que le compilateur est réellement capable d'enregistrer toutes les informations sur le sélecteur et l'objet pendant la compilation. Il n'a pas besoin de faire d'hypothèses sur quoi que ce soit. (J'ai vérifié cela il y a un an en regardant la source, mais je n'ai pas de référence pour le moment.)

Suppression

En essayant de penser à une situation où la suppression de cet avertissement serait nécessaire et une bonne conception de code, je suis vide. Quelqu'un s'il vous plaît partager s'ils ont eu une expérience où le silence de cet avertissement était nécessaire (et ce qui précède ne gère pas les choses correctement).

Plus

Il est possible de créer un NSMethodInvocationpour gérer cela également, mais cela nécessite beaucoup plus de frappe et est également plus lent, il n'y a donc aucune raison de le faire.

Histoire

Lorsque la performSelector:famille de méthodes a été ajoutée pour la première fois à Objective-C, ARC n'existait pas. Lors de la création d'ARC, Apple a décidé qu'un avertissement devait être généré pour ces méthodes afin de guider les développeurs vers l'utilisation d'autres moyens pour définir explicitement comment la mémoire devait être gérée lors de l'envoi de messages arbitraires via un sélecteur nommé. Dans Objective-C, les développeurs peuvent le faire en utilisant des transtypages de style C sur des pointeurs de fonction bruts.

Avec l'introduction de Swift, Apple a documenté la performSelector:famille de méthodes comme "intrinsèquement dangereuses" et elles ne sont pas disponibles pour Swift.

Au fil du temps, nous avons vu cette progression:

1. Les premières versions d'Objective-C permettent performSelector:(gestion manuelle de la mémoire)
2. Objective-C avec ARC met en garde contre l'utilisation de performSelector:
3. Swift n'a pas accès à performSelector:ces méthodes et ne les documente pas comme "intrinsèquement dangereuses"

L'idée d'envoyer des messages sur la base d'un sélecteur nommé n'est cependant pas une fonctionnalité "intrinsèquement dangereuse". Cette idée est utilisée avec succès depuis longtemps dans Objective-C ainsi que dans de nombreux autres langages de programmation.

¹ Toutes les méthodes Objective-C ont deux arguments cachés, selfet _cmdqui sont implicitement ajoutés lorsque vous appelez une méthode.

^{2 L'} appel d'une NULLfonction n'est pas sûr en C. Le gardien utilisé pour vérifier la présence du contrôleur s'assure que nous avons un objet. Nous savons donc que nous aurons un IMPde methodForSelector:(bien qu'il puisse être _objc_msgForward, l' entrée dans le système de transfert des messages). Fondamentalement, avec la garde en place, nous savons que nous avons une fonction à appeler.

³ En fait, il est possible qu'il obtienne des informations erronées si vous déclarez des objets comme idet que vous n'importez pas tous les en-têtes. Vous pourriez vous retrouver avec des plantages dans le code que le compilateur pense être correct. C'est très rare, mais cela pourrait arriver. Habituellement, vous recevrez simplement un avertissement indiquant qu'il ne sait pas laquelle des deux signatures de méthode choisir.

⁴ Voir la référence ARC sur les valeurs de retour conservées et les valeurs de retour non retenues pour plus de détails.

Dans le compilateur LLVM 3.0 dans Xcode 4.2, vous pouvez supprimer l'avertissement comme suit:

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

Si vous obtenez l'erreur à plusieurs endroits et que vous souhaitez utiliser le système de macros C pour masquer les pragmas, vous pouvez définir une macro pour faciliter la suppression de l'avertissement:

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

Vous pouvez utiliser la macro comme ceci:

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

Si vous avez besoin du résultat du message effectué, vous pouvez le faire:

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

Ma conjecture à ce sujet est la suivante: puisque le sélecteur est inconnu du compilateur, ARC ne peut pas appliquer une gestion de la mémoire appropriée.

En fait, il y a des moments où la gestion de la mémoire est liée au nom de la méthode par une convention spécifique. Plus précisément, je pense aux constructeurs de commodité et aux méthodes de fabrication ; l'ancien restitue par convention un objet libéré automatiquement; ce dernier un objet retenu. La convention est basée sur les noms du sélecteur, donc si le compilateur ne connaît pas le sélecteur, il ne peut pas appliquer la règle de gestion de mémoire appropriée.

Si c'est correct, je pense que vous pouvez utiliser votre code en toute sécurité, à condition de vous assurer que tout va bien pour la gestion de la mémoire (par exemple, que vos méthodes ne retournent pas les objets qu'elles allouent).

Dans les paramètres de construction de votre projet , sous Autres indicateurs d'avertissement ( WARNING_CFLAGS), ajoutez
-Wno-arc-performSelector-leaks

Assurez-vous maintenant que le sélecteur que vous appelez n'entraîne pas la conservation ou la copie de votre objet.

Comme solution de contournement jusqu'à ce que le compilateur permette de remplacer l'avertissement, vous pouvez utiliser le runtime

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

au lieu de

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

Tu devras

#import <objc/message.h>

Pour ignorer l'erreur uniquement dans le fichier avec le sélecteur perform, ajoutez un #pragma comme suit:

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

Cela ignorerait l'avertissement sur cette ligne, mais l'autoriserait tout au long du reste de votre projet.

Étrange mais vrai: si cela est acceptable (c'est-à-dire que le résultat est nul et que cela ne vous dérange pas de laisser le cycle runloop une fois), ajoutez un délai, même s'il est nul:

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

Cela supprime l'avertissement, probablement parce qu'il rassure le compilateur qu'aucun objet ne peut être retourné et mal géré.

Voici une macro mise à jour basée sur la réponse donnée ci-dessus. Celui-ci devrait vous permettre d'encapsuler votre code même avec une déclaration de retour.

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

Ce code n'implique pas de drapeaux de compilateur ni d'appels d'exécution directs:

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

NSInvocationpermet de définir plusieurs arguments, contrairement à performSelectorce qui fonctionnera sur n'importe quelle méthode.

Eh bien, beaucoup de réponses ici, mais comme c'est un peu différent, en combinant quelques réponses, je pensais que je les mettrais. J'utilise une catégorie NSObject qui vérifie que le sélecteur retourne vide, et supprime également le compilateur Attention.

#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

Pour la postérité, j'ai décidé de jeter mon chapeau dans le ring :)

Récemment , j'ai été voir de plus en plus loin de la restructuration du target/ selectorparadigme, en faveur des choses telles que des protocoles, des blocs, etc. Cependant, il y a une solution de remplacement pour performSelectorque je l' ai utilisé quelques fois:

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

Ceux-ci semblent être un remplacement propre, sans danger pour l'ARC et presque identique performSelectorsans avoir trop à faire avecobjc_msgSend() .

Cependant, je n'ai aucune idée s'il existe un analogue disponible sur iOS.

La réponse de Matt Galloway sur ce sujet explique pourquoi:

Considérer ce qui suit:

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

Maintenant, comment ARC peut-il savoir que le premier retourne un objet avec un nombre de retenues de 1 mais que le second retourne un objet qui est libéré automatiquement?

Il semble qu'il soit généralement sûr de supprimer l'avertissement si vous ignorez la valeur de retour. Je ne sais pas quelle est la meilleure pratique si vous avez vraiment besoin d'obtenir un objet conservé de performSelector - autre que "ne faites pas ça".

@ c-road fournit le bon lien avec la description du problème ici . Ci-dessous, vous pouvez voir mon exemple, lorsque performSelector provoque une fuite de mémoire.

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

La seule méthode qui provoque une fuite de mémoire dans mon exemple est CopyDummyWithLeak. La raison en est que ARC ne sait pas, que copySelector renvoie un objet conservé.

Si vous exécutez l'outil Memory Leak Tool, vous pouvez voir l'image suivante: ... et il n'y a aucune fuite de mémoire dans les autres cas:

Pour rendre la macro de Scott Thompson plus générique:

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

Ensuite, utilisez-le comme ceci:

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

Ne supprimez pas les avertissements!

Il n'y a pas moins de 12 solutions alternatives au bricolage avec le compilateur.
Alors que vous êtes intelligent au moment de la première mise en œuvre, peu d'ingénieurs sur Terre peuvent suivre vos traces, et ce code finira par se casser.

Itinéraires sûrs:

Toutes ces solutions fonctionneront, avec un certain degré de variation par rapport à votre intention initiale. Supposons que cela parampuisse être nilsi vous le souhaitez:

Route sûre, même comportement conceptuel:

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

Itinéraire sûr, comportement légèrement différent:

(Voir cette réponse)
Utilisez n'importe quel fil au lieu 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]];

Routes dangereuses

Nécessite une sorte de mise en sourdine du compilateur, qui est susceptible de se casser. Notez qu'à l'heure actuelle, il s'est cassé dans Swift .

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

Étant donné que vous utilisez ARC, vous devez utiliser iOS 4.0 ou une version ultérieure. Cela signifie que vous pouvez utiliser des blocs. Si au lieu de vous souvenir du sélecteur pour vous exécuter, vous preniez un bloc, ARC serait en mesure de mieux suivre ce qui se passe réellement et vous n'auriez pas à courir le risque d'introduire accidentellement une fuite de mémoire.

Au lieu d'utiliser l'approche par blocs, ce qui m'a posé quelques problèmes:

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

J'utiliserai NSInvocation, comme ceci:

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

Si vous n'avez pas besoin de passer d'arguments, une solution de contournement simple est à utiliser valueForKeyPath. C'est même possible sur un Classobjet.

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

Vous pouvez également utiliser un protocole ici. Alors, créez un protocole comme ceci:

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

Dans votre classe qui doit appeler votre sélecteur, vous avez alors un @property.

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

Lorsque vous devez appeler @selector(doSomethingWithObject:)dans une instance de MyObject, procédez comme suit:

[self.source doSomethingWithObject:object];