Giữ lại chu kỳ trên `self` với các khối

Tôi e rằng câu hỏi này khá cơ bản, nhưng tôi nghĩ nó có liên quan đến rất nhiều lập trình viên Objective-C đang tham gia vào các khối.

Điều tôi đã nghe là vì các khối bắt các biến cục bộ được tham chiếu trong chúng dưới dạng constbản sao, sử dụng selftrong một khối có thể dẫn đến chu kỳ giữ lại, nếu khối đó được sao chép. Vì vậy, chúng tôi phải sử dụng __blockđể buộc khối phải xử lý trực tiếp selfthay vì sao chép nó.

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

Thay vì chỉ

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

Những gì tôi muốn biết là như sau: nếu điều này là đúng, có cách nào để tôi có thể tránh được sự xấu xí (ngoài việc sử dụng GC) không?

Nói đúng ra, thực tế đó là bản sao const không liên quan gì đến vấn đề này. Các khối sẽ giữ lại bất kỳ giá trị obj-c nào được ghi lại khi chúng được tạo. Nó chỉ xảy ra rằng cách giải quyết cho vấn đề const-copy giống hệt với cách giải quyết cho vấn đề giữ lại; cụ thể là sử dụng __blocklớp lưu trữ cho biến.

Trong mọi trường hợp, để trả lời câu hỏi của bạn, không có sự thay thế thực sự ở đây. Nếu bạn đang thiết kế API dựa trên khối của riêng mình và thật hợp lý để làm như vậy, bạn có thể có khối được truyền giá trị selftrong như một đối số. Thật không may, điều này không có ý nghĩa đối với hầu hết các API.

Xin lưu ý rằng việc tham khảo một chiếc ngà có cùng một vấn đề. Nếu bạn cần tham chiếu một chiếc ngà trong khối của mình, hãy sử dụng một thuộc tính thay thế hoặc sử dụng bself->ivar.

Phụ lục: Khi biên dịch dưới dạng ARC, __blockkhông còn phá vỡ các chu kỳ. Nếu bạn đang biên dịch cho ARC, bạn cần sử dụng __weakhoặc __unsafe_unretainedthay vào đó.

Chỉ dùng:

__weak id weakSelf = self;

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

Để biết thêm thông tin: WWDC 2011 - Khối và công văn lớn trong thực tế .

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

Lưu ý: nếu điều đó không hiệu quả, bạn có thể thử

__weak typeof(self)weakSelf = self;

Điều này có thể rõ ràng, nhưng bạn chỉ phải thực hiện selfbí danh xấu xí khi bạn biết bạn sẽ có một chu kỳ giữ lại. Nếu khối chỉ là một thứ duy nhất thì tôi nghĩ bạn có thể bỏ qua việc giữ lại một cách an toàn self. Trường hợp xấu là khi bạn có khối làm giao diện gọi lại chẳng hạn. Giống như ở đây:

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

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

@implementation AudioProcessor

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

Ở đây, API không có nhiều ý nghĩa, nhưng nó sẽ có ý nghĩa khi giao tiếp với một siêu lớp chẳng hạn. Chúng tôi giữ lại bộ xử lý bộ đệm, bộ xử lý bộ đệm giữ chúng tôi. So sánh với một cái gì đó như thế này:

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

Trong những tình huống này tôi không làm selfrăng cưa. Bạn có một chu kỳ giữ lại, nhưng hoạt động này chỉ tồn tại trong thời gian ngắn và cuối cùng khối sẽ thoát khỏi bộ nhớ, phá vỡ chu trình. Nhưng kinh nghiệm của tôi với các khối là rất nhỏ và có thể là selfrăng cưa xuất hiện như một cách thực hành tốt nhất trong thời gian dài.

Đăng một câu trả lời khác bởi vì đây cũng là một vấn đề đối với tôi. Ban đầu tôi nghĩ rằng tôi phải sử dụng blockSelf ở bất cứ đâu có một tài liệu tham khảo tự bên trong một khối. Đây không phải là trường hợp, nó chỉ khi bản thân đối tượng có một khối trong đó. Và trên thực tế, nếu bạn sử dụng blockSelf trong những trường hợp này, đối tượng có thể nhận được dealloc'd trước khi bạn lấy lại kết quả từ khối và sau đó nó sẽ bị sập khi cố gắng gọi nó, vì vậy rõ ràng bạn muốn giữ lại cho đến khi phản hồi quay lại.

Trường hợp đầu tiên chứng minh khi một chu kỳ giữ lại sẽ xảy ra bởi vì nó chứa một khối được tham chiếu trong khối:

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

Bạn không cần blockSelf trong trường hợp thứ hai vì đối tượng gọi không có khối trong đó sẽ gây ra chu kỳ giữ lại khi bạn tự tham chiếu:

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

