Tôi đang nhận được cảnh báo sau bởi trình biên dịch ARC:

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

Đây là những gì tôi đang làm:

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

Tại sao tôi nhận được cảnh báo này? Tôi hiểu trình biên dịch không thể kiểm tra xem bộ chọn có tồn tại hay không, nhưng tại sao điều đó lại gây rò rỉ? Và làm cách nào để thay đổi mã của mình để tôi không nhận được cảnh báo này nữa?

Giải pháp

Trình biên dịch cảnh báo về điều này vì một lý do. Rất hiếm khi cảnh báo này đơn giản nên được bỏ qua và thật dễ dàng để xử lý. Đây là cách thực hiện:

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

Hoặc chặt chẽ hơn (mặc dù khó đọc và không có người bảo vệ):

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

Giải trình

Điều đang diễn ra ở đây là bạn đang hỏi bộ điều khiển cho con trỏ hàm C cho phương thức tương ứng với bộ điều khiển. Tất cả đều NSObjectphản hồi methodForSelector:, nhưng bạn cũng có thể sử dụng class_getMethodImplementationtrong thời gian chạy Objective-C (hữu ích nếu bạn chỉ có một tham chiếu giao thức, như id<SomeProto>). Các con trỏ hàm này được gọi là IMPs và là typedefcác con trỏ hàm ed đơn giản ( id (*IMP)(id, SEL, ...)) ¹ . Điều này có thể gần với chữ ký phương thức thực tế của phương thức, nhưng sẽ không luôn luôn khớp chính xác.

Khi bạn đã có IMP, bạn cần truyền nó tới một con trỏ hàm bao gồm tất cả các chi tiết mà ARC cần (bao gồm cả hai đối số ẩn ẩn selfvà _cmdcủa mỗi lệnh gọi phương thức Objective-C). Điều này được xử lý trong dòng thứ ba ( (void *)phía bên tay phải chỉ cần cho trình biên dịch biết bạn đang làm gì và không tạo cảnh báo do các loại con trỏ không khớp).

Cuối cùng, bạn gọi con trỏ hàm ² .

Ví dụ phức tạp

Khi bộ chọn nhận đối số hoặc trả về giá trị, bạn sẽ phải thay đổi mọi thứ một chút:

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;

Lý do cảnh báo

Lý do cho cảnh báo này là với ARC, bộ thực thi cần biết phải làm gì với kết quả của phương thức bạn đang gọi. Kết quả có thể là bất cứ điều gì: void, int, char, NSString *, id,, vv ARC thường lấy thông tin này từ tiêu đề của các loại đối tượng bạn đang sử dụng. ³

Thực sự chỉ có 4 điều mà ARC sẽ xem xét cho giá trị trả về: ⁴

1. Loại bỏ qua phi vật thể ( void, int, vv)
2. Giữ lại giá trị đối tượng, sau đó giải phóng khi nó không còn được sử dụng (giả định tiêu chuẩn)
3. Giải phóng các giá trị đối tượng mới khi không còn được sử dụng (các phương thức trong init/ copygia đình hoặc được quy cho ns_returns_retained)
4. Không làm gì cả & giả sử giá trị đối tượng được trả về sẽ hợp lệ trong phạm vi cục bộ (cho đến khi phần lớn nhóm phát hành bên trong bị cạn kiệt, được quy cho ns_returns_autoreleased)

Cuộc gọi methodForSelector:giả định rằng giá trị trả về của phương thức mà nó gọi là một đối tượng, nhưng không giữ lại / giải phóng nó. Vì vậy, cuối cùng bạn có thể tạo ra một rò rỉ nếu đối tượng của bạn được cho là sẽ được phát hành như trong mục số 3 ở trên (nghĩa là phương thức bạn đang gọi trả về một đối tượng mới).

Đối với các bộ chọn bạn đang cố gắng gọi trả về voidhoặc các đối tượng khác, bạn có thể kích hoạt các tính năng của trình biên dịch để bỏ qua cảnh báo, nhưng nó có thể nguy hiểm. Tôi đã thấy Clang trải qua một vài lần lặp lại về cách nó xử lý các giá trị trả về không được gán cho các biến cục bộ. Không có lý do gì khi ARC được kích hoạt mà nó không thể giữ lại và giải phóng giá trị đối tượng được trả về methodForSelector:ngay cả khi bạn không muốn sử dụng nó. Từ quan điểm của nhà soạn nhạc, nó là một đối tượng. Điều đó có nghĩa là nếu phương thức bạn đang gọi,someMethod đang trả về một đối tượng không (bao gồm void), bạn có thể kết thúc bằng một giá trị con trỏ rác được giữ lại / giải phóng và sụp đổ.

