Saya mendapatkan peringatan berikut oleh kompiler ARC:

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

Inilah yang saya lakukan:

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

Mengapa saya mendapat peringatan ini? Saya mengerti kompiler tidak dapat memeriksa apakah pemilih ada atau tidak, tetapi mengapa hal itu menyebabkan kebocoran? Dan bagaimana saya bisa mengubah kode saya sehingga saya tidak mendapatkan peringatan ini lagi?

Larutan

Compiler memperingatkan tentang hal ini karena suatu alasan. Sangat jarang peringatan ini diabaikan begitu saja, dan mudah ditangani. Begini caranya:

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

Atau lebih singkatnya (meskipun sulit dibaca & tanpa penjaga):

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

Penjelasan

Apa yang terjadi di sini adalah Anda meminta controller untuk pointer fungsi C untuk metode yang sesuai dengan controller. Semua NSObjectmerespons methodForSelector:, tetapi Anda juga dapat menggunakan class_getMethodImplementationdalam runtime Objective-C (berguna jika Anda hanya memiliki referensi protokol, seperti id<SomeProto>). Pointer fungsi ini disebut IMPs, dan typedefpointer fungsi ed sederhana ( id (*IMP)(id, SEL, ...)) ¹ . Ini mungkin dekat dengan tanda tangan metode aktual dari metode ini, tetapi tidak akan selalu sama persis.

Setelah Anda memiliki IMP, Anda perlu melemparkannya ke pointer fungsi yang mencakup semua detail yang dibutuhkan ARC (termasuk dua argumen tersembunyi implisit selfdan _cmdsetiap panggilan metode Objective-C). Ini ditangani di baris ketiga ( (void *)di sebelah kanan hanya memberitahu kompiler bahwa Anda tahu apa yang Anda lakukan dan tidak menghasilkan peringatan karena jenis pointer tidak cocok).

Akhirnya, Anda memanggil penunjuk fungsi ² .

Contoh Kompleks

Saat pemilih mengambil argumen atau mengembalikan nilai, Anda harus mengubah sedikit hal:

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;

Alasan untuk Peringatan

Alasan untuk peringatan ini adalah bahwa dengan ARC, runtime perlu tahu apa yang harus dilakukan dengan hasil dari metode yang Anda panggil. Hasilnya bisa apa saja: void, int, char, NSString *, id, dll ARC biasanya mendapat informasi ini dari header dari jenis objek Anda bekerja dengan. ³

Sebenarnya hanya ada 4 hal yang akan dipertimbangkan ARC untuk nilai pengembalian: ⁴

1. Jenis mengabaikan non-object ( void, int, dll)
2. Pertahankan nilai objek, lalu lepaskan ketika tidak lagi digunakan (asumsi standar)
3. Lepaskan nilai objek baru ketika tidak lagi digunakan (metode dalam init/ copykeluarga atau dikaitkan dengan ns_returns_retained)
4. Jangan lakukan apa pun & asumsikan nilai objek yang dikembalikan akan valid dalam lingkup lokal (hingga kumpulan rilis terbanyak dikeringkan, dikaitkan dengan ns_returns_autoreleased)

Panggilan untuk methodForSelector:mengasumsikan bahwa nilai balik dari metode yang dipanggil adalah objek, tetapi tidak mempertahankan / melepaskannya. Jadi Anda bisa membuat kebocoran jika objek Anda seharusnya dirilis seperti pada # 3 di atas (yaitu, metode yang Anda panggil mengembalikan objek baru).

Untuk penyeleksi yang Anda coba panggil balik itu voidatau yang bukan objek, Anda dapat mengaktifkan fitur kompiler untuk mengabaikan peringatan, tetapi itu mungkin berbahaya. Saya telah melihat dentang pergi melalui beberapa iterasi bagaimana ia menangani nilai-nilai kembali yang tidak ditugaskan ke variabel lokal. Tidak ada alasan bahwa dengan ARC diaktifkan, ARC tidak dapat mempertahankan dan melepaskan nilai objek yang dikembalikan methodForSelector:meskipun Anda tidak ingin menggunakannya. Dari perspektif kompiler, itu adalah objek. Itu berarti bahwa jika metode yang Anda panggil,, someMethodmengembalikan non objek (termasuk void), Anda bisa berakhir dengan nilai penunjuk sampah dipertahankan / dirilis dan macet.

