Mantieni il ciclo su `self` con blocchi

Temo che questa domanda sia piuttosto semplice, ma penso che sia pertinente per molti programmatori di Objective-C che stanno entrando in blocchi.

Quello che ho sentito è che, poiché i blocchi acquisiscono variabili locali a cui fanno riferimento al loro interno come constcopie, l'utilizzo selfall'interno di un blocco può comportare un ciclo di mantenimento, nel caso in cui quel blocco venga copiato. Quindi, dovremmo usare __blockper forzare il blocco a gestire direttamente selfinvece di averlo copiato.

__block typeof(self) bself = self;
[someObject messageWithBlock:^{ [bself doSomething]; }];

invece di solo

[someObject messageWithBlock:^{ [self doSomething]; }];

Quello che mi piacerebbe sapere è il seguente: se questo è vero, c'è un modo per evitare la bruttezza (oltre all'utilizzo di GC)?

A rigor di termini, il fatto che si tratti di una copia const non ha nulla a che fare con questo problema. I blocchi manterranno tutti i valori obj-c che vengono acquisiti quando vengono creati. Accade solo che la soluzione alternativa per il problema const-copy sia identica alla soluzione alternativa per il problema di conservazione; vale a dire, usando il__block classe di archiviazione per la variabile.

In ogni caso, per rispondere alla tua domanda, qui non c'è vera alternativa. Se stai progettando la tua API basata su blocco e ha senso farlo, potresti far passare il valore al bloccoself in come argomento. Sfortunatamente, questo non ha senso per la maggior parte delle API.

Nota che fare riferimento a un ivar ha lo stesso identico problema. Se devi fare riferimento a un ivar nel tuo blocco, usa invece una proprietà o usa bself->ivar.

Addendum: durante la compilazione come ARC, __blocknon interrompe più i cicli di conservazione. Se stai compilando per ARC, devi usare__weak o __unsafe_unretainedinvece.

Usa solo:

__weak id weakSelf = self;

[someObject someMethodWithBlock:^{
    [weakSelf someOtherMethod];
}];

Per ulteriori informazioni: WWDC 2011 - Blocks and Grand Central Dispatch in Practice .

https://developer.apple.com/videos/wwdc/2011/?id=308

Nota: se non funziona puoi provare

__weak typeof(self)weakSelf = self;

Questo potrebbe essere ovvio, ma devi solo fare il brutto self alias quando sai che otterrai un ciclo di mantenimento. Se il blocco è solo una cosa a colpo singolo, penso che puoi tranquillamente ignorare il mantenimento self. Il brutto caso è quando hai il blocco come interfaccia di callback, per esempio. Come qui:

typedef void (^BufferCallback)(FullBuffer* buffer);

@interface AudioProcessor : NSObject {…}
@property(copy) BufferCallback bufferHandler;
@end

@implementation AudioProcessor

- (id) init {
    …
    [self setBufferCallback:^(FullBuffer* buffer) {
        [self whatever];
    }];
    …
}

Qui l'API non ha molto senso, ma avrebbe senso quando si comunica con una superclasse, ad esempio. Conserviamo il gestore buffer, il gestore buffer ci mantiene. Confronta con qualcosa del genere:

typedef void (^Callback)(void);

@interface VideoEncoder : NSObject {…}
- (void) encodeVideoAndCall: (Callback) block;
@end

@interface Foo : NSObject {…}
@property(retain) VideoEncoder *encoder;
@end

@implementation Foo
- (void) somewhere {
    [encoder encodeVideoAndCall:^{
        [self doSomething];
    }];
}

In queste situazioni non faccio l' selfaliasing. Si ottiene un ciclo di mantenimento, ma l'operazione è di breve durata e alla fine il blocco uscirà dalla memoria, interrompendo il ciclo. Ma la mia esperienza con i blocchi è molto piccola e potrebbe essere che l' selfaliasing sia una buona pratica a lungo termine.

Pubblicare un'altra risposta perché questo è stato un problema anche per me. Inizialmente pensavo di dover usare blockSelf ovunque ci fosse un riferimento personale all'interno di un blocco. Questo non è il caso, è solo quando l'oggetto stesso ha un blocco al suo interno. E infatti, se usi blockSelf in questi casi, l'oggetto può essere deallocato prima di ottenere il risultato dal blocco e poi si arresterà in modo anomalo quando proverà a chiamarlo, quindi chiaramente vuoi che il sé venga mantenuto fino alla risposta ritorna.

Il primo caso dimostra quando si verificherà un ciclo di mantenimento perché contiene un blocco a cui fa riferimento il blocco:

#import <Foundation/Foundation.h>

typedef void (^MyBlock)(void);

@interface ContainsBlock : NSObject 

@property (nonatomic, copy) MyBlock block;

- (void)callblock;

@end 

@implementation ContainsBlock
@synthesize block = _block;

- (id)init {
    if ((self = [super init])) {

        //__block ContainsBlock *blockSelf = self; // to fix use this.
        self.block = ^{
                NSLog(@"object is %@", self); // self retain cycle
            };
    }
    return self;
}

- (void)dealloc {
    self.block = nil;
    NSLog (@"ContainsBlock"); // never called.
    [super dealloc];
} 

- (void)callblock {
    self.block();
} 

@end 

 int main() {
    ContainsBlock *leaks = [[ContainsBlock alloc] init];
    [leaks callblock];
    [leaks release];
}

Non hai bisogno di blockSelf nel secondo caso perché l'oggetto chiamante non ha un blocco che causerà un ciclo di mantenimento quando fai riferimento a self:

