ARCコンパイラから次の警告が表示されます。

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

これが私がやっていることです：

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

なぜこの警告が出るのですか？セレクターが存在するかどうかをコンパイラーがチェックできないことを理解していますが、なぜリークが発生するのですか？そして、この警告を受け取らないようにコードを変更するにはどうすればよいですか？

解決

コンパイラは、これについて何らかの理由で警告しています。この警告が単に無視されることは非常にまれであり、簡単に回避できます。方法は次のとおりです。

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

またはもっと簡潔に（読みづらいとガードなしでは）：

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

説明

ここでは、コントローラーに対応するメソッドのC関数ポインターをコントローラーに要求しています。すべてNSObjectのはに応答しmethodForSelector:ますがclass_getMethodImplementation、Objective-Cランタイムでも使用できます（などのプロトコル参照しかない場合に役立ちますid<SomeProto>）。これらの関数ポインターはIMPs と呼ばれ、単純なtypedefed関数ポインター（id (*IMP)(id, SEL, ...)）¹です。これは、メソッドの実際のメソッドシグネチャに近い場合がありますが、常に正確に一致するとは限りません。

を取得したらIMP、ARCが必要とするすべての詳細（2つの暗黙的な隠し引数selfと_cmdすべてのObjective-Cメソッド呼び出しの詳細を含む）を含む関数ポインターにキャストする必要があります。これは3行目で処理されます（(void *)右側は、ポインターの型が一致しないため、何をしているのかを知っていて、警告を生成しないことをコンパイラーに通知するだけです）。

最後に、関数ポインター²を呼び出します。

複雑な例

セレクターが引数を取るか値を返す場合、少し変更する必要があります。

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;

警告の理由

この警告の理由は、ARCではランタイムが、呼び出しているメソッドの結果をどう処理するかを知る必要があるためです。結果は何もすることができますvoid、int、char、NSString *、id、などARCは通常、あなたが作業しているオブジェクトタイプのヘッダからこの情報を取得します。^３

ARCが戻り値について考慮すべきことは、実際には4つだけです：⁴

1. 非オブジェクト型（無視するvoid、intなど）
2. オブジェクト値を保持し、使用されなくなったら解放します（標準の想定）
3. 使用されなくなったときに新しいオブジェクト値を解放します（init/ copyファミリのメソッド、またはで属性付けされたメソッドns_returns_retained）
4. 何もせず、返されたオブジェクト値がローカルスコープで有効であると想定します（最も内側のリリースプールが排出され、で属性が付与されるまでns_returns_autoreleased）

の呼び出しmethodForSelector:は、呼び出しているメソッドの戻り値がオブジェクトであることを前提としていますが、保持/解放しません。したがって、上記の＃3のようにオブジェクトが解放されることになっていると、リークが発生する可能性があります（つまり、呼び出しているメソッドが新しいオブジェクトを返します）。

その戻り値voidまたは他の非オブジェクトを呼び出そうとしているセレクターの場合、コンパイラー機能を有効にして警告を無視することができますが、危険な場合があります。Clangがローカル変数に割り当てられていない戻り値を処理する方法を数回繰り返すのを見てきました。ARCを有効にしてmethodForSelector:、使用したくない場合でも、返されたオブジェクト値を保持および解放できない理由はありません。コンパイラの観点から見ると、それは結局オブジェクトです。つまりsomeMethod、呼び出しているメソッドがを含む非オブジェクト（を含むvoid）を返している場合、ガベージポインターの値が保持/解放されてクラッシュする可能性があります。

追加の引数

1つの考慮事項は、これは同じ警告が発生することでperformSelector:withObject:あり、そのメソッドがパラメーターをどのように消費するかを宣言しないと、同様の問題が発生する可能性があるということです。ARCでは、消費されたパラメーターを宣言できます。メソッドがパラメーターを消費した場合、おそらく最終的にはゾンビにメッセージを送信してクラッシュします。ブリッジドキャスティングでこれを回避する方法はいくつかありますが、実際には、IMP上記のと関数ポインタの方法論を単に使用する方が良いでしょう。消費されたパラメーターがめったに問題にならないので、これは起こりそうにありません。

静的セレクター

興味深いことに、コンパイラーは静的に宣言されたセレクターについて文句を言うことはありません。

[_controller performSelector:@selector(someMethod)];

これは、コンパイラーがコンパイル時にセレクターとオブジェクトに関するすべての情報を実際に記録できるためです。何かについて何も仮定する必要はありません。（私は1年ほど前にソースを調べて確認しましたが、現時点ではリファレンスがありません。）

抑制

この警告の抑制が必要であり、優れたコード設計が必要となる状況を考えるために、私は何も考えていません。この警告を止めることが必要だった経験がある場合は、誰かが共有してください（上記では適切に処理されません）。

もっと

これNSMethodInvocationを処理するためにを構築することも可能ですが、これを行うにはより多くのタイピングが必要であり、速度も遅いため、それを行う理由はほとんどありません。

歴史

performSelector:メソッドのファミリーが最初にObjective-Cに追加されたとき、ARCは存在しませんでした。ARCの作成中、Appleは、名前付きセレクターを介して任意のメッセージを送信するときにメモリをどのように処理するかを明示的に定義する他の手段を開発者に案内する方法として、これらのメソッドに対して警告を生成することを決定しました。Objective-Cでは、開発者は生の関数ポインターにCスタイルのキャストを使用してこれを行うことができます。

