Zachowaj cykl na sobie z blokami

Obawiam się, że to pytanie jest dość proste, ale myślę, że jest istotne dla wielu programistów Objective-C, którzy wchodzą do bloków.

Słyszałem, że skoro bloki przechwytują zmienne lokalne, do których odwołują się w nich jako constkopie, użycie selfw bloku może skutkować cyklem zachowania, jeśli ten blok zostanie skopiowany. Więc powinniśmy użyć __blockdo wymuszenia bezpośredniego działania bloku selfzamiast kopiowania.

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

zamiast po prostu

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

Chciałbym wiedzieć, co następuje: jeśli to prawda, czy istnieje sposób, żebym mógł uniknąć brzydoty (poza używaniem GC)?

Ściśle mówiąc, fakt, że jest to kopia const, nie ma nic wspólnego z tym problemem. Bloki zachowają wszelkie wartości obj-c przechwycone podczas ich tworzenia. Tak się składa, że ​​obejście problemu const-copy jest identyczne jak obejście problemu zachowania; mianowicie przy użyciu __blockklasy pamięci dla zmiennej.

W każdym razie, odpowiadając na twoje pytanie, nie ma tutaj prawdziwej alternatywy. Jeśli projektujesz własny interfejs API oparty na blokach i ma to sens, możesz poprosić o przekazanie bloku wartości selfin jako argumentu. Niestety nie ma to sensu w przypadku większości interfejsów API.

Należy pamiętać, że odwoływanie się do ivar ma dokładnie ten sam problem. Jeśli potrzebujesz odwołać się do ivar w swoim bloku, użyj zamiast tego właściwości lub użyj bself->ivar.

Dodatek: Podczas kompilacji jako ARC, __blocknie przerywa już zachowań cykli. Jeśli kompilujesz dla ARC, musisz użyć __weaklub __unsafe_unretainedzamiast tego.

Po prostu użyj:

__weak id weakSelf = self;

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

Więcej informacji: WWDC 2011 - Bloki i Grand Central Dispatch w praktyce .

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

Uwaga: jeśli to nie zadziała, możesz spróbować

__weak typeof(self)weakSelf = self;

Może to być oczywiste, ale musisz zrobić brzydki selfalias tylko wtedy, gdy wiesz, że otrzymasz cykl przechowywania. Jeśli blok jest jednorazowy, myślę, że możesz bezpiecznie zignorować zatrzymanie self. Na przykład zły przypadek ma miejsce, gdy masz blok jako interfejs wywołania zwrotnego. Jak tutaj:

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

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

@implementation AudioProcessor

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

Tutaj API nie ma większego sensu, ale miałoby sens na przykład podczas komunikacji z superklasą. Zachowujemy obsługę bufora, obsługę bufora zachowuje nas. Porównaj z czymś takim:

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

W takich sytuacjach nie wykonuję selfaliasingu. Otrzymujesz cykl zachowania, ale operacja jest krótkotrwała i blok w końcu wyjdzie z pamięci, przerywając cykl. Ale moje doświadczenie z blokami jest bardzo małe i może się zdarzyć, że selfaliasing okaże się najlepszą praktyką na dłuższą metę.

Publikowanie kolejnej odpowiedzi, ponieważ to też był problem dla mnie. Początkowo myślałem, że muszę użyć blockSelf wszędzie tam, gdzie wewnątrz bloku było odniesienie do siebie. Tak nie jest, dzieje się tak tylko wtedy, gdy sam obiekt ma w sobie blok. I faktycznie, jeśli użyjesz blockSelf w takich przypadkach, obiekt może zostać zwolniony, zanim otrzymasz wynik z powrotem z bloku, a następnie ulegnie awarii, gdy spróbuje go wywołać, więc wyraźnie chcesz, aby został zachowany do czasu odpowiedzi wraca.

Pierwszy przypadek pokazuje, kiedy wystąpi cykl utrzymania, ponieważ zawiera blok, do którego odwołuje się blok:

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

W drugim przypadku nie potrzebujesz blockSelf, ponieważ obiekt wywołujący nie ma w sobie bloku, który spowoduje cykl przechowywania, gdy odwołasz się do siebie:

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