Đối số bổ sung

Một xem xét là đây là cảnh báo tương tự sẽ xảy ra performSelector:withObject:và bạn có thể gặp phải các vấn đề tương tự mà không khai báo phương thức đó tiêu thụ tham số như thế nào. ARC cho phép khai báo các tham số đã tiêu thụ và nếu phương thức tiêu thụ tham số đó, cuối cùng bạn có thể sẽ gửi tin nhắn đến zombie và gặp sự cố. Có nhiều cách để giải quyết vấn đề này với việc đúc cầu, nhưng thực sự sẽ tốt hơn nếu chỉ sử dụng IMPphương pháp con trỏ hàm và hàm ở trên. Vì các tham số tiêu thụ hiếm khi là một vấn đề, điều này không có khả năng xuất hiện.

Bộ chọn tĩnh

Thật thú vị, trình biên dịch sẽ không phàn nàn về các bộ chọn được khai báo tĩnh:

[_controller performSelector:@selector(someMethod)];

Lý do cho điều này là bởi vì trình biên dịch thực sự có thể ghi lại tất cả các thông tin về bộ chọn và đối tượng trong quá trình biên dịch. Nó không cần phải đưa ra bất kỳ giả định về bất cứ điều gì. (Tôi đã kiểm tra điều này một năm trước bằng cách xem nguồn, nhưng không có tài liệu tham khảo ngay bây giờ.)

Ức chế

Khi cố gắng nghĩ về một tình huống mà việc ngăn chặn cảnh báo này là cần thiết và thiết kế mã tốt, tôi sẽ trở nên trống rỗng. Ai đó hãy chia sẻ nếu họ đã có kinh nghiệm trong đó việc tắt tiếng cảnh báo này là cần thiết (và những điều trên không xử lý mọi việc đúng cách).

Hơn

Có thể xây dựng một NSMethodInvocation để xử lý việc này, nhưng làm như vậy đòi hỏi phải gõ nhiều hơn và cũng chậm hơn, vì vậy có rất ít lý do để làm điều đó.

Lịch sử

Khi mà performSelector: họ phương thức lần đầu tiên được thêm vào Objective-C, ARC không tồn tại. Trong khi tạo ARC, Apple đã quyết định rằng nên tạo cảnh báo cho các phương thức này như một cách hướng dẫn các nhà phát triển sử dụng các phương tiện khác để xác định rõ cách xử lý bộ nhớ khi gửi tin nhắn tùy ý qua bộ chọn có tên. Trong Objective-C, các nhà phát triển có thể thực hiện điều này bằng cách sử dụng phôi kiểu C trên các con trỏ hàm thô.

Với sự ra đời của Swift, Apple đã ghi nhận performSelector:họ các phương pháp là "vốn không an toàn" và chúng không có sẵn cho Swift.

Theo thời gian, chúng ta đã thấy sự tiến triển này:

1. Phiên bản đầu của Objective-C cho phép performSelector: (quản lý bộ nhớ thủ công)
2. Objective-C với ARC cảnh báo việc sử dụng performSelector:
3. Swift không có quyền truy cập performSelector:và ghi lại các phương thức này là "vốn không an toàn"

Tuy nhiên, ý tưởng gửi tin nhắn dựa trên bộ chọn có tên không phải là một tính năng "vốn không an toàn". Ý tưởng này đã được sử dụng thành công trong một thời gian dài trong Objective-C cũng như nhiều ngôn ngữ lập trình khác.

¹ Tất cả các phương thức Objective-C có hai đối số ẩn selfvà _cmdđược thêm vào khi bạn gọi một phương thức.

² Gọi một NULLchức năng là không an toàn trong C. Bộ phận bảo vệ được sử dụng để kiểm tra sự hiện diện của bộ điều khiển đảm bảo rằng chúng ta có một đối tượng. Do đó, chúng tôi biết rằng chúng tôi sẽ nhận được IMPtừ methodForSelector:(mặc dù có thể _objc_msgForward, nhập vào hệ thống chuyển tiếp tin nhắn). Về cơ bản, với người bảo vệ tại chỗ, chúng tôi biết chúng tôi có một chức năng để gọi.

