How do I avoid capturing self in blocks when implementing an API?

简介:

Short answer

Instead of accessing self directly, you should access it indirectly, from a reference that will not be retained. If you're not using Automatic Reference Counting (ARC), you can do this:

__block MyDataProcessor*dp = self;
self.progressBlock =^(CGFloat percentComplete){[dp.delegate myAPI:dp isProcessingWithProgress:percentComplete];}

The __block keyword marks variables that can be modified inside the block (we're not doing that) but also they are not automatically retained when the block is retained (unless you are using ARC). If you do this, you must be sure that nothing else is going to try to execute the block after the MyDataProcessor instance is released. (Given the structure of your code, that shouldn't be a problem.) Read more about__block.

If you are using ARC, the semantics of __block changes and the reference will be retained, in which case you should declare it __weak instead.

Long answer

Let's say you had code like this:

self.progressBlock =^(CGFloat percentComplete){[self.delegate processingWithProgress:percentComplete];}

The problem here is that self is retaining a reference to the block; meanwhile the block must retain a reference to self in order to fetch its delegate property and send the delegate a method. If everything else in your app releases its reference to this object, its retain count won't be zero (because the block is pointing to it) and the block isn't doing anything wrong (because the object is pointing to it) and so the pair of objects will leak into the heap, occupying memory but forever unreachable without a debugger. Tragic, really.

That case could be easily fixed by doing this instead:

id progressDelegate = self.delegate;
self.progressBlock =^(CGFloat percentComplete){[progressDelegate processingWithProgress:percentComplete];}