Swiftの導入に伴い、Apple はperformSelector:一連のメソッドを「本質的に安全ではない」と文書化し、Swiftでは利用できなくなりました。

時とともに、私たちはこの進歩を見てきました：

1. Objective-Cの初期バージョンではperformSelector:（手動メモリ管理）が可能です
2. ARCを備えたObjective-Cは、 performSelector:
3. SwiftはperformSelector:これらのメソッドへのアクセス権を持たず、「本質的に安全ではない」と文書化しています

ただし、名前付きセレクタに基づいてメッセージを送信するという考えは、「本質的に安全ではない」機能ではありません。このアイデアは、Objective-Cや他の多くのプログラミング言語で長い間成功裏に使用されてきました。

¹すべてのObjective-Cメソッドには2つの隠し引数がselfあり_cmd、それらはメソッドを呼び出すときに暗黙的に追加されます。

²NULL Cでは関数の呼び出しは安全ではありません。コントローラーの存在を確認するために使用されるガードは、オブジェクトがあることを確認します。したがって、IMPfromを取得することがわかりますmethodForSelector:（_objc_msgForwardメッセージ転送システムへのエントリである場合もあります）。基本的に、ガードを配置すると、呼び出す関数があることがわかります。

³実際には、オブジェクトを次のように宣言idし、すべてのヘッダーをインポートしていない場合、誤った情報を取得する可能性があります。コンパイラが問題ないと考えるコードでクラッシュが発生する可能性があります。これは非常にまれですが、発生する可能性があります。通常、2つのメソッドシグネチャのどちらから選択するかがわからないという警告が表示されます。

⁴上でARC基準参照保持戻り値と保持されない戻り値の詳細については。

Xcode 4.2のLLVM 3.0コンパイラでは、次のように警告を抑制できます。

#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は適切なメモリー管理を強制できません。

実際、メモリ管理が特定の規則によってメソッドの名前に関連付けられている場合があります。特に、便利なコンストラクターとmakeメソッドを考えています。前者は慣例により自動解放されたオブジェクトを返します。後者は保持オブジェクトです。規則はセレクターの名前に基づいているため、コンパイラーがセレクターを認識していない場合、適切なメモリー管理規則を適用できません。

これが正しい場合、メモリ管理に関してすべてが問題ないことを確認すれば（たとえば、メソッドが割り当てたオブジェクトをメソッドが返さないこと）、コードを安全に使用できると思います。

プロジェクトのビルド設定で、その他の警告フラグ（WARNING_CFLAGS）の下に、
-Wno-arc-performSelector-leaks

ここで、呼び出すセレクターによってオブジェクトが保持またはコピーされないことを確認してください。

コンパイラが警告を上書きできるようになるまでの回避策として、ランタイムを使用できます

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

の代わりに

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

あなたはする必要があります

#import <objc/message.h>

実行セレクターがあるファイルでのみエラーを無視するには、次のように#pragmaを追加します。

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

これにより、この行の警告は無視されますが、プロジェクトの他の部分では引き続き許可されます。

奇妙だが真実：許容できる場合（つまり、結果が無効であり、runloopを1回循環させてもかまわない場合）、これがゼロであっても遅延を追加します。

[_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これはどのメソッドでも機能します。

さて、ここにはたくさんの答えがありますが、これは少し異なるので、私が入れたと思ったいくつかの答えを組み合わせています。セレクターがvoidを返し、コンパイラーも抑制していることを確認するNSObjectカテゴリーを使用しています。警告。

#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私が今まで何度か使用したものに代わるドロップインが1つあります。

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

これらは、クリーンでARCセーフであり、とほとんど関係performSelectorなく使用できるとほぼ同じように置き換えられobjc_msgSend()ます。

ただし、iOSで利用可能なアナログがあるかどうかはわかりません。

このスレッドに関するMatt Gallowayの回答がその理由を説明しています。

以下を検討してください。

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

では、ARCは、最初のオブジェクトが保持カウント1のオブジェクトを返し、2番目のオブジェクトが自動解放されたオブジェクトを返すことをどのようにして知ることができますか？

戻り値を無視する場合は、警告を抑制しても安全であると思われます。「それをしないでください」以外の方法で、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];
                )

警告を抑制しないでください！

コンパイラをいじくり回すには、少なくとも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]];

危険なルート

壊れるに違いない、ある種のコンパイラのサイレンシングが必要です。現時点ではSwiftで壊れていたことに注意してください。

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

ARCを使用しているため、iOS 4.0以降を使用している必要があります。つまり、ブロックを使用できます。セレクターを覚えて実行する代わりにブロックを取った場合、ARCは実際に何が行われているのかをより適切に追跡でき、誤ってメモリリークを引き起こすリスクを冒す必要はありません。

ブロックアプローチを使用する代わりに、いくつかの問題が発生しました。

    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です。これはClassオブジェクトでも可能です。

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

ここでプロトコルを使用することもできます。したがって、次のようなプロトコルを作成します。

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

セレクターを呼び出す必要があるクラスでは、@ propertyがあります。

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

@selector(doSomethingWithObject:)MyObjectのインスタンスを呼び出す必要がある場合は、次のようにします。

[self.source doSomethingWithObject:object];