Passare sempre il riferimento debole di sé nel blocco in ARC?

Sono un po 'confuso sull'uso dei blocchi in Objective-C. Attualmente uso ARC e ho un sacco di blocchi nella mia app, al momento mi riferisco sempre selfinvece al suo debole riferimento. Potrebbe essere questa la causa di questi blocchi che trattengono selfe impediscono che venga distribuito? La domanda è: dovrei sempre usare un weakriferimento di selfin un blocco?

-(void)handleNewerData:(NSArray *)arr
{
    ProcessOperation *operation =
    [[ProcessOperation alloc] initWithDataToProcess:arr
                                         completion:^(NSMutableArray *rows) {
        dispatch_async(dispatch_get_main_queue(), ^{
            [self updateFeed:arr rows:rows];
        });
    }];
    [dataProcessQueue addOperation:operation];
}

ProcessOperation.h

@interface ProcessOperation : NSOperation
{
    NSMutableArray *dataArr;
    NSMutableArray *rowHeightsArr;
    void (^callback)(NSMutableArray *rows);
}

ProcessOperation.m

-(id)initWithDataToProcess:(NSArray *)data completion:(void (^)(NSMutableArray *rows))cb{

    if(self =[super init]){
        dataArr = [NSMutableArray arrayWithArray:data];
        rowHeightsArr = [NSMutableArray new];
        callback = cb;
    }
    return self;
}

- (void)main {
    @autoreleasepool {
        ...
        callback(rowHeightsArr);
    }
}

Aiuta a non concentrarsi sulla parte strongo weaksulla discussione. Concentrati invece sulla parte del ciclo .

Un ciclo di mantenimento è un ciclo che si verifica quando l'oggetto A conserva l'oggetto B e l' oggetto B conserva l'oggetto A. In quella situazione, se uno degli oggetti viene rilasciato:

• L'oggetto A non verrà deallocato perché l'oggetto B contiene un riferimento ad esso.
• Ma l'oggetto B non sarà mai deallocato fintanto che l'oggetto A avrà un riferimento ad esso.
• Ma l'oggetto A non verrà mai deallocato perché l'oggetto B contiene un riferimento ad esso.
• verso l'infinito

Pertanto, questi due oggetti rimarranno solo nella memoria per tutta la durata del programma, anche se dovrebbero, se tutto funzionasse correttamente, essere deallocato.

Quindi, ciò di cui siamo preoccupati sono i cicli di mantenimento , e non c'è nulla sui blocchi in sé e per sé che creano questi cicli. Questo non è un problema, ad esempio:

[myArray enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop){
   [self doSomethingWithObject:obj];
}];

Il blocco mantiene self, ma selfnon mantiene il blocco. Se l'uno o l'altro viene rilasciato, non viene creato alcun ciclo e tutto viene deallocato come dovrebbe.

Dove ti trovi nei guai è qualcosa di simile:

//In the interface:
@property (strong) void(^myBlock)(id obj, NSUInteger idx, BOOL *stop);

//In the implementation:
[self setMyBlock:^(id obj, NSUInteger idx, BOOL *stop) {
  [self doSomethingWithObj:obj];     
}];

Ora, il tuo oggetto ( self) ha un strongriferimento esplicito al blocco. E il blocco ha un forte riferimento implicito a self. Questo è un ciclo, e ora nessuno dei due oggetti verrà deallocato correttamente.

Perché, in una situazione come questa, self per definizione ha già un strongriferimento al blocco, di solito è più facile risolverlo facendo un riferimento esplicitamente debole selfper il blocco da usare:

__weak MyObject *weakSelf = self;
[self setMyBlock:^(id obj, NSUInteger idx, BOOL *stop) {
  [weakSelf doSomethingWithObj:obj];     
}];

Ma questo non dovrebbe essere lo schema predefinito che segui quando hai a che fare con blocchi che chiamano self! Questo dovrebbe essere usato solo per interrompere quello che altrimenti sarebbe un ciclo di mantenimento tra sé e il blocco. Se dovessi adottare questo modello ovunque, rischieresti di passare un blocco a qualcosa che è stato eseguito dopo che è selfstato deallocato.

//SUSPICIOUS EXAMPLE:
__weak MyObject *weakSelf = self;
[[SomeOtherObject alloc] initWithCompletion:^{
  //By the time this gets called, "weakSelf" might be nil because it's not retained!
  [weakSelf doSomething];
}];