Argumen tambahan

Satu pertimbangan adalah bahwa ini adalah peringatan yang sama akan terjadi dengan performSelector:withObject:dan Anda bisa mengalami masalah yang sama dengan tidak menyatakan bagaimana metode itu mengkonsumsi parameter. ARC memungkinkan untuk mendeklarasikan parameter yang dikonsumsi , dan jika metode tersebut menggunakan parameter tersebut, Anda mungkin pada akhirnya akan mengirim pesan ke zombie dan crash. Ada beberapa cara untuk mengatasi hal ini dengan casting bridged, tetapi sebenarnya akan lebih baik untuk hanya menggunakan IMPmetodologi fungsi pointer di atas. Karena parameter yang dikonsumsi jarang menjadi masalah, ini tidak mungkin muncul.

Selektor Statis

Menariknya, kompiler tidak akan mengeluh tentang pemilih yang dinyatakan secara statis:

[_controller performSelector:@selector(someMethod)];

Alasannya adalah karena kompiler sebenarnya dapat merekam semua informasi tentang pemilih dan objek selama kompilasi. Tidak perlu membuat asumsi tentang apa pun. (Saya memeriksa ini setahun yang lalu dengan melihat sumbernya, tetapi tidak memiliki referensi sekarang.)

Penekanan

Dalam mencoba memikirkan situasi di mana penindasan terhadap peringatan ini akan diperlukan dan desain kode yang baik, saya hampir kosong. Seseorang tolong bagikan jika mereka memiliki pengalaman di mana membungkam peringatan ini diperlukan (dan di atas tidak menangani hal-hal dengan benar).

Lebih

Dimungkinkan untuk membangun dan NSMethodInvocationmenangani ini juga, tetapi melakukannya membutuhkan lebih banyak pengetikan dan juga lebih lambat, jadi ada sedikit alasan untuk melakukannya.

Sejarah

Ketika performSelector:keluarga metode pertama kali ditambahkan ke Objective-C, ARC tidak ada. Saat membuat ARC, Apple memutuskan bahwa peringatan harus dibuat untuk metode ini sebagai cara membimbing pengembang untuk menggunakan cara lain untuk secara eksplisit menentukan bagaimana memori harus ditangani ketika mengirim pesan sewenang-wenang melalui pemilih bernama. Di Objective-C, pengembang dapat melakukan ini dengan menggunakan gips gaya C pada pointer fungsi mentah.

Dengan diperkenalkannya Swift, Apple telah mendokumentasikan dalam performSelector:keluarga metode sebagai "inheren tidak aman" dan mereka tidak tersedia untuk Swift.

Seiring waktu, kami telah melihat perkembangan ini:

1. Versi awal Objective-C memungkinkan performSelector:(manajemen memori manual)
2. Objective-C dengan ARC memperingatkan untuk penggunaan performSelector:
3. Swift tidak memiliki akses ke performSelector:dan mendokumentasikan metode ini sebagai "secara inheren tidak aman"

Akan tetapi, gagasan untuk mengirim pesan berdasarkan pemilih yang dinamai bukan fitur yang "pada dasarnya tidak aman". Ide ini telah berhasil digunakan sejak lama di Objective-C dan juga banyak bahasa pemrograman lainnya.

¹ Semua metode Objective-C memiliki dua argumen tersembunyi, selfdan _cmdyang secara implisit ditambahkan ketika Anda memanggil metode.

² Memanggil NULLfungsi tidak aman di C. Penjaga yang digunakan untuk memeriksa keberadaan pengontrol memastikan bahwa kami memiliki objek. Karena itu kami tahu kami akan mendapatkan IMPdari methodForSelector:(meskipun mungkin _objc_msgForward, masuk ke sistem penerusan pesan). Pada dasarnya, dengan adanya penjaga, kita tahu bahwa kita memiliki fungsi untuk memanggil.