#import <Foundation/Foundation.h>

typedef void (^MyBlock)(void);

@interface BlockCallingObject : NSObject 
@property (copy, nonatomic) MyBlock block;
@end

@implementation BlockCallingObject 
@synthesize block = _block;

- (void)dealloc {
    self.block = nil;
    NSLog(@"BlockCallingObject dealloc");
    [super dealloc];
} 

- (void)callblock {
    self.block();
} 
@end

@interface ObjectCallingBlockCallingObject : NSObject 
@end

@implementation ObjectCallingBlockCallingObject 

- (void)doneblock {
    NSLog(@"block call complete");
}

- (void)dealloc {
    NSLog(@"ObjectCallingBlockCallingObject dealloc");
    [super dealloc];
} 

- (id)init {
    if ((self = [super init])) {

        BlockCallingObject *myobj = [[BlockCallingObject alloc] init];
        myobj.block = ^() {
            [self doneblock]; // block in different object than this object, no retain cycle
        };
        [myobj callblock];
        [myobj release];
    }
    return self;
}
@end

int main() {

    ObjectCallingBlockCallingObject *myObj = [[ObjectCallingBlockCallingObject alloc] init];
    [myObj release];

    return 0;
} 

Ricorda anche che possono verificarsi cicli di mantenimento se il tuo blocco fa riferimento a un altro oggetto che quindi mantieneself .

Non sono sicuro che Garbage Collection possa aiutare in questi cicli di conservazione. Se l'oggetto che conserva il blocco (che chiamerò l'oggetto server) sopravvive self(l'oggetto client), il riferimento aself all'interno del blocco non sarà considerato ciclico fino al rilascio dell'oggetto di conservazione stesso. Se l'oggetto server sopravvive di gran lunga ai suoi client, potresti avere una significativa perdita di memoria.

Dal momento che non esistono soluzioni pulite, consiglierei le seguenti soluzioni alternative. Sentiti libero di sceglierne uno o più per risolvere il problema.

• Utilizzare i blocchi solo per il completamento e non per eventi a tempo indeterminato. Ad esempio, utilizzare i blocchi per metodi simili doSomethingAndWhenDoneExecuteThisBlock:e non per metodi similisetNotificationHandlerBlock: . I blocchi utilizzati per il completamento hanno una durata definita e devono essere rilasciati dagli oggetti server dopo essere stati valutati. Questo impedisce al ciclo di mantenimento di sopravvivere troppo a lungo anche se si verifica.
• Fai quella danza di riferimento debole che hai descritto.
• Fornire un metodo per ripulire l'oggetto prima che venga rilasciato, che "disconnetta" l'oggetto dagli oggetti server che potrebbero contenere riferimenti ad esso; e chiama questo metodo prima di chiamare il rilascio sull'oggetto. Mentre questo metodo è perfetto se il tuo oggetto ha un solo client (o è un singleton in un certo contesto), ma si romperà se ha più client. Fondamentalmente stai sconfiggendo il meccanismo di conteggio del mantenimento qui; questo è simile a chiamare deallocinvece di release.

Se stai scrivendo un oggetto server, prendi gli argomenti a blocchi solo per il completamento. Non accettare argomenti a blocchi per callback, come setEventHandlerBlock:. Invece, ripiega sul modello delegato classico: crea un protocollo formale e pubblicizza un setEventDelegate:metodo. Non conservare il delegato. Se non si desidera nemmeno creare un protocollo formale, accettare un selettore come callback delegato.

E, infine, questo schema dovrebbe suonare allarmi:

- (vuoto) dealloc {
    [myServerObject releaseCallbackBlocksForObject: self];
    ...
}

Se stai provando a sganciare blocchi che potrebbero riferirsi selfdall'interno dealloc, sei già nei guai. deallocpotrebbe non essere mai chiamato a causa del ciclo di conservazione causato dai riferimenti nel blocco, il che significa che il tuo oggetto semplicemente perderà fino a quando l'oggetto server non viene deallocato.

__block __unsafe_unretainedi modificatori suggeriti nel post di Kevin possono causare un'eccezione di accesso errato in caso di blocco eseguito in un thread diverso. È meglio usare solo il modificatore __block per la variabile temp e renderlo nullo dopo l'uso.

__block SomeType* this = self;
[someObject messageWithBlock:^{
  [this doSomething]; // here would be BAD_ACCESS in case of __unsafe_unretained with
                      //  multithreading and self was already released
  this = nil;
}];

Puoi usare la libreria libextobjc. È abbastanza popolare, ad esempio viene utilizzato in ReactiveCocoa. https://github.com/jspahrsummers/libextobjc

Fornisce 2 macro @weakify e @strongify, quindi puoi avere:

@weakify(self)
[someObject messageWithBlock:^{
   @strongify(self)
   [self doSomething]; 
}];

Questo impedisce un riferimento forte diretto, quindi non entriamo in un ciclo di mantenimento verso se stessi. Inoltre, impedisce a se stesso di azzerarsi a metà, ma riduce ancora correttamente il conteggio dei ritardi. Altro in questo link: http://aceontech.com/objc/ios/2014/01/10/weakify-a-more-elegant-solution-to-weakself.html

Cosa ne pensi di questo?

- (void) foo {
     __weak __block me = self;

     myBlock = ^ {
        [[me someProp] someMessage];
     }
     ...
 }

Non ricevo più l'avviso del compilatore.

Blocco: si verificherà un ciclo di mantenimento perché contiene un blocco a cui fa riferimento il blocco; Se si effettua la copia di blocco e si utilizza una variabile membro, self manterrà.