Retener el ciclo en `self` con bloques

Me temo que esta pregunta es bastante básica, pero creo que es relevante para muchos programadores de Objective-C que se están metiendo en bloques.

Lo que he escuchado es que, dado que los bloques capturan variables locales a las que se hace referencia como constcopias, el uso selfdentro de un bloque puede dar como resultado un ciclo de retención, en caso de que ese bloque se copie. Por lo tanto, se supone que debemos usar __blockpara obligar al bloque a tratar directamente en selflugar de copiarlo.

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

en lugar de solo

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

Lo que me gustaría saber es lo siguiente: si esto es cierto, ¿hay alguna manera de evitar la fealdad (aparte de usar GC)?

Estrictamente hablando, el hecho de que sea una copia constante no tiene nada que ver con este problema. Los bloques retendrán cualquier valor obj-c que se capture cuando se creen. Sucede que la solución para el problema de copia constante es idéntica a la solución para el problema de retención; a saber, usar la __blockclase de almacenamiento para la variable.

En cualquier caso, para responder a su pregunta, no hay una alternativa real aquí. Si está diseñando su propia API basada en bloques, y tiene sentido hacerlo, puede hacer que el bloque pase el valor de selfin como argumento. Desafortunadamente, esto no tiene sentido para la mayoría de las API.

Tenga en cuenta que hacer referencia a un ivar tiene exactamente el mismo problema. Si necesita hacer referencia a un ivar en su bloque, use una propiedad en su lugar o use bself->ivar.

Anexo: Al compilar como ARC, __blockya no interrumpe los ciclos de retención. Si está compilando para ARC, debe usar __weako en su __unsafe_unretainedlugar.

Solo usa:

__weak id weakSelf = self;

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

Para más información: WWDC 2011 - Bloques y Grand Central Dispatch en la práctica .

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

Nota: si eso no funciona, puedes probar

__weak typeof(self)weakSelf = self;

Esto puede ser obvio, pero solo tiene que hacer el selfalias feo cuando sabe que obtendrá un ciclo de retención. Si el bloqueo es solo de una sola vez, creo que puede ignorar con seguridad la retención self. El mal caso es cuando tiene el bloque como interfaz de devolución de llamada, por ejemplo. Como aquí:

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

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

@implementation AudioProcessor

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

Aquí la API no tiene mucho sentido, pero tendría sentido cuando se comunica con una superclase, por ejemplo. Retenemos el controlador de búfer, el controlador de búfer nos retiene. Compare con algo como esto:

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

En estas situaciones no hago el selfaliasing. Obtendrá un ciclo de retención, pero la operación es de corta duración y el bloque eventualmente se quedará sin memoria, rompiendo el ciclo. Pero mi experiencia con los bloques es muy pequeña y podría ser que el selfalias salga como una mejor práctica a largo plazo.

Publicar otra respuesta porque esto también fue un problema para mí. Originalmente pensé que tenía que usar blockSelf en cualquier lugar donde hubiera una autorreferencia dentro de un bloque. Este no es el caso, es solo cuando el objeto en sí tiene un bloque. Y, de hecho, si usa blockSelf en estos casos, el objeto puede ser desasignado antes de recuperar el resultado del bloque y luego se bloqueará cuando intente llamarlo, por lo que claramente desea que se retenga hasta la respuesta Vuelve.

El primer caso demuestra cuándo ocurrirá un ciclo de retención porque contiene un bloque al que se hace referencia en el bloque:

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

No necesita blockSelf en el segundo caso porque el objeto que realiza la llamada no tiene un bloque que causará un ciclo de retención cuando haga referencia 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;
} 

Recuerde también que los ciclos de retención pueden ocurrir si su bloqueo se refiere a otro objeto que luego retieneself .

No estoy seguro de que la recolección de basura pueda ayudar en estos ciclos de retención. Si el objeto que retiene el bloque (que llamaré el objeto del servidor) sobrevive self(el objeto del cliente), la referencia aself interior del bloque no se considerará cíclica hasta que se libere el objeto de retención. Si el objeto del servidor supera a sus clientes, es posible que tenga una pérdida de memoria significativa.

Como no hay soluciones limpias, recomendaría las siguientes soluciones. Siéntase libre de elegir uno o más de ellos para solucionar su problema.

• Use bloques solo para completar , y no para eventos abiertos. Por ejemplo, use bloques para métodos como doSomethingAndWhenDoneExecuteThisBlock:, y no métodos como setNotificationHandlerBlock:. Los bloques utilizados para la finalización tienen un final definitivo de vida útil, y los objetos del servidor deben liberarlos después de evaluarlos. Esto evita que el ciclo de retención viva demasiado tiempo, incluso si ocurre.
• Haz ese baile de referencia débil que describiste.
• Proporcione un método para limpiar su objeto antes de liberarlo, que "desconecta" el objeto de los objetos del servidor que pueden contener referencias a él; y llame a este método antes de llamar a release en el objeto. Si bien este método está perfectamente bien si su objeto solo tiene un cliente (o es un singleton dentro de algún contexto), pero se descompondrá si tiene varios clientes. Básicamente estás derrotando el mecanismo de conteo de retención aquí; Esto es similar a llamar en dealloclugar de release.

Si está escribiendo un objeto de servidor, tome argumentos de bloque solo para completar. No acepte argumentos de bloque para devoluciones de llamada, como setEventHandlerBlock:. En cambio, recurra al patrón de delegado clásico: cree un protocolo formal y anuncie un setEventDelegate:método. No retener al delegado. Si ni siquiera desea crear un protocolo formal, acepte un selector como devolución de llamada delegada.

Y, por último, este patrón debería hacer sonar las alarmas:

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

Si está tratando de desenganchar bloques que pueden referirse selfdesde adentro dealloc, ya está en problemas. deallocEs posible que nunca se llame debido al ciclo de retención causado por las referencias en el bloque, lo que significa que su objeto simplemente se filtrará hasta que el objeto del servidor se desasigne.

__block __unsafe_unretainedlos modificadores sugeridos en la publicación de Kevin pueden causar una excepción de acceso incorrecto en caso de que el bloque se ejecute en un hilo diferente. Es mejor usar solo el modificador __block para la variable temporal y hacerlo nulo después del 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;
}];

Puede usar la biblioteca libextobjc. Es bastante popular, se usa en ReactiveCocoa, por ejemplo. https://github.com/jspahrsummers/libextobjc

Proporciona 2 macros @weakify y @strongify, por lo que puede tener:

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

Esto evita una referencia directa fuerte para que no entremos en un ciclo de retención para uno mismo. Y también, evita que el yo se vuelva nulo a mitad de camino, pero aún así disminuye adecuadamente el conteo de retención. Más en este enlace: http://aceontech.com/objc/ios/2014/01/10/weakify-a-more-elegant-solution-to-weakself.html

¿Qué tal esto?

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

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

Ya no recibo la advertencia del compilador.

Bloque: se producirá un ciclo de retención porque contiene un bloque al que se hace referencia en el bloque; Si realiza la copia en bloque y utiliza una variable miembro, self retendrá.