³ Sebenarnya, itu mungkin untuk mendapatkan info yang salah jika menyatakan objek sebagai idAnda dan Anda tidak mengimpor semua header. Anda bisa berakhir dengan crash dalam kode yang menurut kompiler baik-baik saja. Ini sangat jarang, tetapi bisa terjadi. Biasanya Anda hanya akan mendapat peringatan bahwa ia tidak tahu mana dari dua tanda tangan metode yang dapat dipilih.

⁴ Lihat referensi ARC pada nilai retur dan nilai retur tanpa retret untuk detail lebih lanjut.

Dalam kompiler LLVM 3.0 di Xcode 4.2 Anda dapat menekan peringatan sebagai berikut:

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

Jika Anda mendapatkan kesalahan di beberapa tempat, dan ingin menggunakan sistem makro C untuk menyembunyikan pragma, Anda bisa mendefinisikan makro untuk membuatnya lebih mudah untuk menekan peringatan:

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

Anda dapat menggunakan makro seperti ini:

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

Jika Anda membutuhkan hasil dari pesan yang dilakukan, Anda dapat melakukan ini:

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

Dugaan saya tentang ini adalah ini: karena pemilih tidak dikenal oleh kompiler, ARC tidak dapat menerapkan manajemen memori yang tepat.

Bahkan, ada kalanya manajemen memori dikaitkan dengan nama metode dengan konvensi tertentu. Secara khusus, saya sedang memikirkan konstruktor kenyamanan versus membuat metode; mantan mengembalikan dengan konvensi objek autoreleased; yang terakhir merupakan objek yang dipertahankan. Konvensi didasarkan pada nama-nama pemilih, jadi jika kompiler tidak mengetahui pemilih, maka tidak dapat menegakkan aturan manajemen memori yang tepat.

Jika ini benar, saya pikir Anda dapat menggunakan kode Anda dengan aman, asalkan Anda memastikan semuanya baik-baik saja untuk manajemen memori (misalnya, bahwa metode Anda tidak mengembalikan objek yang mereka alokasikan).

Di Pengaturan Bangun proyek Anda , di bawah Bendera Peringatan Lainnya ( WARNING_CFLAGS), tambahkan
-Wno-arc-performSelector-leaks

Sekarang pastikan pemilih yang Anda panggil tidak menyebabkan objek Anda dipertahankan atau disalin.

Sebagai solusi hingga kompiler memungkinkan mengganti peringatan, Anda dapat menggunakan runtime

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

dari pada

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

Anda harus melakukannya

#import <objc/message.h>

Untuk mengabaikan kesalahan hanya di file dengan selector perform, tambahkan #pragma sebagai berikut:

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

Ini akan mengabaikan peringatan pada baris ini, tetapi masih membiarkannya sepanjang sisa proyek Anda.

Aneh tapi benar: jika dapat diterima (yaitu hasilnya batal dan Anda tidak keberatan membiarkan siklus runloop satu kali), tambahkan penundaan, bahkan jika ini nol:

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

Ini menghilangkan peringatan, mungkin karena meyakinkan kompiler bahwa tidak ada objek yang dapat dikembalikan dan entah bagaimana salah kelola.

Berikut ini adalah makro yang diperbarui berdasarkan jawaban yang diberikan di atas. Ini harus memungkinkan Anda untuk membungkus kode Anda bahkan dengan pernyataan pengembalian.

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

Kode ini tidak melibatkan flag compiler atau panggilan runtime langsung:

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

NSInvocationmemungkinkan beberapa argumen diset sehingga tidak seperti performSelectorini akan bekerja pada metode apa pun

Yah, banyak jawaban di sini, tetapi karena ini sedikit berbeda, menggabungkan beberapa jawaban saya pikir saya akan memasukkannya. Saya menggunakan kategori NSObject yang memeriksa untuk memastikan pemilih kembali batal, dan juga menekan kompiler peringatan.