³ Trên thực tế, nó có thể nhận được thông tin sai nếu khai báo cho bạn các đối tượng idvà bạn không nhập tất cả các tiêu đề. Bạn có thể kết thúc với sự cố trong mã mà trình biên dịch cho là ổn. Điều này rất hiếm, nhưng có thể xảy ra. Thông thường, bạn sẽ chỉ nhận được một cảnh báo rằng nó không biết nên chọn chữ ký nào trong hai chữ ký phương thức.

⁴ Xem tài liệu tham khảo ARC về giá trị lợi nhuận giữ lại và giá trị trả về unretained để biết thêm chi tiết.

Trong trình biên dịch LLVM 3.0 trong Xcode 4.2, bạn có thể chặn cảnh báo như sau:

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

Nếu bạn đang gặp lỗi ở một số nơi và muốn sử dụng hệ thống macro C để ẩn các pragma, bạn có thể xác định một macro để dễ dàng loại bỏ cảnh báo hơn:

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

Bạn có thể sử dụng macro như thế này:

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

Nếu bạn cần kết quả của thông báo được thực hiện, bạn có thể làm điều này:

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

Tôi đoán về điều này là: vì trình chọn không xác định được trình biên dịch, ARC không thể thực thi quản lý bộ nhớ phù hợp.

Trong thực tế, có những lúc quản lý bộ nhớ được gắn với tên của phương thức theo một quy ước cụ thể. Cụ thể, tôi suy nghĩ của nhà xây dựng thuận tiện so với làm cho phương pháp; sự trở lại trước đây theo quy ước một đối tượng tự động; cái sau một đối tượng giữ lại. Quy ước dựa trên tên của bộ chọn, vì vậy nếu trình biên dịch không biết bộ chọn, thì nó không thể thực thi quy tắc quản lý bộ nhớ phù hợp.

Nếu điều này là chính xác, tôi nghĩ rằng bạn có thể sử dụng mã của mình một cách an toàn, miễn là bạn đảm bảo rằng mọi thứ đều ổn khi quản lý bộ nhớ (ví dụ: các phương thức của bạn không trả về các đối tượng mà chúng phân bổ).

Trong Cài đặt bản dựng dự án của bạn , bên dưới Cờ cảnh báo khác ( WARNING_CFLAGS), hãy thêm
-Wno-arc-performSelector-leaks

Bây giờ chỉ cần đảm bảo rằng bộ chọn bạn đang gọi không khiến đối tượng của bạn bị giữ lại hoặc sao chép.

Như một cách giải quyết cho đến khi trình biên dịch cho phép ghi đè cảnh báo, bạn có thể sử dụng thời gian chạy

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

thay vì

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

Bạn sẽ phải

#import <objc/message.h>

Để bỏ qua lỗi chỉ trong tệp có bộ chọn thực hiện, hãy thêm #pragma như sau:

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

Điều này sẽ bỏ qua cảnh báo trên dòng này, nhưng vẫn cho phép nó trong suốt phần còn lại của dự án của bạn.

Lạ nhưng đúng: nếu chấp nhận được (nghĩa là kết quả là không có giá trị và bạn không ngại để chu kỳ runloop một lần), hãy thêm độ trễ, ngay cả khi điều này bằng 0:

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

Điều này loại bỏ cảnh báo, có lẽ bởi vì nó trấn an trình biên dịch rằng không có đối tượng nào có thể được trả lại và bằng cách nào đó bị quản lý sai.

Đây là một macro cập nhật dựa trên câu trả lời ở trên. Điều này sẽ cho phép bạn bọc mã của bạn ngay cả với một tuyên bố trở lại.

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

Mã này không liên quan đến cờ trình biên dịch hoặc các cuộc gọi thời gian chạy trực tiếp:

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

NSInvocationcho phép nhiều đối số được đặt để không giống như performSelectorđiều này sẽ hoạt động trên bất kỳ phương thức nào.

Chà, rất nhiều câu trả lời ở đây, nhưng vì điều này hơi khác một chút, kết hợp một vài câu trả lời tôi nghĩ tôi đã đưa nó vào. Tôi đang sử dụng danh mục NSObject để kiểm tra để đảm bảo bộ chọn trả về khoảng trống và cũng loại bỏ trình biên dịch cảnh bá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