Pamiętaj również, że cykle zachowania mogą wystąpić, jeśli twój blok odnosi się do innego obiektu, który następnie zachowujeself .

Nie jestem pewien, czy Garbage Collection może pomóc w tych cyklach przechowywania. Jeśli obiekt zachowujący blok (który nazwiemy obiektem serwera) przeżyje self(obiekt klienta), odniesienie doself wnętrza bloku nie zostanie uznane za cykliczne, dopóki sam obiekt zatrzymujący nie zostanie zwolniony. Jeśli obiekt serwera znacznie przeżyje swoich klientów, możesz mieć znaczny wyciek pamięci.

Ponieważ nie ma czystych rozwiązań, polecam następujące obejścia. Możesz wybrać jedną lub więcej z nich, aby rozwiązać problem.

• Używaj bloków tylko do ukończenia , a nie do otwartych wydarzeń. Na przykład użyj bloków dla metod takich jak doSomethingAndWhenDoneExecuteThisBlock:, a nie metod takich jaksetNotificationHandlerBlock: . Bloki użyte do ukończenia mają określony koniec życia i powinny zostać zwolnione przez obiekty serwera po ich ocenie. Zapobiega to zbyt długiemu cyklowi utrzymania, nawet jeśli wystąpi.
• Zrób ten słaby taniec, który opisałeś.
• Podaj metodę czyszczenia obiektu przed jego zwolnieniem, co „odłącza” obiekt od obiektów serwera, które mogą zawierać odniesienia do niego; i wywołaj tę metodę przed wywołaniem release na obiekcie. Chociaż ta metoda jest całkowicie w porządku, jeśli twój obiekt ma tylko jednego klienta (lub jest singletonem w pewnym kontekście), ale zepsuje się, jeśli ma wielu klientów. Zasadniczo pokonujesz tutaj mechanizm liczenia retencji; jest to podobne do dzwonienia dealloczamiast release.

Jeśli piszesz obiekt serwera, argumenty blokowe przyjmuj tylko do uzupełnienia. Nie akceptuj argumentów blokowych dla wywołań zwrotnych, takich jak setEventHandlerBlock:. Zamiast tego powróć do klasycznego wzorca delegata: utwórz formalny protokół i rozgłaszaj setEventDelegate:metodę. Nie zatrzymuj pełnomocnika. Jeśli nawet nie chcesz tworzyć formalnego protokołu, zaakceptuj selektor jako wywołanie zwrotne delegata.

I wreszcie, ten wzorzec powinien wywoływać alarmy:

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

Jeśli próbujesz odhaczyć bloki, które mogą odnosić się do selfśrodka dealloc, już masz kłopoty. deallocmoże nigdy nie zostać wywołane z powodu cyklu przechowywania spowodowanego przez odwołania w bloku, co oznacza, że ​​obiekt po prostu wycieknie, dopóki obiekt serwera nie zostanie zwolniony.

__block __unsafe_unretainedmodyfikatory sugerowane w poście Kevina mogą powodować wyjątek złego dostępu w przypadku bloku wykonywanego w innym wątku. Lepiej jest używać tylko modyfikatora __block dla zmiennej temp i po użyciu ustawić ją na zero.

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

Możesz użyć biblioteki libextobjc. Jest dość popularny, używany np. W ReactiveCocoa. https://github.com/jspahrsummers/libextobjc

Zapewnia 2 makra @weakify i @strongify, dzięki czemu możesz mieć:

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

Zapobiega to bezpośredniemu silnemu odniesieniu, więc nie wchodzimy w cykl zachowania siebie. Zapobiega również zmniejszeniu się wartości self do zera w połowie, ale nadal odpowiednio zmniejsza liczbę zatrzymań. Więcej w tym linku: http://aceontech.com/objc/ios/2014/01/10/weakify-a-more-elegant-solution-to-weakself.html

Co powiesz na to?

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

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

Nie dostaję już ostrzeżenia kompilatora.

Blok: wystąpi cykl utrzymania, ponieważ zawiera on blok, do którego istnieje odniesienie w bloku; Jeśli utworzysz kopię bloku i użyjesz zmiennej składowej, self zachowa.