Cũng cần nhớ rằng chu kỳ giữ lại có thể xảy ra nếu khối của bạn tham chiếu đến một đối tượng khác mà sau đó giữ lại self.

Tôi không chắc chắn rằng Bộ sưu tập rác có thể giúp ích trong các chu kỳ giữ lại này. Nếu đối tượng giữ lại khối (mà tôi sẽ gọi đối tượng máy chủ) tồn tại self(đối tượng khách), thì tham chiếu selfbên trong khối sẽ không được coi là tuần hoàn cho đến khi chính đối tượng giữ lại được giải phóng. Nếu đối tượng máy chủ vượt xa các máy khách của nó, bạn có thể bị rò rỉ bộ nhớ đáng kể.

Vì không có giải pháp sạch, tôi sẽ đề xuất các cách giải quyết sau. Hãy chọn một hoặc nhiều trong số họ để khắc phục vấn đề của bạn.

• Chỉ sử dụng các khối để hoàn thành và không cho các sự kiện kết thúc mở. Ví dụ: sử dụng các khối cho các phương thức như doSomethingAndWhenDoneExecuteThisBlock:, chứ không phải các phương thức như setNotificationHandlerBlock:. Các khối được sử dụng để hoàn thành có thời gian kết thúc xác định và sẽ được các đối tượng máy chủ giải phóng sau khi chúng được đánh giá. Điều này ngăn chặn chu kỳ giữ lại sống quá lâu ngay cả khi nó xảy ra.
• Làm điệu nhảy tham chiếu yếu mà bạn mô tả.
• Cung cấp một phương thức để dọn sạch đối tượng của bạn trước khi nó được phát hành, nó "ngắt kết nối" đối tượng khỏi các đối tượng máy chủ có thể chứa các tham chiếu đến nó; và gọi phương thức này trước khi gọi phát hành trên đối tượng. Mặc dù phương pháp này hoàn toàn tốt nếu đối tượng của bạn chỉ có một khách hàng (hoặc là một người độc thân trong một số ngữ cảnh), nhưng sẽ bị hỏng nếu có nhiều khách hàng. Về cơ bản bạn đang đánh bại cơ chế đếm giữ ở đây; đây là giống như gọi deallocthay vì release.

Nếu bạn đang viết một đối tượng máy chủ, chỉ lấy các đối số khối để hoàn thành. Không chấp nhận đối số khối cho các cuộc gọi lại, chẳng hạn như setEventHandlerBlock:. Thay vào đó, hãy quay lại mô hình đại biểu cổ điển: tạo một giao thức chính thức và quảng cáo một setEventDelegate:phương thức. Không giữ lại đại biểu. Nếu bạn thậm chí không muốn tạo một giao thức chính thức, hãy chấp nhận bộ chọn làm cuộc gọi lại ủy nhiệm.

Và cuối cùng, mẫu này sẽ rung chuông báo động:

- (void) dealloc {
    [myServerObject phát hànhCallbackBlocksForObject: self];
    ...
}

Nếu bạn đang cố gắng mở các khối có thể tham chiếu selftừ bên trong dealloc, bạn đã gặp rắc rối. dealloccó thể không bao giờ được gọi do chu kỳ giữ lại gây ra bởi các tham chiếu trong khối, điều đó có nghĩa là đối tượng của bạn chỉ đơn giản là bị rò rỉ cho đến khi đối tượng máy chủ bị hủy.

__block __unsafe_unretainedcông cụ sửa đổi được đề xuất trong bài đăng của Kevin có thể gây ra ngoại lệ truy cập xấu trong trường hợp khối được thực thi trong một luồng khác. Tốt hơn hết là chỉ sử dụng công cụ sửa đổi __block cho biến temp và làm cho nó không sau khi sử dụng.

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

Bạn có thể sử dụng thư viện libextobjc. Nó khá phổ biến, nó được sử dụng trong ReactiveCocoa chẳng hạn. https://github.com/jspahrsummers/libextobjc

Nó cung cấp 2 macro @weakify và @strongify, vì vậy bạn có thể có:

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

Điều này ngăn cản một tham chiếu mạnh trực tiếp để chúng ta không tự chui vào. Ngoài ra, nó ngăn không cho bản thân trở thành con số không, nhưng vẫn làm giảm số lượng giữ lại một cách chính xác. Thêm trong liên kết này: http://aceontech.com/objc/ios/2014/01/10/weakify-a-more-elegant-solution-to-weakelf.html

Còn cái này thì sao?

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

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

Tôi không nhận được cảnh báo trình biên dịch nữa.

Khối: một chu kỳ giữ lại sẽ xảy ra vì nó chứa một khối được tham chiếu trong khối; Nếu bạn tạo bản sao khối và sử dụng biến thành viên, tự sẽ giữ lại.