Vì lợi ích của hậu thế, tôi đã quyết định ném mũ vào vòng :)

Gần đây, tôi đã thấy ngày càng tái cấu trúc khỏi target/ selectormô hình, ủng hộ những thứ như giao thức, khối, v.v. Tuy nhiên, có một thay thế thả xuống performSelectormà tôi đã sử dụng một vài lần bây giờ:

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

Đây dường như là một sự thay thế sạch sẽ, an toàn ARC và gần như giống hệt nhau performSelectormà không cần phải quan tâm nhiều objc_msgSend().

Mặc dù vậy, tôi không biết nếu có một tương tự có sẵn trên iOS.

Câu trả lời của Matt Galloway về chủ đề này giải thích lý do:

Hãy xem xét những điều sau đây:

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

Bây giờ, làm thế nào ARC có thể biết rằng cái đầu tiên trả về một đối tượng có số giữ lại là 1 nhưng cái thứ hai trả về một đối tượng được tự động phát hành?

Có vẻ như nói chung là an toàn để chặn cảnh báo nếu bạn bỏ qua giá trị trả về. Tôi không chắc cách thực hành tốt nhất là gì nếu bạn thực sự cần lấy một đối tượng được giữ lại từ PerformanceSelector - ngoài "không làm điều đó".

@ c-road cung cấp liên kết đúng với mô tả vấn đề ở đây . Dưới đây bạn có thể xem ví dụ của tôi, khi PerformanceSelector gây rò rỉ bộ nhớ.

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

Phương pháp duy nhất, gây rò rỉ bộ nhớ trong ví dụ của tôi là CopyDummyWithLeak. Lý do là ARC không biết, copySelector trả về đối tượng được giữ lại.

Nếu bạn chạy Công cụ rò rỉ bộ nhớ, bạn có thể thấy hình ảnh sau: ... và không có rò rỉ bộ nhớ trong bất kỳ trường hợp nào khác:

Để làm cho macro của Scott Thompson chung chung hơn:

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

Sau đó sử dụng nó như thế này:

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

Đừng kìm nén cảnh báo!

Có không dưới 12 giải pháp thay thế để mày mò trình biên dịch.
Mặc dù bạn đang thông minh tại thời điểm thực hiện đầu tiên, một vài kỹ sư trên Trái đất có thể theo bước chân của bạn và mã này cuối cùng sẽ bị phá vỡ.

Tuyến đường an toàn:

Tất cả các giải pháp này sẽ hoạt động, với một số mức độ khác nhau từ mục đích ban đầu của bạn. Giả sử rằng paramcó thể nilnếu bạn rất mong muốn:

Tuyến đường an toàn, hành vi khái niệm tương tự:

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

Tuyến đường an toàn, hành vi hơi khác nhau:

(Xem phản hồi này )
Sử dụng bất kỳ chủ đề thay cho [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]];

Tuyến đường nguy hiểm

Yêu cầu một số loại trình biên dịch im lặng, bị ràng buộc để phá vỡ. Lưu ý rằng tại thời điểm hiện tại, nó đã phá vỡ trong Swift .

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

Bởi vì bạn đang sử dụng ARC, bạn phải sử dụng iOS 4.0 trở lên. Điều này có nghĩa là bạn có thể sử dụng các khối. Nếu thay vì ghi nhớ bộ chọn để thực hiện bạn thay vì lấy một khối, ARC sẽ có thể theo dõi tốt hơn những gì đang thực sự xảy ra và bạn sẽ không gặp rủi ro khi vô tình bị rò rỉ bộ nhớ.

Thay vì sử dụng cách tiếp cận khối, điều này cho tôi một số vấn đề:

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

Tôi sẽ sử dụng NSInvocation, như thế này:

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

Nếu bạn không cần phải vượt qua bất kỳ đối số, một cách giải quyết dễ dàng là sử dụng valueForKeyPath. Điều này thậm chí có thể trên một Classđối tượng.

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

Bạn cũng có thể sử dụng một giao thức ở đây. Vì vậy, tạo một giao thức như vậy:

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

Trong lớp của bạn cần gọi bộ chọn của bạn, sau đó bạn có @property.

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

Khi bạn cần gọi @selector(doSomethingWithObject:)một thể hiện của MyObject, hãy làm điều này:

[self.source doSomethingWithObject:object];