Non è necessario utilizzare sempre un riferimento debole. Se il tuo blocco non viene mantenuto, ma eseguito e quindi scartato, puoi catturare fortemente te stesso, poiché non creerà un ciclo di mantenimento. In alcuni casi, si desidera persino che il blocco mantenga il sé fino al completamento del blocco in modo che non si sposti prematuramente. Se, tuttavia, catturi fortemente il blocco e, all'interno di te stesso acquisisci, creerà un ciclo di mantenimento.

Sono totalmente d'accordo con @jemmons:

Ma questo non dovrebbe essere lo schema predefinito che segui quando hai a che fare con blocchi che chiamano sé! Questo dovrebbe essere usato solo per interrompere quello che altrimenti sarebbe un ciclo di mantenimento tra sé e il blocco. Se dovessi adottare questo modello ovunque, rischieresti di passare un blocco a qualcosa che è stato eseguito dopo che il sé è stato deallocato.

//SUSPICIOUS EXAMPLE:
__weak MyObject *weakSelf = self;
[[SomeOtherObject alloc] initWithCompletion:^{
  //By the time this gets called, "weakSelf" might be nil because it's not  retained!
  [weakSelf doSomething];
}];

Per ovviare a questo problema si può definire un forte riferimento weakSelfall'interno del blocco:

__weak MyObject *weakSelf = self;
[[SomeOtherObject alloc] initWithCompletion:^{
  MyObject *strongSelf = weakSelf;
  [strongSelf doSomething];
}];

Come sottolinea Leo, il codice che hai aggiunto alla tua domanda non suggerirebbe un forte ciclo di riferimento (ovvero ciclo di mantenimento). Un problema relativo all'operazione che potrebbe causare un forte ciclo di riferimento sarebbe se l'operazione non viene rilasciata. Mentre lo snippet di codice suggerisce che non hai definito la tua operazione come concorrente, ma se lo hai, non verrebbe rilasciata se non hai mai pubblicato isFinished, o se avessi dipendenze circolari o qualcosa del genere. E se l'operazione non viene rilasciata, neanche il controller di visualizzazione verrà rilasciato. Suggerirei di aggiungere un punto di interruzione o NSLognel deallocmetodo dell'operazione e confermare che viene chiamato.

Tu hai detto:

Capisco il concetto di cicli di mantenimento, ma non sono del tutto sicuro di cosa accada in blocchi, quindi questo mi confonde un po '

I problemi del ciclo di conservazione (ciclo di riferimento forte) che si verificano con i blocchi sono proprio come i problemi del ciclo di conservazione con cui si ha familiarità. Un blocco manterrà riferimenti forti a tutti gli oggetti che compaiono all'interno del blocco e non rilascerà quei riferimenti forti fino a quando il blocco stesso non viene rilasciato. Pertanto, se i riferimenti di blocco self, o anche solo riferimenti a una variabile di istanza di self, manterranno un forte riferimento a sé, che non viene risolto fino al rilascio del blocco (o in questo caso, fino al NSOperationrilascio della sottoclasse.

Per ulteriori informazioni, consultare la sezione Evitare cicli di riferimento forti durante l'acquisizione di sé del documento Programmazione con Objective-C: Lavorare con i blocchi .

Se il tuo controller di visualizzazione non viene ancora rilasciato, devi semplicemente identificare dove risiede il riferimento sicuro non risolto (supponendo che tu abbia confermato che NSOperationsta per essere deallocato). Un esempio comune è l'uso di una ripetizione NSTimer. O qualche delegateoggetto personalizzato o altro che erroneamente mantiene un strongriferimento. Spesso puoi usare gli strumenti per rintracciare dove gli oggetti ottengono i loro riferimenti forti, ad esempio:

O in Xcode 5:

Alcune spiegazioni ignorano una condizione relativa al ciclo di mantenimento [Se un gruppo di oggetti è collegato da un cerchio di relazioni forti, si mantengono reciprocamente in vita anche se non ci sono riferimenti forti al di fuori del gruppo.] Per ulteriori informazioni, leggere il documento

Ecco come puoi usare il sé all'interno del blocco:

// chiamata del blocco

 NSString *returnedText= checkIfOutsideMethodIsCalled(self);

NSString* (^checkIfOutsideMethodIsCalled)(*)=^NSString*(id obj)
{
             [obj MethodNameYouWantToCall]; // this is how it will call the object 
            return @"Called";


};