In this code, self is retaining the block, the block is retaining the delegate, and there are no cycles (visible from here; the delegate may retain our object but that's out of our hands right now). This code won't risk a leak in the same way, because the value of the delegate property is captured when the block is created, instead of looked up when it executes. A side effect is that, if you change the delegate after this block is created, the block will still send update messages to the old delegate. Whether that is likely to happen or not depends on your application.

Even if you were cool with that behavior, you still can't use that trick in your case:

self.dataProcessor.progress =^(CGFloat percentComplete){[self.delegate myAPI:self isProcessingWithProgress:percentComplete];};

Here you are passing self directly to the delegate in the method call, so you have to get it in there somewhere. If you have control over the definition of the block type, the best thing would be to pass the delegate into the block as a parameter:

self.dataProcessor.progress =^(MyDataProcessor*dp,CGFloat percentComplete){[dp.delegate myAPI:dp isProcessingWithProgress:percentComplete];};

This solution avoids the retain cycle and always calls the current delegate.

If you can't change the block, you could deal with it. The reason a retain cycle is a warning, not an error, is that they don't necessarily spell doom for your application. If MyDataProcessor is able to release the blocks when the operation is complete, before its parent would try to release it, the cycle will be broken and everything will be cleaned up properly. If you could be sure of this, then the right thing to do would be to use a #pragma to suppress the warnings for that block of code. (Or use a per-file compiler flag. But don't disable the warning for the whole project.)

You could also look into using a similar trick above, declaring a reference weak or unretained and using that in the block. For example:

__weak MyDataProcessor*dp = self;// OK for iOS 5 only
__unsafe_unretained MyDataProcessor*dp = self;// OK for iOS 4.x and up
__block MyDataProcessor*dp = self;// OK if you aren't using ARC
self.progressBlock =^(CGFloat percentComplete){[dp.delegate myAPI:dp isProcessingWithProgress:percentComplete];}

All three of the above will give you a reference without retaining the result, though they all behave a little bit differently: __weak will try to zero the reference when the object is released;__unsafe_unretained will leave you with an invalid pointer; __block will actually add another level of indirection and allow you to change the value of the reference from within the block (irrelevant in this case, since dp isn't used anywhere else).

What's best will depend on what code you are able to change and what you cannot. But hopefully this has given you some ideas on how to proceed.

share | edit | flag
 
1  
   
Awesome answer! Thanks, I have a much better understanding about what is going on and how this all works. In this case, I have control over everything so I'll re-architect some of the objects as needed. –  XJones  Oct 21 '11 at 21:18
   
   
Good answer. I've been using __weak myself in an iOS project. It gives you more safety than __block or __unsafe_unretained, but I imagine most people would be calling this in a situation where self is guaranteed to exist. I also like __weak as a keyword because it is more "explicit" about what's being accomplished, whereas the intentions of __block can be ambiguous. –   mikelikespie  Nov 2 '11 at 1:15
7  
   
O_O I was just passing by with a slightly different problem, got stuck reading, and now leave this page feeling all knowledgeable and cool. Thanks! –   Orc JMR  Dec 19 '12 at 8:07
   
   
@OrcJMR You're welcome! –   benzado  Dec 19 '12 at 22:12
   
   
is is correct, that if for some reason on the moment of block execution dp will be released (for example if it was a view controller and it was poped), then line [dp.delegate ... will cause EXC_BADACCESS? –  peetonn  Jan 30 '13 at 1:50
   
add / show 5 more comments

There’s also the option to suppress the warning when you are positive that the cycle will get broken in the future:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-retain-cycles"

self.progressBlock =^(CGFloat percentComplete){[self.delegate processingWithProgress:percentComplete];}#pragma clang diagnostic pop

That way you don’t have to monkey around with __weakself aliasing and explicit ivar prefixing.

share | edit | flag
 
1  
   
Sounds like a very bad practice that takes more than 3 lines of code that can be replaced with __weak id weakSelf = self; –   Andy  Sep 3 '13 at 14:05 
1  
   
There’s often a larger block of code that can benefit from the suppressed warnings. –   zoul  Sep 3 '13 at 17:56
   
add comment

I believe the solution without ARC also works with ARC, using the __block keyword:

EDIT: Per the Transitioning to ARC Release Notes, an object declared with __block storage is still retained. Use __weak (preferred) or __unsafe_unretained (for backwards compatibility).

// code sample
self.delegate= aDelegate;

self.dataProcessor =[[MyDataProcessor alloc] init];// Use this inside blocks
__block id myself = self;

self.dataProcessor.progress =^(CGFloat percentComplete){[myself.delegate myAPI:myself isProcessingWithProgress:percentComplete];};

self.dataProcessor.completion =^{[myself.delegate myAPIDidFinish:myself];
    myself.dataProcessor = nil;};// start the processor - processing happens asynchronously and the processor is released in the completion block[self.dataProcessor startProcessing];
share | edit | flag
 
   
   
Didn't realize that the __block keyword avoided retaining it's referent. Thanks! I updated my monolithic answer. :-) –   benzado  Oct 21 '11 at 21:41
1  
   
According to Apple docs "In manual reference counting mode, __block id x; has the effect of not retaining x. In ARC mode, __block id x; defaults to retaining x (just like all other values)." –   XJones  Oct 22 '11 at 2:08 
   
   
@XJones Thanks for the clarification, I've edited my answer. –   Tony  Oct 24 '11 at 15:09
   
add comment

For a common solution, I have these define in the precompile header. Avoids capturing and still enables compiler help by avoiding to use id

#defineBlockWeakObject(o) __typeof(o) __weak
#defineBlockWeakSelfBlockWeakObject(self)

Then in code you can do:

BlockWeakSelf weakSelf = self;
self.dataProcessor.completion =^{[weakSelf.delegate myAPIDidFinish:weakSelf];
    weakSelf.dataProcessor = nil;};
欢迎加群互相学习,共同进步。QQ群:iOS: 58099570 | Android: 572064792 | Nodejs:329118122 做人要厚道,转载请注明出处!

















本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/sunshine-anycall/p/3514235.html ,如需转载请自行联系原作者

相关文章
|
24天前
|
JSON API 数据格式
淘宝 / 天猫官方商品 / 订单订单 API 接口丨商品上传接口对接步骤
要对接淘宝/天猫官方商品或订单API,需先注册淘宝开放平台账号,创建应用获取App Key和App Secret。之后,详细阅读API文档,了解接口功能及权限要求,编写认证、构建请求、发送请求和处理响应的代码。最后,在沙箱环境中测试与调试,确保API调用的正确性和稳定性。
|
1月前
|
供应链 数据挖掘 API
电商API接口介绍——sku接口概述
商品SKU(Stock Keeping Unit)接口是电商API接口中的一种,专门用于获取商品的SKU信息。SKU是库存量单位,用于区分同一商品的不同规格、颜色、尺寸等属性。通过商品SKU接口,开发者可以获取商品的SKU列表、SKU属性、库存数量等详细信息。
|
1月前
|
JSON API 数据格式
店铺所有商品列表接口json数据格式示例(API接口)
当然,以下是一个示例的JSON数据格式,用于表示一个店铺所有商品列表的API接口响应
|
2月前
|
编解码 监控 API
直播源怎么调用api接口
调用直播源的API接口涉及开通服务、添加域名、获取API密钥、调用API接口、生成推流和拉流地址、配置直播源、开始直播、监控管理及停止直播等步骤。不同云服务平台的具体操作略有差异,但整体流程简单易懂。
|
27天前
|
JSON API 数据安全/隐私保护
拍立淘按图搜索API接口返回数据的JSON格式示例
拍立淘按图搜索API接口允许用户通过上传图片来搜索相似的商品,该接口返回的通常是一个JSON格式的响应,其中包含了与上传图片相似的商品信息。以下是一个基于淘宝平台的拍立淘按图搜索API接口返回数据的JSON格式示例,同时提供对其关键字段的解释
|
2月前
|
人工智能 自然语言处理 PyTorch
Text2Video Huggingface Pipeline 文生视频接口和文生视频论文API
文生视频是AI领域热点,很多文生视频的大模型都是基于 Huggingface的 diffusers的text to video的pipeline来开发。国内外也有非常多的优秀产品如Runway AI、Pika AI 、可灵King AI、通义千问、智谱的文生视频模型等等。为了方便调用,这篇博客也尝试了使用 PyPI的text2video的python库的Wrapper类进行调用,下面会给大家介绍一下Huggingface Text to Video Pipeline的调用方式以及使用通用的text2video的python库调用方式。
|
2月前
|
JSON JavaScript API
(API接口系列)商品详情数据封装接口json数据格式分析
在成长的路上,我们都是同行者。这篇关于商品详情API接口的文章,希望能帮助到您。期待与您继续分享更多API接口的知识,请记得关注Anzexi58哦!
|
1月前
|
JSON 前端开发 JavaScript
API接口商品详情接口数据解析
商品详情接口通常用于提供特定商品的详细信息,这些信息比商品列表接口中的信息更加详细和全面。以下是一个示例的JSON数据格式,用于表示一个商品详情API接口的响应。这个示例假定API返回一个包含商品详细信息的对象。
|
2月前
|
JSON API 开发者
1688API商品详情接口如何获取
获取 1688 API 商品详情接口的步骤包括:1. 注册开发者账号;2. 了解接口规范和政策;3. 申请 API 权限;4. 获取 API 密钥;5. 实现接口调用(选择开发语言、发送 HTTP 请求);6. 处理响应数据。通过这些步骤,可以顺利调用 1688 的商品详情 API。