#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

Demi anak cucu, saya telah memutuskan untuk melemparkan topi saya ke atas ring :)

Baru-baru ini saya telah melihat semakin banyak restrukturisasi jauh dari target/ selectorparadigma, mendukung hal-hal seperti protokol, blok, dll Namun, ada satu drop-in pengganti performSelectorbahwa saya telah digunakan beberapa kali sekarang:

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

Ini tampaknya menjadi pengganti yang bersih, aman-ARC, dan hampir identik untuk performSelectortanpa harus banyak peduli dengan objc_msgSend().

Padahal, saya tidak tahu apakah ada analog yang tersedia di iOS.

Jawaban Matt Galloway pada utas ini menjelaskan alasannya:

Pertimbangkan yang berikut ini:

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

Sekarang, bagaimana ARC bisa tahu bahwa yang pertama mengembalikan objek dengan jumlah tetap 1 tetapi yang kedua mengembalikan objek yang autoreleased?

Tampaknya aman untuk menekan peringatan jika Anda mengabaikan nilai pengembalian. Saya tidak yakin apa praktik terbaik adalah jika Anda benar-benar perlu mendapatkan objek yang ditahan dari performSelector - selain "jangan lakukan itu".

@ c-road menyediakan tautan yang tepat dengan deskripsi masalah di sini . Di bawah ini Anda dapat melihat contoh saya, ketika performSelector menyebabkan kebocoran memori.

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

Satu-satunya metode, yang menyebabkan kebocoran memori dalam contoh saya adalah CopyDummyWithLeak. Alasannya adalah bahwa ARC tidak tahu, bahwa copySelector mengembalikan objek yang dipertahankan.

Jika Anda menjalankan Memory Leak Tool, Anda dapat melihat gambar berikut: ... dan tidak ada kebocoran memori dalam hal lain:

Untuk menjadikan makro Scott Thompson lebih umum:

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

Kemudian gunakan seperti ini:

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

Jangan menekan peringatan!

Ada tidak kurang dari 12 solusi alternatif untuk bermain-main dengan kompiler.
Ketika Anda menjadi pintar pada saat implementasi pertama, beberapa insinyur di Bumi dapat mengikuti jejak Anda, dan kode ini pada akhirnya akan rusak.

Rute Aman:

Semua solusi ini akan berfungsi, dengan beberapa tingkat variasi dari niat awal Anda. Anggaplah itu parambisanil jika Anda menginginkannya:

Rute aman, perilaku konseptual yang sama:

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

Rute aman, perilaku yang sedikit berbeda:

(Lihat respons ini )
Gunakan utas apa pun sebagai pengganti [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]];

Rute Berbahaya

Membutuhkan beberapa jenis kompiler yang dibungkam, yang pasti akan rusak. Perhatikan bahwa pada saat ini, ia melakukan istirahat di Swift .

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

Karena Anda menggunakan ARC, Anda harus menggunakan iOS 4.0 atau yang lebih baru. Ini artinya Anda bisa menggunakan blok. Jika alih-alih mengingat pemilih untuk melakukan Anda alih-alih mengambil blok, ARC akan dapat melacak dengan lebih baik apa yang sebenarnya terjadi dan Anda tidak perlu menjalankan risiko secara tidak sengaja memasukkan kebocoran memori.

Alih-alih menggunakan pendekatan blok, yang memberi saya beberapa masalah:

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

Saya akan menggunakan NSInvocation, seperti ini:

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

Jika Anda tidak perlu memberikan argumen apa pun, penyelesaian yang mudah adalah dengan menggunakan valueForKeyPath. Ini bahkan mungkin terjadi pada Classobjek.

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

Anda juga bisa menggunakan protokol di sini. Jadi, buat protokol seperti ini:

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

Di kelas Anda yang perlu memanggil pemilih Anda, Anda kemudian memiliki @ properti.

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

Ketika Anda perlu memanggil @selector(doSomethingWithObject:)instance MyObject, lakukan ini:

[self.source doSomethingWithObject:object];